SAML2 IdP Extension

[Cantor, Scott]

On 3/26/15, 9:44 AM, "Romstorfer, Georg" <Georg.Romstofer at cryptas.com> wrote:

>I’m trying to develop an extension for the Shibboleth Idp V3. My requirements are the following:
>-         
>The SP sends a SAML2 AuthnRequest containing a certificate in <samlp:Extensions>
>-         
>My Idp extension should take this certificate, encrypt the resolved attributes with it and put them in the Advice-Tag of the AuthnResponse

That sounds more like a use case for multi-casting encrypted data under different keys, which is something we put a little bit of pre-design work into but isn't really built.

> 
>In V2, I would have extended the SAML2ProfileHandler, but in V3 I don’t know where to start.

You would have to read a lot of code, there's nowhere else you're going to be able to figure out how it works right now. And it's not really an easy design to understand, there are a lot of complex relationships between flow files that make up the SAML flows.

>I already looked into these documents and files, but I think I need a little more help.

You'll need a lot more help, but I can't really give it to you, not in detail.

>My understanding so far is, that I have to override the whole SAML2 web-flow,
>and inject a custom action somewhere at the beginning of the flow to extract the certificate
>and a second action after the AttributeResolution or BuildResponse action to encrypt the attributes.

Well, you can plug into the flows without copying them at some specific points, but those may or may not be workable for you. You can build an interceptor flow that runs after authentication and attribute resolution/filtering, but that runs before the assertion is built. You could conceivably plug that in to do most of the set up work and save off the necessary state.

At the very end, another type of plug point exists that runs another interceptor flow before passing control to the outbound message handling actions. That isn't normally used in the SAML flows, but you might be able to use that to add the data to the assertion.

>Maybe it is also possible to implement only the second action at the end if the request can be accessed from there?

It can always be accessed, we have a tree of objects that carry the state of all the input and output for the life of a request.

-- Scott