Decoding encrypted attributes from an IDP

[Rob Whitener]

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:

2012-07-24 14:07:24 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: message from (
https://s-memberportal.cigna.com/sps/idp_saml20/saml20)
2012-07-24 14:07:24 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: searching
metadata for message issuer...
2012-07-24 14:07:24 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2012-07-24 14:07:24 DEBUG XMLTooling.StorageService [1]: inserted record
(FIMRSP_b9504b5d-0138-172e-a683-ce95e26a576c) in context (MessageFlow)
2012-07-24 14:07:24 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]:
validating signature profile
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolving
ds:X509Certificate
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 1
certificate(s)
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0
CRL(s)
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolving
ds:X509Certificate
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 1
certificate(s)
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0
CRL(s)
2012-07-24 14:07:24 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
attempting to validate signature with the peer's credentials
2012-07-24 14:07:24 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: signature
validated with credential
2012-07-24 14:07:24 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]:
signature verified against message issuer
2012-07-24 14:07:24 DEBUG Shibboleth.SSO.SAML2 [1]: processing message
against SAML 2.0 SSO profile
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0
certificate(s)
2012-07-24 14:07:24 DEBUG XMLTooling.CredentialCriteria [1]: key algorithm
didn't match ('AES' != 'RSA')
2012-07-24 14:07:24 DEBUG XMLTooling.KeyInfoResolver.Inline [1]: resolved 0
certificate(s)
2012-07-24 14:07:24 DEBUG XMLTooling.CredentialCriteria [1]: credential
name(s) didn't overlap

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?

Thanks,

Rob

On Tue, Jul 24, 2012 at 9:57 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > then use that to decrypt the assertion itself?  When I look at the logs,
> it
> > appears that things fall apart when it tries to process "message against
> SAML
> > 2.0 SSO profile":
>
> 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.
>
> > 2012-07-24 12:45:57 DEBUG XMLTooling.CredentialCriteria [21]: credential
> > name(s) didn't overlap
> > 2012-07-24 12:45:57 ERROR Shibboleth.SSO.SAML2 [21]: Unable to resolve
> > any key decryption keys.
>
> Let me ask again: did you check the log and not find any mention of these
> same errors from the original EncryptedAttribute case?
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120724/3259fc9a/attachment-0001.html