Re: [saml-dev] Authentication Responses

[<philippe.beauchamp@bell.ca>]

Thanks again, Scott, that helps.


So in summary (and we'll see if I get this right ;) ...

- IdPs need to respond with auth responses on successful user flows. 
- Failed responses need to go back when requests are malformed or can't be interpretted
- Failed responses may or may not go back on error states for users (like lockout). This depends on implementation details and user experience
- Responses may or may not go back to SPs in cases where users have left the login flow. (Including cases like a like to  registration from the login page). IdPs should have a best effort in these cases, factoring in implementation details and user experience; but these situations are outside of the scope of the saml specifications per se.


Does that pretty much sum it up?








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 21:29:59 2009
Subject: RE: [saml-dev] Authentication Responses

philippe.beauchamp@bell.ca wrote on 2009-12-08:
> 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.

That's not unusual.

> 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.

My original response was trying to say that the answer is "both". Yes, it's obviously out of scope what the login looks like or what the user does in the middle of it, but the actions taken by the IdP are supposed to result in a response when that's practical.

In practice people violate this guideline all the time (e.g., when the login is unsuccessful for some reason), but that's one of the reasons you'll hear potential SPs fret about the fact that once they send the user away to login, they can't count on the user coming back. People are easily distracted. ;-)

So, again, it's a judgement call. One error might need to be reported to the user and then action taken, and another might be silently logged and a response issued. It depends. That's the only answer I can think of.

> 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.

Which is why it's an untestable/unenforceable requirement. The exception is in cases where errors result from specific SAML processing, where nothing else would be expected to intervene 

> 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...

That's an overly strict interpretation. You can't return a response in those cases. The browser profile requires the browser bindings, that's unavoidable.

> 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...

All of that is true, but "putting up the login page" is not IMHO always sufficient to let the IdP off the hook in all cases. Some though, maybe most. I guess if you pressed me, I'd have to come up with a specific scenario, but one thing that comes to mind is the idea of giving the user a visible means during login of saying "no, I don't want to keep trying this, please send me back".

> 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?

No, I think that's the general summary I'm trying to give above.

-- Scott