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] Subject in the AuthRequest.


Title: Subject in the AuthRequest.
Thanks.
 
in this case:

"The IdP needs to consider whether or not the requestor is allowed to specify its own key."

If from I guess its policies the IDP allow the key, would then build an assertion (after authentication) with the same subject+confirmation as specified in the request (is this a MUST/MAY or SHOULD)?

Giuseppe.



From: Cahill, Conor P [mailto:conor.p.cahill@intel.com]
Sent: 20 September 2006 15:38
To: Sarno, Giuseppe (MOP:GM15); saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Subject in the AuthRequest.

 

In the AuthRequest there is a <saml:Subject> tag where the requestor can specify the subject of the resulting assertion.

Can anyone please give an example/use case ? I thought it was the IDP during AuthReq to determine the Subject.
If the SP knows the subject (I'm assuming that somehow the subject had to be previously authenticated and an assertion generated) wouldn't it perform an AssertionQuery kind of request instead ? 

AuthnRequest with a subject would typically be used if you wanted to initiate an SSO session with a specific user.  This may be because you are running into the end of a session validity period on an existing assertion (and want to renew for the same user) or you want to change the subject that was previously authenticated in the current "session".

AuthnQuery is how you query for an *existing* assertion, not create a new assertion for a new or extended SSO session.

Subject can contain subject confirmation data to indicate how and by whom the resulting assertions can be confirmed.
In the case of holder of key for example the SP would include the Key the SP owns to confirm the subject.
Shouldn't the IDP verify this key?  

This is typically used in non-SSO cases where the requestor is asking for an assertion for a different relying party AND saying that such assertion(s) should require the confirmation of the specified key in order to be  used.  

The IdP needs to consider whether or not the requestor is allowed to specify its own key, but typically doesn't need to verify the key.

Conor



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