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

Title: AuthnRequest usage - 'recognize' principal

If a subject is specified in the AuthnRequest and the request results in a successful response with an assertion, it is expected that the subject in the assertion matches the Subject in the request (that’s what it means to include the subject in the request – the SP is asking you for an assertion about this particular subject, not just any subject).


If you are including that subject in you’re Assertions, then you should be doing more than just logging it.   You really need to ensure that you can authoritatively assert that subject in this context (as in you have authenticated that subject).


If you are just logging the subject, but generating a successful response with a different subject, they you are not correctly processing the request since they asked for an assertion for subject A and you’re returning an assertion for subject B.


The subject in the request should match a subject that you have provided for them at some point in the past (or have shared through some out-of-band mechanism) and should be *known* in your context – that’s the identity of the user that you should be authenticating and generating assertions for.




From: Lucas, Mike [mailto:Mike.Lucas@gwl.ca]
Sent: Friday, August 02, 2013 9:41 AM
To: saml-dev@lists.oasis-open.org
Subject: [saml-dev] AuthnRequest usage - 'recognize' principal


I am trying to determine if our usage of Subject in the AuthnRequest might violate section "<AuthnRequest> Usage" of the Web Browser SSO Profile, particularly lines 525-528 (in saml-profiles-2.0-os.pdf) which states:

Note that the service provider MAY include a <Subject> element in the request that names the actual

identity about which it wishes to receive an assertion. This element MUST NOT contain any

<SubjectConfirmation> elements. If the identity provider does not recognize the principal as that

identity, then it MUST respond with a <Response> message containing an error status and no assertions.

In the case where we are acting as the identity provider, we were planning on accepting the Subject name (userid on Service Provider system) and just logging it for audit/debugging purposes. We don’t have any way to verify that the user is actually that user, but we do trust the contents of the AuthnRequest – so if the Service Provider says that’s the principal we believe them (it’s their user). Is that trust good enough to satisfy the word ‘recognize’ above? Should we maybe also make it part of our interface that if Subject is present, we want the Subject SPNameQualifier to equal Issuer?


michael lucas  |  Senior Software Developer  |  Great-West Life

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