portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ruttimann <roger...@apache.org>
Subject Re: [J2] Proposal Single Sign-on feature
Date Fri, 24 Sep 2004 23:35:32 GMT
For more clarity the component should be called SingleSignonComponent.

David Sean Taylor wrote:

> David Le Strat wrote:
>> Roger,
>> This is great. I have a couple questions/comments. See below.
>> --- Roger Ruttimann <rogerrut@apache.org> 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 

>>> 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

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message