Re: [saml-dev] Authentication Responses

[<philippe.beauchamp@bell.ca>]

Thanks Scott...

I may have misrepresented the situation a bit.

The proposal here is to have a link on the login page which would allow users to register if they don't have an account already. Normal flow for authntication however is to supply the credential and go back to the SP with an authentication response and assertion.

Part of the question is whether the saml specifications consider a user initiated action (such as clicking a link to perform a different action) to be a break in the saml authentication flow and therefore outside of the bounds of the specification; or whether they are stating that user navigations from the authentication flow need to result in navigating the user back to the SP with an authentication response.  

It actually goes beyond registration as any links off of the login page have similar issues; as would users clicking on bookmarks... If the spec is saying that idps must always return authentication responses to authentication requests.

Clearly some user actions are out of scope for the idp, such as if a user clicks on a bookmark to an external site, like google.com. In these the idp no longer has access to the end user no can't send a response through browser bindings; however section 4.1.4.1 seems to indicate that all requests must be returned...

Or... Am I misinterpretting and that section is simply referring to idps returning failed responses if the requests can't be interpretted; and putting up the login page is appropriate support for a request; as is sending back a successful response for a valid credential; and any user action taken to move away from the login flow is out of scope...


To put it another way; if an IDP doesn't send back an auth response for events where the user has left the login page; or events such as failed authentication or lockout... But does provide links back to SP sites and does return failed auth response messages to requests that can't be interpretted or are invalid; Are they breaking the saml specs?






Philippe R. Beauchamp
Senior Solutions Architect 
Identity & Security Event Management Services
Enterprise Group 
Bell Canada 
Phone:            613-781-8953
Cell:                 613-327-6928 
Conf. Bridge: 613-787-5146
Conf. Bridge: 866-797-9104 
Conf. ID:         6444571 




----- Original Message -----
From: Scott Cantor <cantor.2@osu.edu>
To: Beauchamp, Philippe (6009210); saml-dev@lists.oasis-open.org <saml-dev@lists.oasis-open.org>
Sent: Tue Dec 08 18:10:09 2009
Subject: RE: [saml-dev] Authentication Responses

philippe.beauchamp@bell.ca wrote on 2009-12-08:
> We have a case where the Login Page at the Identity Provider may take the
> user into other flows initiated by the user, such as registering for a new
> credential.  Is the IdP obligated to respond with a authentication
response
> to the SP?

Eventually, yes, or you're feeding into the paranoia that some SPs have
about "giving up control of the user". With SP-initiated SSO, the SP is
telling the IdP to respond with an error or an assertion, and that's all we
can say.

> Under what situation(s) do I NOT have to respond back with a SAML
response?

It's a non-testable requirement, of which there are many. You have to apply
reasonable judgement. Users can always choose to jump out at any point, but
making that a likely outcome tends to result in a confusing overall user
experience from the point of view of the SP.

If somebody has to register in real time, that doesn't have to completely
interrupt a login flow, except that identity vetting that ends up being
asynchronous (e.g., email verification) tends to be impossible to coordinate
well from what I've seen. Really, federation should reduce that need. If we
have to constantly walk users through account registration in a federation
scenario, that's a red flag for the deployment.

-- Scott