Of course you always have the option of depending on vendors. However, those monitoring this list are more interested in open standards and the bleeding edge.
Glen
Jeff Linwood wrote:
Isn't SAML more of an interchange language for single sign on than a user management layer? Anyway, maybe this is getting more towards Sun's Project Liberty than capabilities the portal container should have. I would think that some portal vendors will add single sign on management to their portals, and I would have liked to see it standardized.
Jeff
Fletcher, Boyd C. J9C534 wrote:
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:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 10:44 PM
To: Alejandro Abdelnur
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
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
--------------------------------------------------------------------- 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]
