Returning an AuthnContextDecl using Sibboleth3 external auth
cantor.2 at osu.edu
Tue May 12 20:35:54 EDT 2015
On 5/12/15, 8:52 PM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>Yes, the source is not the issue. Binding it to a particular
>authentication instant is. But perhaps just because I don’t know all
>features of IdP V3 yet.
I'm not sure what you mean by "bind", and I doubt V3 is the issue, but you
can generate attributes at runtime all you want. With a script if nothing
>I don’t know how to do that yet, but I’ll try to figure it out. If you
>have any good pointers on info how this is done I’d be happy.
No, I don't. Not for a while, that's down the list of documentation tasks.
Documenting custom login flows is much more critical right now.
You'd have to create a custom profile flow by copying the SAML flow
machinery in system/flows/saml, put it in flows/ using the right filename
conventions, copy the bean file(s) over for import (understanding all of
those classes can change, breaking your version), and wire new beans into
the copied flow to do new things. It's not intended, in other words.
>Finally, what is the intended mechanism for an external auth servlet to
>communicate what ClassRef alt DeclRef it just performed, in order to get
>it included in the assertion?
In V3, the authentication engine knows nothing about SAML. It deals in
Subjects and Principals. AuthnContextClassRefs are modeled as
AuthnContextClassRefPrincipal objects. AuthnContextDeclRefs are modeled as
AuthnContextDeclRefPrincipal objects. Login flows "support" one or more
custom Principals, and requests can supply Principals to match and
comparison operators to satisfy and that's how it selects flows to
attempt. Flows have to return Subjects containing custom Principals and
one or more of them has to satisfy the request or it just fails the
The intended mechanism is that External servlets that care about this sort
of thing return a complete Subject with the appropriate custom Principals
added. If you want to include a specific ClassRef, you add an
AuthnContextClassRefPrincipal to the Subject. If there are no other such
Principals in the Subject, and the Principal satisfies the context
comparison engine (assuming the SP requests anything to start with), then
that's the one it will use in the assertion.
The problem is that the External flow implementation (and in fact all the
built-in flows) will automatically add in all custom Principals configured
for the flow in general-authn.xml, which means any attempt to "subset" the
flow's capabilities with just a specific Principal will just be
overwritten by the full set anyway, and it won't do what you want in most
cases, or at least it isn't likely to.
I have a bug open to work on it some more, but at the end of the day,
complicated requirements require writing custom login flows, just like
they require custom login handlers now.
>It was not evident to me in the wiki. Or is it: what was requested, is
>what gets returned?
The Subject contains any number of Principals that express these kinds of
semantics. The engine selects one of them at the end to use.
If an SP requests an exact match, then you have no choice. You have to
return that, or you fail. The engine will only select login flows to run
that can supply that matching Principal, which is why you have to add them
to the descriptors in general-auth.xml to start with. And if the Subject
produced doesn't contain a matching Principal, then it will fail.
>To me that is not always true. I could do better than
>what was requested, or different but equivalent.
Not unless the SP doesn't request exact matching. "Equivalent" is not
allowed unless "maximum" or "minimum" is used, for example. The IdP takes
great pains to prevent you from circumventing that requirement.
More information about the users