For more clarity the component should be called SingleSignonComponent.
More comments see below....
David Sean Taylor wrote:
David Le Strat wrote:
Roger,
This is great. I have a couple questions/comments. See below.
--- Roger Ruttimann <[EMAIL PROTECTED]> wrote:
The following proposal describes how J2 handles
single sign-on (SSO). I gathered ideas from several people and the proposal
below came together with input from Randy Watler and David Taylor.
Proposal
------------
The J2 framework will be extended with a component
(SSOCredentials) that does a lookup in the database to find credentials
for a site (url) and a jetspeed user. The credentials could be assigned to
a user, group or a role (Priority needs to be defined like User, Group,
Role or better order should be customizable).
Does this mean, that you will modify the login module
so that upon authentication, you add a private or
public credential (which one) to the security Subject?
By doing so, the SSOCredential could be mapped to the
principal (currently supported in the security layer
for any type of principals).
I like this approach as it would fill all the security credentials, including credentials required for single signon into one subject in a standard manner.
This would could also simplify how credentials are accessed. All credentials could be retrieved from the Subject
see:
http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/Subject.html
This way the SSOComponent would actually be invoked from the login module. A credential could be associated with a named Site (see web content module) and stored in the credentials set on the Subject.
I like the idea but wouldn't we store to much (all credentials for external sites) information that migth never been used?
The credentials would be fixed for the time the user is logged in. For any changes the user has to log out login. Not a big deal but just something to remember.
Will the SSOCredential basically become another type of credential in the security framework? Or am i missing something?
I think so, yes, although I don't think any interface is required on the credential:
http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/Subject.html#getPrivateCredentials(java.lang.Class)
Accessing a resource becomes simple, the Subject has the principals and the credentials, a component can perform the match and grant or deny access. I guess I am getting a little confused, when you talk about SSOCredential API (a little below).
We were discussing an API called SSOComponent or SecureSignonComponent
As I mentioned above we should use the more descriptive name SecureSignonComponent
For the first implementation two modes will be supported:
Username/password (HTTP Post) --> Portlets (IFrame, Webpage) will call into SSOCredentials with the site (url) and the principal. The returned credentials can be used to add them as parameters to the URL
Basic Authentication (HTTP Basic Authentication)
--> Since many sites use Basic Authentication
another API updates the request so that it uses BasicAuthentication with the
credentials returned by the lookup (site, principal).
At a later stage the SSOCredential API could be extended with certificates and cookie based authentication.
Implementation -------------------- The credentials for the site can be entered in two ways:
--> If a user tries to access a secured site (lookup
in SSOCredentials API fails) a dialog will pop up and ask if the
credentials for that site should be stored in the SSO credentials table. For
any future requests the credentials will be found by the lookup.
--> Using the SSO Admin portlet. This is necessary for assigning credentials to groups and roles and to update or clean credentials.
If you decided to leverage some of the security framework stuff, managing this association is basically managing the assoc credential where credential is of type (SSOCredential) to principal.
+1
+1
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
