OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [saml-dev] FW: Products and OSS that support SAML2 AssertionXML reuse


Thanks Scott,

Our use case is to extend user authentication from one application (SAML SSO) to other applications(web services) where both apps reside at the same IDP. The user is identified/has a record at each service provider resource with different pseudonymous references. The references cannot be shared between SPs for privacy reasons. The following are the sequence of steps;

1. The service provider's resource (SP1) redirects user to IDP using SAML2 WebSSO profile.
2. IDP presents the user with logon page. The user enters their credentials and submits them at IDP.
3. IDP returns SAML2 assertion to the requesting service provider (SP1) resource. So the user is now authenticated at SP1.  SP1 requires to interact with another service provider's (SP2) resource(s) to obtain further details about user in order to deliver service. (Note that user consent for the following steps/transaction has been requested and given). 
4. Because the user is authenticated to SP1, the pseudonymous reference can be exchanged for an opaque token at the IdP's STS (WS Trust) Service to identify the user at SP2. The opaque token is created using PK Crypto to prevent disclosure of the users pseudo reference at SP1. SP1 requests STS(WS-Trust service) at the IDP for a token with the IDP issued authenticated assertion for that user at SP2, and the other SP2's resource identifier.
(5. In our scenario both IDP and STS are co-located. STS validates the signature of IDP issued assertion and checks timestamp. If both are valid then issues a token for user so that he can be identified at SP2. The token contains pseudonymous reference of the user at SP2's resource.)
6. Upon receiving the token from the IDP/STS, SP1 requests SP2 about user with the STS issued token.
7. SP2 identifies the user based on pseudo reference inside the token, processes the request and returns requested information about the user to the requesting service provider.   

Putting aside the fairly complex message flow (which was not the point at this moment), does this make more sense about the question of 'persistence'? In our use case the service provider resource 're-uses' original IDP assertion to obtain user token from the IDP/STS that can be used to identify user at other service provider. 

Our previous questions are related to feasibility of our use case to work with SAML2 products. If they allowed the re-use of the original IDP issued assertion, then our integration and any customisation work is considerably lessened.

Hopefully this time we are clearer on our question.


Thanks
Venkat (and Colin, probably unhelpfully editing..)  

-----Original Message-----
From: Cantor, Scott E. [mailto:cantor.2@osu.edu] 
Sent: Thursday, 14 July 2011 1:51 a.m.
To: Colin Wallis; saml-dev@lists.oasis-open.org
Subject: Re: [saml-dev] FW: Products and OSS that support SAML2 Assertion XML reuse

On 7/13/11 1:43 AM, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:

>Hi Folks
> 
>I'm wondering if you can help
>out one of our developers with this question?
> 
>We have a requirement to later
>reuse the SAML2 Assertion document
>(i.e. XML) issued by IDP.

Generally you *can't*, depending on what you intend to use it to do. That
depends on the assertion's content.

> 
>1) Do you know of any (and how
>many) SAML2 SP products do persist IDP
>issued assertion XML after parsing XML?

Define "persist". Persist where?

> 
>2) If most products
>don't persist it, then what is the rationale behind not
>doing so?

SSO assertions by design are generally single use and short lived and
certainly not forwardable.

-- Scott

====
CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.
====


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]