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

On 1/7/07, i2ware i2ware <i2coder@gmail.com> wrote:
> 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

Ah, I see.  Okay, in that case the easiest thing to do (it seems) is
for the TB to issue its own transient identifier.  If the IdP asserts
a persistent identifier to the TB, the TB could use that, I suppose,
but the NameQualifier would not change as the identifier flows across

It is the re-assertion of attributes that is most interesting.  Does
the TB repackage the attributes and assert them as its own, or pass
the assertion from the IdP to the SP so that the latter can make its
own decision.  From the scenario that you've described, it seems you
intend to repackage and re-assert the attributes, but that raises some
issues depending on the trust relationships between the various

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

The TB asserts no new information of its own?  Does the SP trust the
IdP?  If so, you might consider using a <thrpty:RespondTo> element:


Hope this helps,

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