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: <4159E65B.9070809@apache.org>
Date: Tue, 28 Sep 2004 15:31:55 -0700
From: Roger Ruttimann <rogerrut@apache.org>
Reply-To: rogerrut@apache.org
Organization: Web Portal
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
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> <4157EA1D.9020306@jahia.com>
In-Reply-To: <4157EA1D.9020306@jahia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Serge Huber wrote:

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

With this and the other earlier suggestions I move forward starting 
implementing SSO for J2

Roger


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


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