Returning an AuthnContextDecl using Sibboleth3 external auth

[Stefan Santesson]

Thanks Scott,

This saved me a-lot of searching in vain..

Let me explain what I need then, and hope you can explain the best way to
do it, if at all.


We have a particular situation where the IdP need to show some data
provided by the requesting SP.
(Will explain further if needed - Basically the SP is a signature service
and the message is information about what the user agrees to sign upon
successful authentication)

This is included in an extension of the request.

So far so good. The external servlet have access to the request and parses
the extension for the data.

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.

We are looking into
 1) Including the receipt in an attribute
 2) Including the receipt in an AuthnContextDecl

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.

Is there any hope for us?

The fallback solution, which we in the end will have to choose is to
define a new AuthnContextClassRef for each LoA that includes a requirement
to show the message, preventing non-conformant IdP:s from serving the
request at all.
Then perhaps we could omit the receipt all together.

/Stefan



On 12/05/15 15:49, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 5/12/15, 4:26 AM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>>
>>We are testing Shibboleth3 IdP in the Swedish national federation and
>>I¹m stuck in my efforts to return an AuthnContextDecl and even setting
>>the appropriate AuthnContextClassRef from my external auth servlet to
>>the Shibboleth3 IdP.
>
>We have no support for AuthnContext declarations, we never have. We
>support ClassRef or DeclRef (but not both, since that's not legal).
>
>>On the input side to the external auth servlet I have more than I need.
>>The key here for me is the profileRequestContext request attribute
>>providing the full AuthnRequest.
>
>You should *not* in general ever evaluate SAML in a login flow. If you're
>looking for data about the RequestedAuthnContext, it's transformed into a
>RequestedPrincipalContext in the tree so that it's protocol neutral.
>
>>The content of the request will influence the processing in the IdP and
>>I¹m supposed to return both the actually performed AuthnContextClassRef,
>>but even more importantly, result data in a AuthnContextDecl.
>
>Not supported, at least without doing your own copy of the SAML flow and
>writing new Java code.
>
>>In Shibboleth2 IdP I could influence the AuthnContextClassRef through
>>the now deprecated authnMethod attribute.
>
>Yes, but not the Decl.
>
>Class handling is automatic for the most part, but there are limitations
>on doing this more dynamically, the design's not there yet. Too much of
>the automation gets in the way. You can explicitly return a Subject with
>your choice of custom Principal objects (namely
>AuthnContextClassRefPrincipals), but the flow engine will add in all the
>custom Principals established on the flow descriptor, which likely
>contaminates whatever you're trying to do. Marvin asked a similar
>question a couple of weeks ago.
>
>>Is the input request attributes also working as output request
>>attributes, that is, can I return a profileRequestContext to the IdP
>>with the data above? (it seems to have an outbountMessageContext)
>
>No.
>
>>If so, How am I supposed to include the data in this generic object?
>
>Generally speaking you're supposed to return a Subject, but it probably
>won't do what you need it to in the end (and it will never generate a
>declaration).
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net