Add HSM Support for Decrypting Assertions

[jzheaux]

It would be nice to allow for a custom decryption strategy in OpenSamlAuthenticationProvider. This would simplify delegating the assertion and principal decryption to a separate service.

[jzheaux]

Currently, OpenSamlAuthenticationProvider has a private field Converter<Saml2AuthenticationToken, Decrypter>. I'm not convinced that Decrypter is the correct thing to expose, though. I'd prefer that it be an interface. Since OpenSAML doesn't provide an interface for decryption, we could possibly use Consumer.

So, instead of:

Decrypter decrypter = // ... your custom decrypter
provider.setDecrypter((token) -> decrypter);

you'd do:

YourDecrypter decrypter = // ... your custom decrypter
provider.setResponseDecrypter((tuple) -> {
    EncryptedAssertion encrypted = tuple.getResponse().getEncryptedAssertions().get(0);
    Assertion assertion = decrypter.decrypt(encrypted);
    tuple.getResponse().getAssertions().add(assertion);
});

Or, for decrypting an assertion's subject, you'd do:

YourDecrypter decrypter = // ... your custom decrypter
provider.setAssertionDecrypter((tuple) -> {
    EncryptedID encrypted = tuple.getAssertion().getSubject().getEncryptedID();
    NameID name = decrypter.decrypt(encrypted);
    tuple.getAssertion().getSubject().setNameID(name);
});

While a touch more verbose, it provides a great deal more flexibility and encourages composition over inheritance.

[ryan13mt]

@jzheaux would something like this meet your explanation above? #9055

[jzheaux]

Thanks for the PR, @ryan13mt, I've left my feedback there.

[ryan13mt]

Hello @jzheaux thanks for closing this issue and merging to master.

I am finding a problem with the polishing commit. You added a check in d0581c9#diff-e1434c9a229d033aa3fe922ab7b9637a54ba5a2521711e3b362e70bc7f787833R511 where you are checking if a response is signed and if true, doing the elements decryption. Is there a reason this check was added?

I believe this is not correct since there are use cases where the idp will sign and encrypt the assertion but will leave the response unsigned as is in our case. Thus having an unsigned SAML Response with an encrypted signed Assertion should still decrypt the assertion and then checking that it has been signed before throwing the error "Either the response or one of the assertions is unsigned. Please either sign the response or all of the assertions.". or in my case it's throwing "No assertions found in response." since the encrypted assertions have not being decrypted yet.

With this new check, the library is now requiring that a response must be signed if it contains an encrypted assertion.

Thanks