Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4157EA1D.9020306@jahia.com>
Date: Mon, 27 Sep 2004 12:23:25 +0200
From: Serge Huber <shuber2@jahia.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
Subject: Re: [J2] Proposal Single Sign-on feature
References: <20040924223726.87279.qmail@web40203.mail.yahoo.com>
 <4154A6C1.5050004@bluesunrise.com> <4154AF44.1030105@apache.org>
 <4154B6CF.3020302@apache.org>
In-Reply-To: <4154B6CF.3020302@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Just some food for thought while we're on the object of SSO : maybe it 
would be a good idea to make this component as self-standing as 
possible, so that it may even be started without J2 ?

I thought about this because from the planned features it seems like 
this has the potential to become a server that would be sufficient for a 
lot of SSO needs.

Regards,
  Serge Huber.

Roger Ruttimann wrote:

> 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 <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 
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


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