portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fletcher, Boyd C. J9C534" <Boyd.Fletc...@je.jfcom.mil>
Subject RE: JSR 168, Security, and User Information
Date Fri, 15 Aug 2003 03:01:41 GMT
Isn't this basically what SAML was suppose to fix.  We've used SAML
enabled Netegrity Siteminder and Oblix NetPoint in the past to handle
inter-app/web-server authentication and authorization. There are also a
couple of open source projects that are tackling the issue:
http://shibboleth.internet2.edu, http://www.opensaml.org, and
http://www.nsf-middleware.org/NMIR3/components/edit-software.asp

boyd


> -----Original Message-----
> From: Jeff Linwood [mailto:jeff@greenninja.com] 
> Sent: Thursday, August 14, 2003 10:44 PM
> To: Alejandro Abdelnur
> Cc: jetspeed-dev@jakarta.apache.org; jsr-168-comments@jcp.org
> Subject: Re: JSR 168, Security, and User Information
> 
> 
> Hi,
> 
> I saw JSR 196, but that looks like it will just standardize the 
> username/password authentication for J2EE containers.  What I was 
> looking for was a standard API for permissions (like JSR 115), 
> username/password, single sign-on, and user information, 
> because those 
> are all likely to be stored in one central database.
> 
> I agree that the container should fetch the user information, but 
> considering that each container will have to do this, it should be 
> standardized.  Obviously, the specification shouldn't try to specify 
> what fields are on a user, because that won't be generic 
> enough, but it 
> would be nice to have one layer to integrate with for authentication, 
> authorization, and user information.
> 
> I would like to see single-sign on taken into account as 
> well, because 
> the username and password recieved from the portal container 
> may not be 
> the username and password required by the portlet to authenticate to 
> another legacy system - which means that each portlet would have to 
> store the single sign-on information as a preference.  This could be 
> difficult to administer/automate, especially for application 
> migrations 
> into a portal environment.
> 
> Thanks,
> Jeff
> 
> Alejandro Abdelnur wrote:
> > Jeff,
> > 
> > Thanks for your feedback.
> > 
> > On authentication, if I understand correctly what you are proposing,
> > this is outside of the realm of portlet-apps, web-apps and 
> > enterprise-apps. It is something it is outside of the scope 
> of a single 
> > container, it has to be solved in a general way (servlet-container, 
> > ejb-container, portlet-container). Today many 
> implementations provide 
> > support for plugin an authentication service. Some of them 
> are based on 
> > JAAS and some on proprietary APIs. It's the container 
> implementor who 
> > has to take care of this, not the application developers. 
> There is a 
> > JSR, 196, that is aimed at this. Another one, JSR115, takes care of 
> > plugglable authorization (roles checking).
> > 
> > On user information, JSR168 puts the responsibility on the 
> container 
> > to
> > fetch user information data. Portlet applications don't 
> have to worry 
> > about this. You  cannot modify it through the Portlet API. 
> In fact, user 
> > information, should be another API altogether, we added this simple 
> > mechanism to fetch user info data because portlets use it 
> often and we 
> > wanted to address this somehow. You can see the user info 
> portlet API 
> > offers as a temporary fix for something should be be addressed in a 
> > generic way (to be usable from other component APIs).
> > 
> > Regards.
> > 
> > Alejandro / Stefan
> > JSR168, specification co-leads
> > 
> > On Thursday, August 14, 2003, at 12:30  AM, Jeff Linwood wrote:
> > 
> >> I wanted to see what people thought about the security and user
> >> information side of JSR 168.
> >>
> >> It looks like the portal security model is based on the servlet
> >> security model.  Each servlet engine has a different interface for 
> >> plugging in a custom authentication mechanism (Tomcat's 
> realms, for 
> >> instance).  This means that to support multiple app 
> servers with one 
> >> back-end authentication database or application, multiple 
> integration 
> >> pieces are needed, and applications can't be deployed on any app 
> >> server without a migration effort.  I'd prefer adding a 
> >> security/authentication layer to the portal container 
> specification 
> >> that allowed different portable back ends.
> >>
> >> Otherwise, it looks like to implement an integration between my
> >> portlet and my user database, I'd have to:
> >>
> >> a) write a database integration implementation for each servlet 
> >> engine
> >> b) write an integration between my portal container and my 
> database to 
> >> get the user information
> >> c) include hooks in my portlet to somehow get the database 
> >> configuration information (say a JDBC URL, or a WSDL URL 
> w/ username 
> >> and password) from the portal container, and then make 
> calls to it to 
> >> get any additional information, or to change anything, in 
> case we had 
> >> one database, but multiple portal containers that don't share 
> >> preferences for different parts of the organization.
> >>
> >> Something else I noticed with the user information model is that it
> >> doesn't look like preferences are tied to the user 
> information that 
> >> portal containers are supposed to pass to the portlet - so you 
> >> couldn't write a portlet that would conform to the spec that could 
> >> modify user information, such as email, password, etc.
> >>
> >> Anyway, let me know if these are valid issues, or if there is
> >> something I missed in the portlet specification.
> >>
> >> Thanks,
> >> Jeff Linwood
> >>
> >>
> > 
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 

Mime
View raw message