IdP delegation extension problem using CryptoTransient principal connector
Basics
Logistics
Basics
Logistics
Description
We are testing the IdP delegation extension, and ran into an issue when the IdP (version 2.4.0) is also configured to use the CryptoTransient principal connector. In that scenario, the IdP gets an error on the ECP client's delegation request, because it cannot resolve the principal name in the request:
08:49:27.355 - DEBUG [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:410] - Token did not have delegation chain, this must be initial delegation request 08:49:27.355 - DEBUG [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:898] - Attempting to resolve principal name from assertion token presented by '<ECP client SP entity ID>', with NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' and value 'F3HX25IOP7PSJOURM6VQEIN3IBKRS5UZLC7ZG6EAVT5XXAPWJLKIGYMNJQVFKG3MAUMUO4BZFBWFIOR45ABHM2POIOBOG7IYXFBRLE5WNQJ5AMCPL2VSMHDWWUI6KG7UHDWVF2YWI6JRDIPTN6RXZTRM34S6MKRMDSH4TQN43I5KK2AWAC2WVBKKQSFZXDSYCBVYKOFK2HIBIKDKQQCRBKDYJ7BN2WOUO5LUNRI' 08:49:27.359 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:555] - Error resolving principal name for SAML request 'null' from relying party '<ECP client SP entity ID>'. Cause: Decoded NameQualifier (<IdP entity ID>) does not match issuer (null). 08:49:27.359 - WARN [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:911] - Error resolving principal name from assertion token presented by '<ECP client SP entity ID>', with NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' and value 'F3HX25IOP7PSJOURM6VQEIN3IBKRS5UZLC7ZG6EAVT5XXAPWJLKIGYMNJQVFKG3MAUMUO4BZFBWFIOR45ABHM2POIOBOG7IYXFBRLE5WNQJ5AMCPL2VSMHDWWUI6KG7UHDWVF2YWI6JRDIPTN6RXZTRM34S6MKRMDSH4TQN43I5KK2AWAC2WVBKKQSFZXDSYCBVYKOFK2HIBIKDKQQCRBKDYJ7BN2WOUO5LUNRI'
From looking at the code, apparently the profile handler fails to set the outbound message issuer in the resolution context, and the connector code does not like that. I have managed to work around the problem by using this patch to the delegation extension, which just copies the outbound message issuer from the request context:
We are testing the IdP delegation extension, and ran into an issue
when the IdP (version 2.4.0) is also configured to use the CryptoTransient
principal connector. In that scenario, the IdP gets an error on the ECP
client's delegation request, because it cannot resolve the principal name
in the request:
08:49:27.355 - DEBUG [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:410] - Token did not have delegation chain, this must be initial delegation request
08:49:27.355 - DEBUG [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:898] - Attempting to resolve principal name from assertion token presented by '<ECP client SP entity ID>', with NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' and value 'F3HX25IOP7PSJOURM6VQEIN3IBKRS5UZLC7ZG6EAVT5XXAPWJLKIGYMNJQVFKG3MAUMUO4BZFBWFIOR45ABHM2POIOBOG7IYXFBRLE5WNQJ5AMCPL2VSMHDWWUI6KG7UHDWVF2YWI6JRDIPTN6RXZTRM34S6MKRMDSH4TQN43I5KK2AWAC2WVBKKQSFZXDSYCBVYKOFK2HIBIKDKQQCRBKDYJ7BN2WOUO5LUNRI'
08:49:27.359 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:555] - Error resolving principal name for SAML request 'null' from relying party '<ECP client SP entity ID>'. Cause: Decoded NameQualifier (<IdP entity ID>) does not match issuer (null).
08:49:27.359 - WARN [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:911] - Error resolving principal name from assertion token presented by '<ECP client SP entity ID>', with NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' and value 'F3HX25IOP7PSJOURM6VQEIN3IBKRS5UZLC7ZG6EAVT5XXAPWJLKIGYMNJQVFKG3MAUMUO4BZFBWFIOR45ABHM2POIOBOG7IYXFBRLE5WNQJ5AMCPL2VSMHDWWUI6KG7UHDWVF2YWI6JRDIPTN6RXZTRM34S6MKRMDSH4TQN43I5KK2AWAC2WVBKKQSFZXDSYCBVYKOFK2HIBIKDKQQCRBKDYJ7BN2WOUO5LUNRI'
From looking at the code, apparently the profile handler fails to set the
outbound message issuer in the resolution context, and the connector code
does not like that. I have managed to work around the problem by using
this patch to the delegation extension, which just copies the outbound
message issuer from the request context:
Index: src/main/java/edu/internet2/middleware/shibboleth/idp/ext/delegation/profile/LibertyIDWSFSSOSProfileHandler.java
===================================================================
— src/main/java/edu/internet2/middleware/shibboleth/idp/ext/delegation/profile/LibertyIDWSFSSOSProfileHandler.java (revision 360)
+++ src/main/java/edu/internet2/middleware/shibboleth/idp/ext/delegation/profile/LibertyIDWSFSSOSProfileHandler.java (working copy)
@@ -902,6 +902,7 @@
LibertySSOSRequestContext principalResolutionContext = new LibertySSOSRequestContext();
principalResolutionContext.setInboundMessageIssuer(relyingPartyId);
+ principalResolutionContext.setOutboundMessageIssuer(requestContext.getOutboundMessageIssuer());
principalResolutionContext.setSubjectNameIdentifier(tokenNameID);
principalResolutionContext.setProfileConfiguration((SSOConfiguration) profileConfiguration);
But I am not familiar enough with the code to know if this is correct.