It looks like JSR 196 (http://www.jcp.org/en/jsr/detail?id=196) is the specification for a unified portable API for connecting container authentication to back-end user databases, legacy systems, etc.
I think single-sign on is very important for a portal, and we probably have had similar problems with account management. I'd like to see the standard extend to a wider range of user information than just username, role, and password, though. For instance, with the current model, it looks like each portlet would be responsible for managing its own set of maps of permissions to roles, which I think would be useful to be standardized as a portal container feature. I also would like to allow the portlet to have access to the user information for modification, if possible. This access would have to be controlled by the portal container, and not allowed by default, in case there are badly coded portlets. I saw that preferences were on a per-user basis in the portlet specification, but my concern was really that portlets couldn't use the preference API to change user profile information. I would imagine that sharing portlet preferences between different portal container instances or installations would end up being an extended feature for some portlet containers. Jeff ----- Original Message ----- From: "Chamberlain James O. CONTR J9C998" <[EMAIL PROTECTED]> To: "Jetspeed Developers List" <[EMAIL PROTECTED]> Sent: Thursday, August 14, 2003 10:22 AM Subject: RE: JSR 168, Security, and User Information I really hope that Jetspeed 2 will be able to use the servlet security model. By using the servlet model all authentication and authorization can be pushed to the container to manage. So single sign-on within the application server can be easily accomplished. Single sign-on between multiple application servers can be accomplished by plugging in third party security tools such as Siteminder. Another reason to use container based security is the strong third party support for plugins, in particular the support for federated identities for cross organization sso is a real hot issue for us. For our applications we would like to centralize the user account information for all of our applications. Creating a single point of account management and enabling single sign-on. Sorry for running on, but account management has been a real thorn in my side in the past. Regards, James -----Original Message----- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 10:15 AM To: 'Jetspeed Developers List' Subject: RE: JSR 168, Security, and User Information > -----Original Message----- > From: Jeff Linwood [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 14, 2003 3:31 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: JSR 168, Security, and User Information > > 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. > The JSR-168 took a lot from the servlet spec to build the portlet spec. However, we are not required to use the servlet container's security model. So we will eventually have our own security model which will more than likely default to using an LDAP solution. > 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. > The spec does state that preferences are on a per-user basis, look at the first few lines under PTL.14 in the spec. So that means that the PortletPreference object that is made available within your portlet will be specific to that user. As for modifying preferences, a portlet can easily modify user preferences by calling the PortletPreference's store() method. However, this can only be done during the action phase, calling it during the render phase will throw an UnsupportedOperationException. > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] *===================================* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===================================* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
