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] SubjectConfirmation in SAML query

ok, thanks. So the SP is "client authenticating" the "user" and using
information in the X509 of the user to get their attributes.

The IdP takes no part in the authentication of the user.

Presumably the location of the IdP can be inferred from the contents of
the X509.

> All that's needed is an extension
> so the requester can ask for a specific set of attributes
yes that would be very handy indeed. AttributeConsumingServiceIndex
doesn't seem to be of too much use for dynamic attribute requests.

This looks interesting for machine to machine as well and passing tokens
between SPs when using web services (sorry!). If an aggregating SP passes
the extended AuthnRequest it constructs to other services it has a
relationship with, those other services can use that AuthnRequest to get
their own attributes.

The interesting question for me is how to authenticate those other
services at the IdP. If the IdP trusts SP1 then perhaps it could trust
those SPs that SP1 trusts. SP1 signing an AuthnRequest and setting the
AssertionConsumerServiceURL to SP2's service would be interesting for
n-tier machine to machine.


mov eax,1
mov ebx,0
int 80h

> On 2/11/07, Alistair Young <alistair@smo.uhi.ac.uk> wrote:
>> > define an AuthnRequest Extension to allow
>> > for
>> > tunnelling Attributes to use as a query
>> can you explain a bit more about this please? What do you mean by
>> "tunnelling"?
> A principal can use AttributeQuery to self-query for attributes.  See,
> for example, section 4 of this deployment profile:
> http://www.oasis-open.org/committees/download.php/21568/sstc-saml2-profiles-deploy-x509-draft-01.pdf
> Scott is suggesting to use AuthnRequest instead of AttributeQuery,
> since AuthnRequest is much richer.  All that's needed is an extension
> so the requester can ask for a specific set of attributes.  Then
> AuthnRequest will be able to do everything that AttributeQuery can do,
> and much more.
> Hope that helps,
> Tom

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