portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Proposal Single Sign-on feature
Date Fri, 24 Sep 2004 22:59:13 GMT
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.
>>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



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.

> 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 


> 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

>>For the first implementation two modes will be
>>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
>>returned by the lookup (site, principal).
>>At a later stage the SSOCredential API could be
>>extended with 
>>certificates and cookie based authentication.
>>The credentials for the site can be entered in two
>>--> 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.


David Sean Taylor
Bluesunrise Software
[office] +01 707 773 4646
[mobile] +01 707 529 9194

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

View raw message