�
> -----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] * *===================================*
