AUTHN_CONTEXT Functionality in v3

Cantor, Scott cantor.2 at osu.edu
Tue Apr 14 11:17:57 EDT 2015


On 4/14/15, 10:22 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>In v2 we leveraged a feature (undocumented afaict) whereby we could set a request attribute called AUTHN_CONTEXT (e.g. via servlet filter) to a value that would pass through to the outgoing SAML response as the AuthenticationMethod.
>The use case was defining the authentication method based on artifacts of a remote user authentication event. I don't see any equivalent mechanism available in v3, and it appears the data model maps a flow definition onto a single authentication method, which doesn't really accommodate this use case. I would appreciate some pointers on how we might accommodate this use case in v3.

This is all much more complex now to fix the unending stream of bugs related to context classes and downgrade attacks, and to try and automate so many complicated use cases.

None of the existing flows are really designed to leave the choice up in the air. You configure each flow with what it supports, and then it does something, and the code just auto-adds all of the special Principals it supports to the Subject coming back and then later on it picks one to use in the response. Everything is cross-checked over and over to prevent it from sending back Foo if the SP requests Bar.

There's a lot of internal machinery that can override this, but it's not really used out of the box, I just put it there to support customization later.

The External flow is slightly more powerful in that you can populate a Subject yourself and return exactly the Principal collection you want, but out of the box it's not that usable for that because the engine will still auto-add the supportedPrincipals collection from the flow descriptor to the Subject at the end. I didn't think that part through all that well.

I've reviewed the code a bit and even some of what I was expecting to use to override behavior probably won't work as well as I thought, it's still too rigid for this use case.

So I guess in a nutshell, it would take a custom login flow to do it right now. A custom flow can avoid the built-in assumptions and return whatever it wants as the Subject. The only caveat is that it had better be compatible with the SP's request or it will fail before it finishes up.

I'll file an issue so I can review some of the code again, I think there are some adjustments or additions we can make to provide more flexibility here.

-- Scott



More information about the users mailing list