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

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


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

-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[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


Mime
View raw message