AuthenticatingAuthority element

Janne Lauros janne.lauros at csc.fi
Wed Jan 25 09:54:35 EST 2017


Hi!

 I was hoping to find possibility to set the information in authentication or postsso flow before the assertion is formed but it was not going to happen. Yes, we do have to sign assertions and we also do need to have the element in place so I will have to go the hard way, hopefully still not having to modify flows. Thank you for confirming this.

 Br Janne

----- Original Message -----
From: "Scott Cantor" <cantor.2 at osu.edu>
To: "users" <users at shibboleth.net>
Sent: Tuesday, 24 January, 2017 16:46:21
Subject: RE: AuthenticatingAuthority element

>  We have SAML2 proxies based on shib sp 2  and shib idp 3. To clean their acts
> the proxies would need to populate AuthenticatingAuthority element to
> follow the specification.  I am failing to find a feasible  way to do that. Is there
> a way to to have  AuthenticatingAuthority element populated with IdP 3?

There's nothing like a setting that just does it, no. That's a fairly simple RFE.

In the mean time, that's a bit tricky without modifying flows unless you assume unsigned assertions (meaning the default behavior, with the response signed). Assuming that, you probably could do this by plugging in an outbound interceptor flow with an action bean that adds this to the assertion, which is inside the outbound message context.

The outbound interceptor hook is empty/undefined in the SAML flows right now, so there's nothing particularly weird about hooking it, everything else should continue to work.

If you wanted to accomodate signed assertions, that's harder. You'd either have to be modifying the flows or you'd need to duplicate the signing logic itself and adding it to your outbound interceptor.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list