Returning an AuthnContextDecl using Sibboleth3 external auth
Cantor, Scott
cantor.2 at osu.edu
Tue May 12 13:38:21 EDT 2015
On 5/12/15, 12:44 PM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>
>This is included in an extension of the request.
Ok, that would be an obvious exception to the "don't look at the SAML" rule.
>The IdP should now (ideally) return a receipt that it actually showed the
>data in the generated assertion. This to distinguish a conforming IdP from
>one that simply ignored the extension.
Sure. I don't really think that's a use case for AuthnContext.
>I don¹t like the attribute path since we are using a data base to resolve
>the attributes. I don¹t want to put this into the user database, because
>it is not related to the user per se, just the authentication instant.
Attributes can come from anywhere, not just a database, but regardless:
It is inevitable IMHO that people will eventually give up on using AuthnContext and its various clones and just go back to using attributes, even for things that actually fit the AuthnContext purpose. Once you start dealing with data that's not a simple constant, there is no other path to take. Nothing supports the AuthnContextDecl schema.
I don't know that the only two options are AuthnContext and Attributes. Extension statements or conditions are also possible, as is Advice. Any of those still involves copying the flow to add the new action(s). There is no hook for customizing the assertion at present.
>Is there any hope for us?
Well, not unless you do what I mentioned, copy the flow and extend it with your own action(s). We designed the flows to be easy to add new features to, but that doesn't mean they have an endless number of hooks you can just plug into now. It's a small amount of code to add to do something new, but it's not possible to get it to run without copying the flow so it can be wired in.
-- Scott
More information about the users
mailing list