From gcf@npac.syr.edu Tue Feb 22 09:14:38 2000 Date: Tue, 15 Feb 2000 22:38:08 -0500 From: Geoffrey Fox To: Marlon Pierce Subject: Cant spell address -- please comment on security Return-Path: Received: from localhost (gcf@localhost) by boss.npac.syr.edu (8.9.3/8.9.3) with SMTP id WAA261708; Tue, 15 Feb 2000 22:34:03 -0500 (EST) Message-Id: <200002160334.WAA261708@boss.npac.syr.edu> X-Authentication-Warning: boss.npac.syr.edu: gcf@localhost didn't use HELO prot ocol Reply-to: gcf@npac.syr.edu To: pierce@boss.npac.syr.edu, haupt@boss.npac.syr.edu Subject: Exchange on Security in NCSA Portal Date: Tue, 15 Feb 2000 22:34:03 -0500 From: Geoffrey Fox Comments? Geoffrey Fox gcf@npac.syr.edu gcf@cs.fsu.edu Phones Cell 315-254-6387 Syracuse Office 315-443-2163 FSU Office 850-644-4587 - ------- Forwarded Messages Date: Tue, 15 Feb 2000 19:35:10 -0500 From: Dennis Gannon To: Jay Alameda cc: gcf@npac.syr.edu, Gregor von Laszewski , ccat@cs.indiana.edu Subject: Re: Portals Hi Jay and Geoffrey, thanks for the comments. yes, what Geoffrey has outlined is very much along the lines of what i have been thinking about. also we need to keep focused on the other aspect of our portal toolkit. we had a good talk at nasa yesterday with Steve Tuecke and our people who are looking at hot page and the user portal. One the issues that keeps coming back again and again is security and delegation. This relates to the cogkit stuff that gregor and company bring to the table. we need a way for a laptop user with a local private key to create a remote proxy with the authority to do things like move protected files around and launch jobs, etc. this would take the form of a little local daemon that has access to the private key and can do the bidding of the user who is working from the web browser. technical problems are hard to solve, i.e. can't assume users browser will allow a java2 plug in and applets may be too restricted anyway.. my guys have worked up a little demo that shows how to launch remote components from the web browser based on servlet technology, but this assumes the servlet has access to the private keys. this is what ucsd is planning, but it is ot what we want for the high security (nobody has my private key but me) situations. we need to think about is the list of "high security" functionality we need to support for the portal applications. things like "do a secure file transfer for job staging that moves a file from A to B with out making it go though my dialup connection or the web server." Gregor, you have probably given this more thought than me. dennis ps: sorry this message is late. i have been on airplanes again. i am in indianapolis tonight for meetings tomorrow and i will be attending to indiana university business on thurs - sat. back to my temporary home on sat night and then back to chicago monday night or i will red eye it on tues for our meeting. On Tue, 15 Feb 2000, Jay Alameda wrote: > Geoffrey -- I think you are correct in your assessment of needs -- this set > of portal authoring tools would go far beyond current practice. Dennis -- > does this sound like what you have been thinking of as well? I really liked > your assessment of the problems inherent in our current prototype. > > Jay > > > ----- Original Message ----- > From: Geoffrey Fox > To: Jay Alameda ; Dennis Gannon > > Cc: Gregor von Laszewski > Sent: Tuesday, February 15, 2000 4:16 PM > Subject: Portals > > > > I have been silently following the conversation between Jay and Dennis > > I think that some of recent suggestions are supportive of the concept > > of "Visual Portal Authoring Tools" with an XML backend supporting > > both object (document fragment, tool, index etc) specification > > and their special parameters (layout, parameters, I/O and files including > > file format, collaborative structure etc). This allows easier production > > of pages with same(good) look and feel within a given portal and more > > generally to produce multiple portals with a given CPA > > Did I misunderstand needs? > > > > Geoffrey Fox gcf@npac.syr.edu gcf@cs.fsu.edu > > Phones Cell 315-254-6387 Syracuse Office 315-443-2163 FSU Office > 850-644-4587 > > > > > > > > - ------- Message 2 Date: Tue, 15 Feb 2000 20:56:08 -0500 From: Kenneth Chiu To: Dennis Gannon cc: Jay Alameda , gcf@npac.syr.edu, Gregor von Laszewski , ccat@cs.indiana.edu Subject: Re: [CCAT]Re: Portals On Tue, 15 Feb 2000, Dennis Gannon wrote: > my guys have worked up a little demo that shows how to launch > remote components from the web browser based on servlet technology, > but this assumes the servlet has access to the private keys. this > is what ucsd is planning, but it is ot what we want for the high > security (nobody has my private key but me) situations. I'm not sure if Globus can do this straight out-of-the-box, but if not, the following solution might be easy to build using a combination of Globus and SSL. Locally, generate a proxy certificate (signed by you). Open up an SSL connection from the browser to the remote server. Send the private proxy key through the SSL connection. You can send the proxy certificate over an insecure channel. The server now creates a remote proxy containing the private key corresponding to the proxy certificate. You can qualify how much you trust the server by granting the proxy only the rights you want (by what you put in the certificate). So you might only allow the proxy to access resources on the server's host. I think this kind of functionality is already a part of the Globus proxy certificate. - ------- Message 3 Date: Tue, 15 Feb 2000 19:59:51 -0600 From: Gregor von Laszewski To: Dennis Gannon cc: Jay Alameda , gcf@npac.syr.edu, ccat@cs.indiana.edu, tuecke@mcs.anl.gov, gawor@mcs.anl.gov Subject: Re: Portals Yes, we thought about it. What we actually do need is the possibility of extending SSL with the delegation stuff. If this would be the case one could launch directly from the browser. But that is too far off. Generally I am not considering ANY solution where the private key is stored on a remote host. I think this is simply wrong, but I can understand arguments why this may be a convenient way to simplify security (looks to me like clear text authentication though). The scenario (secure file copy without going through the browser) described by dennis is I think possible. One of the people working here is currently trying to get exactly this going. I think we may be able to tweek a servlet solution a bit while letting the servlet do a key deligation via the CoG Kit. This way the private key would be still on the client side. I also think that we may include in a future path to demand that we have smartcards or java rings to increase security. PS: I hope the security discussion at SDSC has lead to a good result. I will as k Steve to give me an update. PS: I think we are in agreement that we have the following three components. USER ADMINISTRATOR DESIGNER PORTAL PORTAL PORTAL I used to call this actually the GridCAS Dennis Gannon wrote: > Hi Jay and Geoffrey, > thanks for the comments. yes, what Geoffrey has outlined is very > much along the lines of what i have been thinking about. also we > need to keep focused on the other aspect of our portal toolkit. > we had a good talk at nasa yesterday with Steve Tuecke and our people > who are looking at hot page and the user portal. One the issues > that keeps coming back again and again is security and delegation. > This relates to the cogkit stuff that gregor and company bring to > the table. we need a way for a laptop user with a local private > key to create a remote proxy with the authority to do things like > move protected files around and launch jobs, etc. this would take > the form of a little local daemon that has access to the private > key and can do the bidding of the user who is working from the web > browser. technical problems are hard to solve, i.e. can't assume > users browser will allow a java2 plug in and applets may be too > restricted anyway.. > my guys have worked up a little demo that shows how to launch > remote components from the web browser based on servlet technology, > but this assumes the servlet has access to the private keys. this > is what ucsd is planning, but it is ot what we want for the high > security (nobody has my private key but me) situations. > > we need to think about is the list of "high security" functionality > we need to support for the portal applications. things like > "do a secure file transfer for job staging that moves a file from A > to B with out making it go though my dialup connection or the web > server." > Gregor, you have probably given this more thought than me. > dennis > ps: sorry this message is late. i have been on airplanes again. > i am in indianapolis tonight for meetings tomorrow and i will be > attending to indiana university business on thurs - sat. back > to my temporary home on sat night and then back to chicago > monday night or i will red eye it on tues for our meeting. > > On Tue, 15 Feb 2000, Jay Alameda wrote: > > > Geoffrey -- I think you are correct in your assessment of needs -- this set > > of portal authoring tools would go far beyond current practice. Dennis -- > > does this sound like what you have been thinking of as well? I really like d > > your assessment of the problems inherent in our current prototype. > > > > Jay > > > > > > ----- Original Message ----- > > From: Geoffrey Fox > > To: Jay Alameda ; Dennis Gannon > > > > Cc: Gregor von Laszewski > > Sent: Tuesday, February 15, 2000 4:16 PM > > Subject: Portals > > > > > > > I have been silently following the conversation between Jay and Dennis > > > I think that some of recent suggestions are supportive of the concept > > > of "Visual Portal Authoring Tools" with an XML backend supporting > > > both object (document fragment, tool, index etc) specification > > > and their special parameters (layout, parameters, I/O and files including > > > file format, collaborative structure etc). This allows easier production > > > of pages with same(good) look and feel within a given portal and more > > > generally to produce multiple portals with a given CPA > > > Did I misunderstand needs? > > > > > > Geoffrey Fox gcf@npac.syr.edu gcf@cs.fsu.edu > > > Phones Cell 315-254-6387 Syracuse Office 315-443-2163 FSU Office > > 850-644-4587 > > > > > > > > > > > > > - - -- - - -------------------------------------------------------------------- * Gregor von Laszewski * gregor@mcs.anl.gov * Mathematics and Computer Science Division * fax : (630) 252-5986 * Argonne National Laboratory * phone: (630) 252-0472 * Argonne, IL 60439 http://www.mcs.anl.gov/~gregor - ------- Message 4 Date: Tue, 15 Feb 2000 21:17:16 -0500 From: Kenneth Chiu To: Dennis Gannon cc: Jay Alameda , gcf@npac.syr.edu, Gregor von Laszewski , ccat@cs.indiana.edu Subject: Re: [CCAT]Re: Portals On Tue, 15 Feb 2000, Kenneth Chiu wrote: > On Tue, 15 Feb 2000, Dennis Gannon wrote: > > my guys have worked up a little demo that shows how to launch > > remote components from the web browser based on servlet technology, > > but this assumes the servlet has access to the private keys. this > > is what ucsd is planning, but it is ot what we want for the high > > security (nobody has my private key but me) situations. > > I'm not sure if Globus can do this straight out-of-the-box, but if > not, the following solution might be easy to build using a combination > of Globus and SSL. > ... Forget to add that the remote proxy will not have access to your private key. You only send the proxy private key which has restricted rights and time duration. - ------- End of Forwarded Messages - --WAA265703.950672044/boss.npac.syr.edu-- ------- End of Forwarded Message