Could not resolve a key encryption credential for peer entity
Fong, Trevor
Hi Guys,
We're trying to integrate with Service-Now also and are trying to follow uChicago's recipe from https://docs.google.com/document/d/1yApSgHn0C02z09zYC3CD_edX7s3DbnuGgJ-kI-BhqYI/edit?hl=en_US&authkey=CPK1ppQN&pli=1
We've also commented out some of the lines in Service-Now scripts to do with SPNameQualifier as suggested by James Bardin.
However, we still have a problem: when someone tries to login, they get the Service-Now error message "Could not extract //Subject/NameID from SAMLResponse"
Delving into our idp-process.log, we see:
10:24:24.448 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:888] - Could not resolve a key encryption credential for peer entity: https://xxxx.service-now.com
10:24:25.913 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:275] - Unable to construct encrypter
org.opensaml.xml.security.SecurityException: Could not resolve key encryption credential
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.getEncrypter(AbstractSAML2ProfileHandler.java:889) ~[shibboleth-identityprovider-2.2 .0.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:272) ~[shibboleth-identityprovider-2.
2.0.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.completeAuthenticationRequest(SSOProfileHandler.java:280) [shibboleth-identityprovider-2.2.0.j
ar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:164) [shibboleth-identityprovider-2.2.0.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:84) [shibboleth-identityprovider-2.2.0.jar:na]
at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:83) [shibboleth-common-1.2.0.jar:na]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [servlet-api.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:77) [shibboleth-identityprovider-2.2.0.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:51) [shibboleth-common-1.2.0.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [catalina.jar:6.0.29]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:6.0.29]
at org.terracotta.modules.tomcat.tomcat_5_5.SessionValve55.invoke(SessionValve55.java:88) [na:na]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) [catalina.jar:6.0.29]
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) [tomcat-coyote.jar:6.0.29]
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) [tomcat-coyote.jar:6.0.29]
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774) [tomcat-coyote.jar:6.0.29]
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) [tomcat-coyote.jar:6.0.29]
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896) [tomcat-coyote.jar:6.0.29]
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) [tomcat-coyote.jar:6.0.29]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_24]
... <snip> ...
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/>
<saml2p:StatusMessage>Unable to encrypt assertion</saml2p:StatusMessage>
</saml2p:Status>
Any ideas?
Thanks a lot,
Trev
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Cantor, Scott
>Delving into our idp-process.log, we see:
You failed to configure a relying party override that disables encryption.
-- Scott
Nate Klingenstein
Leung, Warren
We have a SP where a certificate is expiring soon, so we wanted to do an
SP key rollover. We added another KeyDescriptor(2 total) into the IdP
metadata both with no use attribute. After the metadata is refreshed into
the IdP we get the following error on the SP
2011-09-21 15:51:01 ERROR Shibboleth.SSO.SAML2 [1]: Unable to resolve any
key decryption keys.
The relying-party.xml is configured like the following for SAML2. No
errors appear on the IdP logs.
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
includeAttributeStatement="true" assertionLifetime="PT30M"
assertionProxyCount="0" signResponses="never" signAssertions="always"
encryptAssertions="conditional" encryptNameIds="never"/>
I could get things to work to by making sure the valid certificate is the
2nd KeyDescriptor in the metadata. It would also work if I made
encryptAssertions="never".
Since we are pushing attributes to the SP, the IdP will pick a certificate
to encrypt the assertion to the SP and if it is wrong then the error
occurs. If it was a pull the SP would present a cert and thus the IdP
would know what to use to encrypt it back to the SP. Is my understanding
of this correct?
Is there some configuration or a step I missed that would resolve this?
Thanks
Warren Leung
Nate Klingenstein
Cantor, Scott
>
>We have a SP where a certificate is expiring soon, so we wanted to do an
>SP key rollover. We added another KeyDescriptor(2 total) into the IdP
>metadata both with no use attribute. After the metadata is refreshed into
>the IdP we get the following error on the SP
>
>2011-09-21 15:51:01 ERROR Shibboleth.SSO.SAML2 [1]: Unable to resolve any
>key decryption keys.
You can't add an encryption key to the metadata if the SP doesn't have
access to it. The IdP is allowed to pick any key to encrypt with, and
you'd better be able to decrypt.
That said, if you put that new key first, that's basically asking any
typical IdP to use it for encryption. You can't do it that way.
>Since we are pushing attributes to the SP, the IdP will pick a certificate
>to encrypt the assertion to the SP and if it is wrong then the error
>occurs. If it was a pull the SP would present a cert and thus the IdP
>would know what to use to encrypt it back to the SP. Is my understanding
>of this correct?
Yes.
>Is there some configuration or a step I missed that would resolve this?
Yes, using the SP configuration to configure the new key for decryption
only before adding it to the metadata and then swapping things.
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCreden
tials
There are other ways, which require control over metadata key usage bits.
They're all comparatively similar.
-- Scott
Tom Scavo
>
> We have a SP where a certificate is expiring soon, so we wanted to do an
> SP key rollover. We added another KeyDescriptor(2 total) into the IdP
> metadata both with no use attribute.
I think you mean SP metadata. Strictly speaking, you don't need two
encryption keys in SP metadata.
> The relying-party.xml is configured like the following for SAML2.
At the IdP? You shouldn't have to muck with the IdP's config to
rollover a key at the SP.
> Is there some configuration or a step I missed that would resolve this?
Yes, at the SP (others have provided pointers). If this is an InCommon
SP (and maybe even if it isn't), you might want to read this doc:
https://spaces.internet2.edu/display/InCCollaborate/Certificate+Migration
Hope this helps,
Tom
Leung, Warren
>the SP so that either key can be available for decryption.
Nate/Scott, it totally slipped my mind to do the SP configuration with
CredentialResolvers. When we were doing attribute queries in SAML1 it
wasn't ever
needed to make a configuration on the SP side for key rollover, so I
didn't really consider it with encryption. I ended up adding the 2nd
cert/key and things worked. Thanks
>I think you mean SP metadata. Strictly speaking, you don't need two
>encryption keys in SP metadata.
If you can't time the metadata loading with when the SP changes the
cert/key, then wouldn't you have to have 2? If you had complete control
of everything I could see how you wouldn't need it 2 though.
Thanks for the help
Warren
Christopher Bongaarts
>> I think you mean SP metadata. Strictly speaking, you don't need two
>> encryption keys in SP metadata.
>
> If you can't time the metadata loading with when the SP changes the
> cert/key, then wouldn't you have to have 2? If you had complete control
> of everything I could see how you wouldn't need it 2 though.
Step 1: configure credential resolvers on SP so it accepts messages
encrypted with either the old or new key
Step 2: provide updated metadata to IdPs with the new key (only)
Step 3: wait till all IdPs are using the new key
Step 4: remove the old key from your SP configuration
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
Tom Scavo
>
>>I think you mean SP metadata. Strictly speaking, you don't need two
>>encryption keys in SP metadata.
>
> If you can't time the metadata loading with when the SP changes the
> cert/key, then wouldn't you have to have 2?
In metadata? No.
> If you had complete control
> of everything I could see how you wouldn't need it 2 though.
You only need complete control at the SP. If you needed to control the
IdP as well, then key rollover would be impossible in all but the
simplest deployments.
Tom
Tom Scavo
>
> Step 1: configure credential resolvers on SP so it accepts messages
> encrypted with either the old or new key
> Step 2: provide updated metadata to IdPs with the new key (only)
> Step 3: wait till all IdPs are using the new key
> Step 4: remove the old key from your SP configuration
If the metadata contains a key descriptor with use="encryption", then
that's about right. If, OTOH, the metadata contains a key descriptor
with no use attribute, then it's a bit more complicated than that.
Tom
Fong, Trevor
Hi Everyone,
Yup - we have turned off encryption for their SP, exactly as uChicago and Nate have suggested. We have the following in our relying-party.xml:
<RelyingParty id="https://xxxx.service-now.com"
provider="https://xxxxx/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<ProfileConfiguration
xsi:type="saml:SAML2SSOProfile"
encryptAssertions="never"
encryptNameIds="never" />
</RelyingParty>
So still no dice…
Thanks,
Trev
From: users-...@shibboleth.net [mailto:users-...@shibboleth.net]
On Behalf Of Nate Klingenstein
Sent: September-21-11 1:01 PM
To: Shib Users
Subject: Re: Could not resolve a key encryption credential for peer entity
Trev,
Your immediate problem is that there is no way to encrypt assertions sent to Service-Now, according to the guide you referenced. As such, that's usually turned off strictly for that SP by this configuration:
<!-- relying party for service-now -->
<RelyingParty id="https://uchicagotest.service-now.com"
provider="https://matlock.uchicago.edu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
</RelyingParty>
... which you may be missing.
Their parsing code is probably not ultra sophisticated, and it interprets the error code the IdP sends as a response missing an assertion with a subject in it. Which, I guess is true, in a very narrow sense...
Make sure you're not trying to encrypt assertions sent to them,
Nate.
On Sep 21, 2011, at 19:54 , Fong, Trevor wrote:
Peter Schober
> Yup - we have turned off encryption for their SP, exactly as uChicago and Nate have suggested. We have the following in our relying-party.xml:
>
> <RelyingParty id="https://xxxx.service-now.com"
> provider="https://xxxxx/idp/shibboleth"
> defaultSigningCredentialRef="IdPCredential">
> <ProfileConfiguration
> xsi:type="saml:SAML2SSOProfile"
> encryptAssertions="never"
> encryptNameIds="never" />
> </RelyingParty>
>
And you restarted the container (or configured the IdP to periodically
reload relying-party.xml and waited until the reload happened -- not
that that's recommended for relying-party.xml)?
Since the XML seems correct it must be something elselike not using
the config file, being on the wrong server (dev,qa,test,prod,whathaveyou)...
-peter
Cantor, Scott
>Hi Everyone,
>
>Yup - we have turned off encryption for their SP, exactly as uChicago and
>Nate have suggested. We have the following in our relying-party.xml:
It isn't actually using that configuration if you're getting that error.
Maybe the entityID doesn't match, or something else is off, but your logs
should show it using the default relying party config and not that one.
-- Scott
Cantor, Scott
>> If you had complete control
>> of everything I could see how you wouldn't need it 2 though.
>
>You only need complete control at the SP. If you needed to control the
>IdP as well, then key rollover would be impossible in all but the
>simplest deployments.
You do need an IdP using metadata predictably and keeping it in sync. That
is often not the case if the IdP isn't Shibboleth or SSP, so in such
cases, it is in fact royally difficult/impossible.
-- Scott
Peter Schober
> On Thu, Sep 22, 2011 at 12:21 PM, Christopher Bongaarts <c...@umn.edu> wrote:
> >
> > Step 1: configure credential resolvers on SP so it accepts messages
> > encrypted with either the old or new key
> > Step 2: provide updated metadata to IdPs with the new key (only)
> > Step 3: wait till all IdPs are using the new key
> > Step 4: remove the old key from your SP configuration
>
> If the metadata contains a key descriptor with use="encryption", then
> that's about right. If, OTOH, the metadata contains a key descriptor
> with no use attribute, then it's a bit more complicated than that.
Would the above (by Christopher) still work without specifying a use
if the SP never signes requests and the IdP pushes attributes to the
SP (i.e., no SOAP queries to verify)?
-peter
Cantor, Scott
>Would the above (by Christopher) still work without specifying a use
>if the SP never signes requests and the IdP pushes attributes to the
>SP (i.e., no SOAP queries to verify)?
Meaning the SPs keys are only for decryption. Yes, I think so.
I tried (and Tom tried) to document for very general cases, and since it's
not all that many more steps, I haven't tried to make it any simpler for
people with a lot of "if" and "assuming".
-- Scott
Tom Scavo
Yes, but that's a hefty "if". In the InCommon Federation, for example,
we have data that suggests the vast majority of transactions are still
SAML1 and I'm fairly certain that almost all of them are doing
attribute query.
Tom
Peter Schober
> > Would the above (by Christopher) still work without specifying a use
> > if the SP never signes requests and the IdP pushes attributes to the
> > SP (i.e., no SOAP queries to verify)?
>
> Yes, but that's a hefty "if". In the InCommon Federation, for example,
> we have data that suggests the vast majority of transactions are still
> SAML1 and I'm fairly certain that almost all of them are doing
> attribute query.
Well, that's not at all the situation here, and statistics do not
factor into my abstract question. Thanks for the anwers.
I also wasn't proposing this as a general solution, I was merely
interested in intellectually "saving" the method suggested, maybe with
an eye towards a couple of SPs (and the IdPs they work with) where I
know these assumptions to hold.
-peter
Fong, Trevor
In relying-party.xml, I've specified <AnonymousRelyingParty>, then <DefaultRelyingParty> and then <RelyingParty id="https://ubctest.service-now.com"> - is that the correct place to put it? I tried specifying it before AnonymousRelyingParty and also between AnonymousRelyingParty and DefaultRelyingParty but the IdP didn't seem to like either situation and wouldn't start.
Thanks,
Trev
-----Original Message-----
From: users-...@shibboleth.net [mailto:users-...@shibboleth.net] On Behalf Of Cantor, Scott
Sent: September-22-11 10:53 AM
To: us...@shibboleth.net
Subject: Re: Could not resolve a key encryption credential for peer entity
On 9/22/11 1:44 PM, "Fong, Trevor" <trevo...@ubc.ca> wrote:
>Hi Everyone,
>
>Yup - we have turned off encryption for their SP, exactly as uChicago
>and Nate have suggested. We have the following in our relying-party.xml:
It isn't actually using that configuration if you're getting that error.
Maybe the entityID doesn't match, or something else is off, but your logs should show it using the default relying party config and not that one.
-- Scott
--
Peter Schober
> In relying-party.xml, I've specified <AnonymousRelyingParty>, then
> <DefaultRelyingParty> and then <RelyingParty
> id="https://ubctest.service-now.com"> - is that the correct place to
> put it? I tried specifying it before AnonymousRelyingParty and also
> between AnonymousRelyingParty and DefaultRelyingParty but the IdP
> didn't seem to like either situation and wouldn't start.
Yes, it's a sequence, cf. shibboleth-2.0-relying-party.xsd
-peter
Fong, Trevor
Trev
-----Original Message-----
From: users-...@shibboleth.net [mailto:users-...@shibboleth.net] On Behalf Of Peter Schober
Sent: September-23-11 9:57 AM
To: us...@shibboleth.net
Subject: Re: Could not resolve a key encryption credential for peer entity
* Fong, Trevor <trevo...@ubc.ca> [2011-09-23 18:38]:
> In relying-party.xml, I've specified <AnonymousRelyingParty>, then
> <DefaultRelyingParty> and then <RelyingParty
> id="https://ubctest.service-now.com"> - is that the correct place to
> put it? I tried specifying it before AnonymousRelyingParty and also
> between AnonymousRelyingParty and DefaultRelyingParty but the IdP
> didn't seem to like either situation and wouldn't start.
Yes, it's a sequence, cf. shibboleth-2.0-relying-party.xsd -peter