None of these errors showed up anywhere when the partner was just encrypting the attributes. This set of errors showed up once I asked them to encrypt the assertion. They indicated that they are encrypting both now (meaning, encrypt attributes, then encrypt the assertion), which seems pretty stupid so I hope that is not actually what they are doing. Putting extractKeyNames=false into our config didn't actually solve the problem:<div>
<br></div><div><div>2012-07-24 14:07:24 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: message from (<a href="https://s-memberportal.cigna.com/sps/idp_saml20/saml20">https://s-memberportal.cigna.com/sps/idp_saml20/saml20</a>)</div>
<div>2012-07-24 14:07:24 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: searching metadata for message issuer...</div><div>2012-07-24 14:07:24 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]: evaluating message flow policy (replay checking on, expiration 60)</div>
<div>2012-07-24 14:07:24 DEBUG XMLTooling.StorageService [1]: inserted record (FIMRSP_b9504b5d-0138-172e-a683-ce95e26a576c) in context (MessageFlow)</div><div>2012-07-24 14:07:24 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]: validating signature profile</div>
<div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolving ds:X509Certificate</div><div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 1 certificate(s)</div><div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0 CRL(s)</div>
<div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolving ds:X509Certificate</div><div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 1 certificate(s)</div><div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0 CRL(s)</div>
<div>2012-07-24 14:07:24 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: attempting to validate signature with the peer's credentials</div><div>2012-07-24 14:07:24 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: signature validated with credential</div>
<div>2012-07-24 14:07:24 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]: signature verified against message issuer</div><div>2012-07-24 14:07:24 DEBUG Shibboleth.SSO.SAML2 [1]: processing message against SAML 2.0 SSO profile</div>
<div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0 certificate(s)</div><div><span style="background-color:rgb(255,255,102)">2012-07-24 14:07:24 DEBUG XMLTooling.CredentialCriteria [1]: key algorithm didn't match ('AES' != 'RSA')</span></div>
<div>2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0 certificate(s)</div><div>2012-07-24 14:07:24 DEBUG XMLTooling.CredentialCriteria [1]: credential name(s) didn't overlap</div><div><br></div>
<div>Something must be wrong with either the public key we gave them or how they are using it, is all I can think. Also, I have no idea how AES is coming into play since neither side is specifying to use AES anywhere. Is that the default private key algorithm Shib uses?</div>
<div><br></div><div>Thanks,</div><div><br>Rob</div><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 9:57 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> then use that to decrypt the assertion itself? When I look at the logs, it<br>
> appears that things fall apart when it tries to process "message against SAML<br>
> 2.0 SSO profile":<br>
<br>
</div>I gave you the solution to this yesterday. If your key matches your metadata, then the problem is the key names they generated and you will have to add extractKeyNames="false" to the credential resolver to stop it from checking the name against your key.<br>
<div class="im"><br>
> 2012-07-24 12:45:57 DEBUG XMLTooling.CredentialCriteria [21]: credential<br>
> name(s) didn't overlap<br>
> 2012-07-24 12:45:57 ERROR Shibboleth.SSO.SAML2 [21]: Unable to resolve<br>
> any key decryption keys.<br>
<br>
</div>Let me ask again: did you check the log and not find any mention of these same errors from the original EncryptedAttribute case?<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>