SAML2 Auth flow fails to decrypt when using overridden responder id.
Description
Environment
is related to
Activity
Scott Cantor October 18, 2022 at 1:21 PM
For now, defining shibboleth.DecryptionRecipients as a collection of Strings will override just injecting the default entityID into the resolver. Added to both branches.
I will open a separate issue for the possible change to the entire decryption API that would be needed to actually fix this.
Scott Cantor October 18, 2022 at 1:06 PM
No way to really do a simple fix as it turns out, too many APIs in the middle of these calls. It would require a total roto-till.
I think the most expedient solution for “most” people will be to wire in a way to override ths list of recipients so that when decrypting you can feed in “all” of the possible recipient IDs you’re using. That’s not elegant, but there really aren’t decryption use cases that ever make much use of all this machinery “in anger” to actually affect the key lookup process, so I don’t think that will typically break anything.
Scott Cantor October 18, 2022 at 12:27 PM
I think the simplest fix here is going to be to add a lookup-based option for getting the recipient(s) that’s based on ProfileRequestContext, since that’s usable in OpenSAML anyway, then we shouldn’t need new key resolver classes or too much of an API change.
This should be an API addition, so it can be slipped into 4.3.
Scott Cantor April 5, 2022 at 5:27 PM
Looking for confirmation I’m correct about the limitation in OpenSAML.
Scott Cantor April 5, 2022 at 5:26 PM
The issue is that the defaultEncryptedKeyResolver bean in relying-party-system.xml that wires up the various resolvers of keys from the message has a hard-wired reference to the entityID bean carrying the default value as the recipient to check for.
It appears to me that the APIs in this area of OpenSAML for resolving keys aren’t based on pluggable Criteria objects like a lot of the other resolvers did, and the recipient values are statically defined on the resolver beans rather than fed in from outside.
As a workaround, it is possible to re-wire the relevant beans into an overridden SecurityConfiguration object’s decryptionConfiguration slot to point it at a different entityID. It’s not elegant, for sure.
One workaround might be to slap in some subclasses in the IdP that are lookup-strategy aware to handle this use case, unless/until we enhance the lower level APIs to accomodate a criterion-based approach.
Setup IdP with SAML2 flow to upstream IdP. Setup upstream IdP to encrypt assertion.
Verify SAML2 authentication works ok.
Change the IdP global entity id propery to something else.
Create the following override with values from step 1
<util:list id="shibboleth.RelyingPartyOverrides">
<bean parent="RelyingPartyByName" c:relyingPartyIds="https://upstream-entity.com/idp" p:responderId="https://upstream-entity.com/sp">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO" p:checkAddress="false" p:signAssertions="true"/>
</list>
</property>
</bean>
</util:list>
==> SAML2 authenticatio flow fails as it is not able to decrypt assertion anymore.
DEBUG [org.opensaml.saml.saml2.profile.impl.DecryptAssertions:121] - Profile Action DecryptAssertions: Decrypting EncryptedAssertion in Response
DEBUG [org.opensaml.xmlsec.encryption.support.ChainingEncryptedKeyResolver$ChainingIterator:225] - Getting key iterator from next resolver: class org.opensaml.xmlsec.encryption.support.InlineEncryptedKeyResolver
DEBUG [org.opensaml.xmlsec.encryption.support.ChainingEncryptedKeyResolver$ChainingIterator:225] - Getting key iterator from next resolver: class org.opensaml.saml.saml2.encryption.EncryptedElementTypeEncryptedKeyResolver
DEBUG [org.opensaml.xmlsec.encryption.support.ChainingEncryptedKeyResolver$ChainingIterator:225] - Getting key iterator from next resolver: class org.opensaml.xmlsec.encryption.support.SimpleRetrievalMethodEncryptedKeyResolver
DEBUG [org.opensaml.xmlsec.encryption.support.ChainingEncryptedKeyResolver$ChainingIterator:225] - Getting key iterator from next resolver: class org.opensaml.xmlsec.encryption.support.SimpleKeyInfoReferenceEncryptedKeyResolver
DEBUG [org.opensaml.xmlsec.encryption.support.ChainingEncryptedKeyResolver$ChainingIterator:228] - No more resolvers available in the resolver chain