RE: AuthnRequest usage - 'recognize' principal

From
Cahill, Conor P <>
Date
2013-08-02T14:08:21+00:00
ID
Thread
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.

 

Conor

 

From: Lucas, Mike [mailto:]

Sent: Friday, August 02, 2013 9:41 AM

To: 

Subject: [saml-dev] AuthnRequest usage - 'recognize' principal

 

I am trying to determine if our usage of Subject in the AuthnRequest might violate
section 4.1.4.1 "<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?

Thanks

michael lucas  |  Senior Software Developer  |  Great-West Life