Details
Major Description
Validation of a SAML 1.1 and 2.0 token is failing due to an inability to extract KeyInfo from the Subject of a SAML assertion. The issue appears to be independant of using SAML 1.1/2.0 or symmetric/asymmetric bindings.
The extract of the SAML subject (symmetric binding) is as follows:
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos">DOMAIN\JOE</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
</e:EncryptionMethod>
<KeyInfo>
<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<X509Data>
<X509IssuerSerial>
<X509IssuerName>CN=Root Agency</X509IssuerName>
<X509SerialNumber>-147027885241304943914470421251724308948</X509SerialNumber>
</X509IssuerSerial>
</X509Data>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>YPzUKhWVjM56ugTvgLF8nbCULmITwiE2lGFWf5rsRwm7v+g/J2cswNJoK5oBpROUXJRV3P10PRtWloXNU3eR8kZRn7nutFp5iEpRW4FHcoRMTK3KHYILz7EaBwYsNaGJ45PD6IeJvjGb79/5N9boePWZBMl708vsXp63fXNbUPo=</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
</KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
The extract of the SAML subject (asymmetric binding) is as follows:
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos">DOMAIN\JOE</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<SubjectConfirmationData xmlns:a="http://www.w3.org/2001/XMLSchema-instance" a:type="KeyInfoConfirmationDataType">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyValue>
<RSAKeyValue>
<Modulus>qq45WmIc5AJQF8f06R8KMm9G4RsT4Vi9Xx5psYuyDzD1M7480CQ7dEmOLkYnOP/qwLNiKgvG/Xm2rGYf1fgQD+dH+jwoirACflwEGUk7nU88mZOeJwqfXq4oWdsGVAMREyJQnW2q5+KJQt6/Pt3UBWquTvJnwes9/0WrQUAUX9s=</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</SubjectConfirmationData>
</SubjectConfirmation>
</Subject>
In both cases the SAMUtil.java (as part of WSSJ-1.5.8) fails to extract the certificate info. The following lines are an extract from the source code for which this is failing:
Element e = samlSubj.getKeyInfo();
X509Certificate[] certs = null;
try {
KeyInfo ki = new KeyInfo(e, null);
if (ki.containsX509Data()) {
X509Data data = ki.itemX509Data(0);
XMLX509Certificate certElem = null;
In both use cases the ki instance return false for ki.containsX509Data() and hence the processing fails.
In an attempt to see whether the KeyInfo constructor limited itself to certain types of certificate references, I manually modified the SAML assertion subject using TCPMon to include the X509 Base64 representation of the certificate as follows and found that this actually works, as a result of the ki.containsX509Data() statement returns true:
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos">DOMAIN\JOE</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIBsTCCAV+gAwIBAgIQKCrSOt8UsKxIAPFEMK316zAJBgUrDgMCHQUAMBYxFDASBgNVBAMTC1Jvb3QgQWdlbmN5MB4XDTA4MDgxMzE1MDkyM1oXDTM5MTIzMTIzNTk1OVowFDESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEhqjNMe8M8CA0yGX1pUlJZ4r5WKvQfJ6k8DPBR/VGcvbWPBeiHRjBhH5I5kszg04on8M+FFg0RkW1cfmQRc8kf1XLudHdBUxJx3nfLXH2OscsxQkgcNfdvo5/GCewDIRHMxI+2TO9tgLP6SEJBdprO/55q8t4k/VW4Yi9u9/2VQIDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCNYSHcFmRjoRgwFjEUMBIGA1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwCQYFKw4DAh0FAANBAEWsx9wociNjb8uidCy6WRHfS8qhIYjSbgGCYL8/bZ0Xoc8ETPOgZsnD0zSgLuWj7tlY0cHNtY4Nvu8tRo/U2ts=</X509Certificate>
</X509Data>
</KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
Have previously submitted this an email request directly to rampart-dev but thought it best to formally raise the issue here as it's blocking any further use of rampart for this particular project.
Thanks,
Jason