You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Roger Ruttimann <ro...@apache.org> on 2004/09/25 00:21:01 UTC
[J2] Proposal Single Sign-on feature
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.
Introduction
----------------
Since a user is logged in into the portal he/she should never be asked
to login again to see any content. Web portlets or IFrame portlets which
refer to external (to the Web Portal) sites might be only visible after
a login (if the target site requires authentication). This behavior can
be annoying especially if the portal integrates different applications
that all require authentication.
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).
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.
Planning
------------
I plan to start working on the SSO implementation a.s.a.p.
Any comments/suggestions are highly appreciated.
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Proposal Single Sign-on feature
Posted by Roger Ruttimann <ro...@apache.org>.
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 <ro...@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
Re: [J2] Proposal Single Sign-on feature
Posted by Serge Huber <sh...@jahia.com>.
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 <ro...@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
TestCapability Broken
Posted by David Le Strat <dl...@yahoo.com>.
All,
TestCapability is broken. I will comment it in my
soon to come commit.
The error is below. Not sure when we started getting
this:
------------- Standard Error -----------------
java.sql.SQLException: Unexpected token:
MEDIATYPE_TO_MIMETYPE in statement [SELECT
A0.TITLE,A0.MEDIATYPE_ID,A0.CHARACTER_SET,A0.NAME,A0.DESCRIPTION
FROM MEDIA_TYPE A0 INNER JOIN (MEDIATYPE_TO_MIMETYPE
A1 INNER JOIN MIMETYPE A2 ON
A1.MIMETYPE_ID=A2.MIMETYPE_ID) ON
A0.MEDIATYPE_ID=A1.MEDIATYPE_ID WHERE A2.NAME IN
('text/html','text/xml','text/xhtml')]
at org.hsqldb.Trace.getError(Unknown Source)
at org.hsqldb.Result.<init>(Unknown Source)
at org.hsqldb.jdbcConnection.executeHSQL(Unknown
Source)
at org.hsqldb.jdbcConnection.execute(Unknown Source)
at org.hsqldb.jdbcStatement.fetchResult(Unknown
Source)
at org.hsqldb.jdbcStatement.executeQuery(Unknown
Source)
at
org.hsqldb.jdbcPreparedStatement.executeQuery(Unknown
Source)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:92)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl.java:283)
at
org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(RsQueryObject.java:74)
at
org.apache.ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:183)
at
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(RsIteratorFactoryImpl.java:58)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(PersistenceBrokerImpl.java:1808)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBrokerImpl.java:1333)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:111)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:233)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:253)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1217)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
at
org.apache.jetspeed.components.persistence.store.ojb.pb.PBStore.getCollectionByQuery(PBStore.java:182)
at
org.apache.jetspeed.capabilities.impl.JetspeedCapabilities.getMediaTypesForMimeTypes(JetspeedCapabilities.java:330)
at
org.apache.jetspeed.capabilities.impl.JetspeedCapabilities.getCapabilityMap(JetspeedCapabilities.java:184)
at
org.apache.jetspeed.capabilities.TestCapability.testCapability(TestCapability.java:86)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
junit.framework.TestCase.runTest(TestCase.java:154)
at
junit.framework.TestCase.runBare(TestCase.java:127)
at
junit.framework.TestResult$1.protect(TestResult.java:106)
at
junit.framework.TestResult.runProtected(TestResult.java:124)
at
junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536)
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Proposal Single Sign-on feature
Posted by Roger Ruttimann <ro...@apache.org>.
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 <ro...@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
Re: [J2] Proposal Single Sign-on feature
Posted by Roger Ruttimann <ro...@apache.org>.
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 <ro...@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
Re: [J2] Proposal Single Sign-on feature
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Le Strat wrote:
> Roger,
>
> This is great. I have a couple questions/comments.
> See below.
>
> --- Roger Ruttimann <ro...@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
Re: [J2] Proposal Single Sign-on feature
Posted by David Le Strat <dl...@yahoo.com>.
Roger,
This is great. I have a couple questions/comments.
See below.
--- Roger Ruttimann <ro...@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).
Will the SSOCredential basically become another type
of credential in the security framework? Or am i
missing something?
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).
> 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.
Regards,
David Le Strat.
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org