Returning an AuthnContextDecl using Sibboleth3 external auth

[Cantor, Scott]

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

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

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.

-- Scott