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] SAML 2.0 - Name Qualifier Question


Hi,

 

>>TB does federate identifier.

>>What I meant was the TB doesn't maintain any user information in its repository (persistence). Once the user federates from IDP to TB, TB verifies the saml response document and if it is valid then maintains the user information(subject value and attributes) sent by IDP in session and it then displays the list of websites the user can access (sp websites). The user clicks on the website, TB federate the user information (contains the value sent by IDP) to SP, the SP then validates and create necessary credentials and route the user to website.

This scenario can be broken into two IDP-SP sub scenarios

  1. idp1 as IDP and TB as SP

< saml:NameID Format=" urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier=" idp1.com"> joe</ saml:NameID>

  1. TB as IDP and sp1,sp2 etc as SPs

< saml:NameID Format=" urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier=" tb.com"> joe</ saml:NameID>

 

Thanks,

Mrigank.

 


From: i2ware i2ware [mailto:i2coder@gmail.com]
Sent: Monday, January 08, 2007 6:30 AM
To: Tom Scavo
Cc: saml-dev@lists.oasis-open.org
Subject: Re: [saml-dev] SAML 2.0 – Name Qualifier Question

 

Thanks Tom & Scott for the response.

> Note: TB doesn't maintain any Identity just a pass through.

This is an important observation.  If the TB does not federate
identifiers, what exactly does it do?
 

TB does federate identifier.

What I meant was the TB doesn't maintain any user information in its repository (persistence). Once the user federates from IDP to TB, TB verifies the saml response document and if it is valid then maintains the user information(subject value and attributes) sent by IDP in session and it then displays the list of websites the user can access (sp websites). The user clicks on the website, TB federate the user information (contains the value sent by IDP) to SP, the SP then validates and create necessary credentials and route the user to website.

On 1/7/07, Tom Scavo <trscavo@gmail.com> wrote:

On 1/7/07, i2ware i2ware < i2coder@gmail.com> wrote:
>
> Note: TB doesn't maintain any Identity just a pass through.

This is an important observation.  If the TB does not federate
identifiers, what exactly does it do?

> The SPs maintain the user identity based on IDPs domain name for
> authorization purpose.
>
> In this scenario, what is the standard way to define in SAML document to
> identify the user uniquely when Trusted Broker sends a saml response to sp?

Well, SAML has no notion of "Trusted Broker" so this is not a standard
scenario.  In any event, if the TB does not federate identifiers, it
has no choice but to use the identifier produced by the IdP.

> Is below subject nameid correct? Or should NameQualifier be the TB domain
> and the primary IDP should be mentioned in the BaseID?
>
> < saml:NameID Format=" urn:oasis:names:tc:SAML: 2.0:nameid-format:persistent"
> NameQualifier=" idp1.com"> joe</ saml:NameID>
>
> Or
>
> < saml:NameID Format=" urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
> NameQualifier="tb .com">joe </ saml:NameID>

The spec is pretty clear about this.  The NameQualifier refers to the
IdP that produced the identifier, which is idp1.com in this case.

> < saml:BaseID Format=" urn:oasis:names:tc:SAML: 2.0:nameid-format:persistent"
> NameQualifier="idp1 .com" SPNameQualifier=" sp1.com"></ saml:BaseID>

The BaseID element is derived from an abstract type, so the above is
not correct.  You would need to extend the saml:BaseIDAbstractType and
specify the type of the BaseID element to have this new type.

Tom

 



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