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] AuthnRequest usage - 'recognize' principal


On 8/2/13 9:40 AM, "Lucas, Mike" <Mike.Lucas@gwl.ca> wrote:

>In the case where we are acting as the identity provider, we were
>planning on accepting the Subject name (userid onService Provider system)
>and just logging it for audit/debugging purposes. Wedon¹t have any way to
>verify that the user is actually that user, but wedo trust the contents
>of the AuthnRequest­ soif the Service Provider says that¹s the principal
>we believe them (it¹s
> their user).

No, it's your user too. If not, how could you be authenticating them?

As Conor said, if you don't have a way to map from the Subject to a
principal in your system, you MUST fail the request. And unless the SP has
a good reason for specifying Subject, it shouldn't do so.

You don't have to return the exact same Subject, just a Subject that
represents the same principal in your system, and that meets the requested
NameIDPolicy, if any.

The point of a Subject element there is to provide a round trip guarantee
about the user identity to match back to something the SP has determined,
and as a minimal sort of NameID Mapping capability during SSO.

The primary purpose of that element is not for Web SSO, it's for stand
alone token request use cases.

-- Scott




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