StatusResponseType must have Status. / xmltooling::ValidationException at (https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST)
Stefan König
as soon I solved 2 other problems, it seems there is still another one
(hope this ends once).
The current issue seems more a bug in the software than a configuration
problem to me, as the produced XML seems invalid.
Question:
Is this a configuration issue or a bug in the IdP implementation?
Any suggestions what to do next?
Thanks for you time...
Regards,
Stefan
----
Error Message is:
xmltooling::ValidationException at
(https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST)
StatusResponseType must have Status.
Version Information:
IdP-Version is the one from: shibboleth-identityprovider-2.3.5-bin.zip
2012-02-16 11:41:24 INFO Shibboleth.Config : Shibboleth SP Version 2.4.3
2012-02-16 11:41:24 INFO Shibboleth.Config : Library versions: log4shib
1.0.5, Xerces-C 3.1.1, XML-Security-C 1.6.1, XMLTooling-C 1.4.2,
OpenSAML-C 2.4.3, Shibboleth 1.4.3
It seems that the IdP sends back the following (invalid) XML, which the
SP is complaining about:
<?xml version="1.0" encoding="UTF-8"?><saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"
ID="_716eef3f2dbc3cd01facf0211f1d4d73"
InResponseTo="_020ec9805ac690bb79a84f251a992cde"
IssueInstant="2012-02-20T10:36:15.625Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idefix.worldtalk.de/idp</saml2:Issuer>
</saml2p:Response>
=== CUT HERE (idp-processing.log) =====
11:36:15.625 - DEBUG
[org.opensaml.ws.message.encoder.BaseMessageEncoder:49] - Beginning
encode message to outbound transport of type:
org.opensaml.ws.transport.http.HttpServletResponseAdapter
11:36:15.626 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:124] - Invoking
Velocity template to create POST body
11:36:15.628 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:158] - Encoding
action url of 'https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST'
with encoded value
'https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST'
11:36:15.628 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:161] - Marshalling
and Base64 encoding SAML message
11:36:15.628 - DEBUG
[org.opensaml.ws.message.encoder.BaseMessageEncoder:97] - Marshalling
message
11:36:15.639 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:184] - Setting
RelayState parameter to: 'https://idefix.worldtalk.de/sp/', encoded as
'https://idefix.worldtalk.de/sp/'
11:36:15.651 - DEBUG [PROTOCOL_MESSAGE:74] -
<?xml version="1.0" encoding="UTF-8"?><saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"
ID="_716eef3f2dbc3cd01facf0211f1d4d73"
InResponseTo="_020ec9805ac690bb79a84f251a992cde"
IssueInstant="2012-02-20T10:36:15.625Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idefix.worldtalk.de/idp</saml2:Issuer>
</saml2p:Response>
=== CUT HERE (shibd.log, Note: different but similar request/response
[needed DEBUG enabled]) =====
2012-02-20 11:56:56 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
validating input
2012-02-20 11:56:56 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalling, deflating, base64-encoding the message
2012-02-20 11:56:56 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
marshalled message:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"
Destination="https://idefix.worldtalk.de/idp/profile/SAML2/Redirect/SSO"
ID="_9988236f4b4dd40ebcec5919b13c38ef"
IssueInstant="2012-02-20T10:56:56Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idefix.worldtalk.de/idp</saml:Issuer><samlp:NameIDPolicy
AllowCreate="1"/></samlp:AuthnRequest>
2012-02-20 11:56:56 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]:
message encoded, sending redirect to client
2012-02-20 11:56:57 DEBUG OpenSAML.MessageDecoder.SAML2POST [1]:
validating input
2012-02-20 11:56:57 DEBUG OpenSAML.MessageDecoder.SAML2POST [1]: decoded
SAML message:
<?xml version="1.0" encoding="UTF-8"?><saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"
ID="_a0c4d22bdceb8637cd474eae5051dd5c"
InResponseTo="_9988236f4b4dd40ebcec5919b13c38ef"
IssueInstant="2012-02-20T10:56:56.963Z" Version="2.0"><saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idefix.worldtalk.de/idp</saml2:Issuer></saml2p:Response>
Chad La Joie
> Is this a configuration issue or a bug in the IdP implementation?
Looks like a bug in the IdP, it's sending invalid messages.
> Any suggestions what to do next?
Get the IdP to send valid messages.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Stefan König
>> Any suggestions what to do next?
> Get the IdP to send valid messages.
>
1. Should I file a bug report and wait for a fix?
As I just guess I have a crappy configuration:
2. Where to look for the problem in the configuration? Which parts (of
the configuration) are likely to produce those symptoms?
Regards,
Stefan
Chad La Joie
> 1. Should I file a bug report and wait for a fix?
You don't have much choice, the IdP is producing an invalid response
the SP isn't going to accept that.
> As I just guess I have a crappy configuration:
> 2. Where to look for the problem in the configuration? Which parts (of the
> configuration) are likely to produce those symptoms?
I'm not sure why you'd guess that since I just said it wasn't an
configuration issue.
Cantor, Scott
>
> 1. Should I file a bug report and wait for a fix?
If it's a Shibboleth IdP, then I don't know of any scenario where it would produce such a message, but I guess you should file a bug.
> As I just guess I have a crappy configuration:
> 2. Where to look for the problem in the configuration? Which parts (of
> the configuration) are likely to produce those symptoms?
Whatever you were trying to say in the other thread about needing a RelyingParty definition did not make any sense to me, and isn't true, so my suspicion would be to start there.
-- Scott
Stefan König
>> You don't have much choice, the IdP is producing an invalid response
the SP isn't going to accept that.
Ok, thx.
Cantor, Scott:
>> If it's a Shibboleth IdP, then I don't know of any scenario where it would produce such a message, but I guess you should file a bug.
Ok, I'm convinced. Will write a bug report.
Cantor, Scott:
>> Whatever you were trying to say in the other thread about needing a RelyingParty definition did not make any sense to me, and isn't true, so my suspicion would be to start there.
For others following this thread, here is what is meant:
I had the problem, that my Shibboleth IdP tried to encrypt the Assertion, it generated.Final error message in my browser was: "Could not resolve a key encryption credential for peer entity: https://idefix.worldtalk.de/idp/shibboleth";
It looked for metadata for an SPSSODescriptor with credential definition for the Request sent by the idp itself (Retrieving metadata for entity 'https://idefix.worldtalk.de/idp/shibboleth' in role '{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor' for protocol 'urn:oasis:names:tc:SAML:2.0:protocol').
I also got log lines as "No metadata for relying party https://idefix.worldtalk.de/idp, treating party as anonymous" and "SAML 2 SSO profile is not configured for relying party https://idefix.worldtalk.de/idp"; That's the reason why I finally added a RelyingParty for entity 'https://idefix.worldtalk.de/idp/shibboleth' with itself as its "provider" in the relying-party.xml:
--- CUT HERE (relying-party.xml) ---
<rp:RelyingParty id="https://idefix.worldtalk.de/idp"
provider="https://idefix.worldtalk.de/idp"
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
<rp:ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" />
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" />
<rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" />
<rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" />
</rp:RelyingParty>
--- CUT HERE ---
--- CUT HERE (idp-process.log) ----
11:01:15.949 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:274] - Attempting to encrypt assertion to relying party 'https://idefix.worldtalk.de/idp/shibboleth'
11:01:15.951 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:279] - Assertion to be encrypted is:
<?xml version="1.0" encoding="UTF-8"?><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_041ed7c8c610dbb33ca8452c33b37887" IssueInstant="2012-02-20T10:01:15.864Z" Version="2.0">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idefix.worldtalk.de/idp/shibboleth</saml2:Issuer>
[... some more XML ...]
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://idefix.worldtalk.de/idp/shibboleth" SPNameQualifier="https://idefix.worldtalk.de/idp/shibboleth">_4b134ea73f9b295c3e9a76fea9676ade</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="134.2.22.86" InResponseTo="_54a47f7b77a7c7deda0fc050f3bea4a2" NotOnOrAfter="2012-02-20T10:06:15.864Z" Recipient="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2012-02-20T10:01:15.864Z" NotOnOrAfter="2012-02-20T10:06:15.864Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://idefix.worldtalk.de/idp/shibboleth</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2012-02-20T10:01:15.844Z" SessionIndex="9472804cbda62fb99c450cd21c02a390416a8655d6b9199cc17c936d28205a3f">
<saml2:SubjectLocality Address="134.2.22.86"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
[... uninteresting ...]
11:01:15.976 - DEBUG [org.opensaml.security.MetadataCredentialResolver:206] - Attempting to retrieve credentials from cache using index: [https://idefix.worldtalk.de/idp/shibboleth,{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor,urn:oasis:names:tc:SAML:2.0:protocol,ENCRYPTION]
11:01:15.977 - DEBUG [org.opensaml.security.MetadataCredentialResolver:223] - Unable to retrieve credentials from cache using index: [https://idefix.worldtalk.de/idp/shibboleth,{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor,urn:oasis:names:tc:SAML:2.0:protocol,ENCRYPTION]
11:01:15.977 - DEBUG [org.opensaml.security.MetadataCredentialResolver:243] - Attempting to retrieve credentials from metadata for entity: https://idefix.worldtalk.de/idp/shibboleth
11:01:15.977 - DEBUG [org.opensaml.security.MetadataCredentialResolver:315] - Retrieving metadata for entity 'https://idefix.worldtalk.de/idp/shibboleth' in role '{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor' for protocol 'urn:oasis:names:tc:SAML:2.0:protocol'
11:01:15.977 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:308] - Checking child metadata provider for entity descriptor with entity ID: https://idefix.worldtalk.de/idp/shibboleth
[.... more log lines about how it tried to fetch encryption credentials ...]
11:01:15.987 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:904] - Could not resolve a key encryption credential for peer entity: https://idefix.worldtalk.de/idp/shibboleth
11:01:15.991 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:289] - 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:905) ~[shibboleth-identityprovider-2.3.5.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:286) ~[shibboleth-identityprovider-2.3.5.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.completeAuthenticationRequest(SSOProfileHandler.java:283) [shibboleth-identityprovider-2.3.5.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:165) [shibboleth-identityprovider-2.3.5.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:88) [shibboleth-identityprovider-2.3.5.jar:na]
at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:84) [shibboleth-common-1.3.4.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.35]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]
at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50) [shibboleth-identityprovider-2.3.5.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.35]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]
at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:81) [shibboleth-identityprovider-2.3.5.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.35]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]
at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52) [shibboleth-common-1.3.4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.35]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) [catalina.jar:6.0.35]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:6.0.35]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [catalina.jar:6.0.35]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:6.0.35]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:6.0.35]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) [catalina.jar:6.0.35]
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) [tomcat-coyote.jar:6.0.35]
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) [tomcat-coyote.jar:6.0.35]
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776) [tomcat-coyote.jar:6.0.35]
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705) [tomcat-coyote.jar:6.0.35]
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898) [tomcat-coyote.jar:6.0.35]
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) [tomcat-coyote.jar:6.0.35]
at java.lang.Thread.run(Unknown Source) [na:1.6.0_30]
[....]
11:25:40.125 - WARN [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:287] - No metadata for relying party https://idefix.worldtalk.de/idp, treating party as anonymous
11:25:40.125 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:199] - SAML 2 SSO profile is not configured for relying party https://idefix.worldtalk.de/idp
----
--
----------==========#########>>>>>ZDV<<<<<#########==========----------
Dipl.-Inform. Stefan König
Zentrum für Datenverarbeitung
Universität Tübingen
Wächterstraße 76
D-72074 Tübingen
E-Mail: s.ko...@uni-tuebingen.de
Fon: +49 7071 29-70286
Fax: +49 7071 29-5912
----------==========##########>>>>>@<<<<<##########==========----------
Cantor, Scott
> the Request sent by the idp itself (Retrieving metadata for entity
> 'https://idefix.worldtalk.de/idp/shibboleth' in role
> '{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor' for protocol
> 'urn:oasis:names:tc:SAML:2.0:protocol').
Then your config is wrong, that's my point. Your SP is naming itself after your IdP. That's not likely to go well. You need to pick appropriate names and use them.
My guess is that's the trigger for the bug in the IdP.
Stefan König
itself after your IdP. That's not likely to go well. You need to pick
appropriate names and use them.
>> My guess is that's the trigger for the bug in the IdP.
Yeah, that seemed a "hack" for me too. But sometimes those software
implementations aren't as cleanly as one would expect. So I decided to
give it a try, just giving it was it was wanting according to my log files.
According the bug report:
---
Ok, I found it will -currently- be quite complicated to reproduce the
error. And it wont help anyone, if the bug can't be easily reproduced...
I mean: As long as I don't know any exact cause of the problem, a
developer have to setup the stuff as I did (which wont work without
adapting URLs very carefully or e.g. modifying the /etc/hosts) and even
then would have to hope that the bug occures...
So, I decided to backup the whole thing and setup everything from the
scratch, while taking notes what I exactly changed to the default config
files (using diff).
If the error happens again then, I'll post how to reproduce it.
If it does not, I'll try to force it... and post my results.
This time I'll try to have a mostly minimalistic setup, throwing most
stuff out of the example configs. I did not do that before, because I
did not even have a clue about it's meaning (which I haven't much more
now) and thought it would cause some parts not to function and therefore
running into "non standard"-problems that I cannot solve due to my
limited experience with shibboleth.
I'll especially throw out all SAML1.x-Stuff and everything that's not
"SSO" and "Authentication" (especially Attributes, that possibly need to
be encrypted).
Regards,
Stefan
Peter Schober
> This time I'll try to have a mostly minimalistic setup, throwing
> most stuff out of the example configs. I did not do that before,
> because I did not even have a clue about it's meaning (which I
> haven't much more now) and thought it would cause some parts not to
> function and therefore running into "non standard"-problems that I
> cannot solve due to my limited experience with shibboleth.
> I'll especially throw out all SAML1.x-Stuff and everything that's
> not "SSO" and "Authentication" (especially Attributes, that possibly
> need to be encrypted).
That seems like a waste of time to me, since many people never care to
remove any of that, and also the config examples are working fine
(where this is possible, i.e., no values have to bemade up).
But YMMV,
-peter
Cantor, Scott
> implementations aren't as cleanly as one would expect. So I decided to
> give it a try, just giving it was it was wanting according to my log files.
Your logs are simply telling you how you configured it, but they can't tell you that the configuration doesn't make sense.
> This time I'll try to have a mostly minimalistic setup, throwing most
> stuff out of the example configs.
You don't want to do that. The chances of that working are near nil.
There is nothing wrong other than the choice to name the SP after the IdP. Just don't do that.
Stefan König
(https://issues.shibboleth.net/jira/browse/SIDP-538?focusedCommentId=13855#comment-13855).
NOTE:
I did revise the whole configuration AND changed some things (as
EntityIDs and mixed IDP/SP-metadata.xml) that seemed incorrect.
So please check the description of changes to the standard config given,
instead of relying on information given before in this thread.
Regards
Stefan
Stefan König
party defintion for handling this kind of request?
The SP issues the following AuthnRequest (or equivalent):
—
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"
Destination="https://idefix.worldtalk.de/idp/profile/SAML2/Redirect/SSO"
ID="_3e3e35716f396695533a686a8d8e370e" IssueInstant="2012-02-21T16:04:47Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idefix.worldtalk.de/sp</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>
—
It gets a
AssertionConsumerServiceURL="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST",
thats where to send the response to.
It gets a
Destination="https://idefix.worldtalk.de/idp/profile/SAML2/Redirect/SSO", so
it knows the Profile Binding to be used for receiption (from it's own
metadata, as defined in C:/opt/shibboleth-idp/metadata/idp-metadata.xml):
—
[...]
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
entityID="https://idefix.worldtalk.de/idp">
<IDPSSODescriptor protocolSupportEnumeration="urn:mace:shibboleth:1.0
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false">idefix.worldtalk.de</shibmd:Scope>
</Extensions>
[...]
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://idefix.worldtalk.de/idp/profile/SAML2/Redirect/SSO"/>
</IDPSSODescriptor>
[...]
—
It even gets the
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", so it
knows how to communicatio with the Service at the
"AssertionConsumerServiceURL" to send back the Response.
While just reading again the IdPRelyingParty-Page of the Wiki
(https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty) I
found:
>> Before attempting to change relying party configurations be sure you
understand the concept of a relying party. Also, note, changing these
configuration is an intermediate-level configuration task, is not
generally needed in most deployments, and should only by done by
deployers with a good understanding of how shibboleth and federated
identity management works.
So the question is, weather I should (or better: need) to change
something in the relying-party.xml at all.
The problem: When I comment out everything I added to the
relying-party.xml I'm getting the error message:
—
Error Message: SAML 2 SSO profile is not configured for relying party
https://idefix.worldtalk.de/sp
—
Details from the idp-processing.log:
The following is according to what the wiki states... Its using the
default relying party configuration. That's what we want...
—
18:18:10.124 - DEBUG
[edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:157]
- No custom or group-based relying party configuration found for
https://idefix.worldtalk.de/sp. Using default relying party configuration.
—
But later there's those warnings:
—
18:18:10.126 - WARN
[org.opensaml.saml2.binding.security.SAML2AuthnRequestsSignedRule:81] -
SPSSODescriptor role metadata for entityID
'https://idefix.worldtalk.de/sp' could not be resolved
18:18:10.128 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:287]
- No metadata for relying party https://idefix.worldtalk.de/sp, treating
party as anonymous
18:18:10.129 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:199]
- SAML 2 SSO profile is not configured for relying party
https://idefix.worldtalk.de/sp
—
This at least states, that the IdP wants the access the service
provider's metadata. The only way to give it that metadata reference was
for me to add the definitions in relying-party.xml. Or I could try to
add the SAML 2 SSO profile to the anonymous relying party definition
(which seems not to make so much sense to me).
Just adding the Service Provider Metadata-Definition to the
idp-metadata.xml doesn't work, since the XMLs root node
<EntityDescriptor> has entityID="https://idefix.worldtalk.de/idp"; This
one seems to be the relevant one for the IdP when looking for a matching
<SPSSODescriptor>-Definition. As two root nodes are not permitted in
XML, I can't add another EntityDescriptor...
BUT: It's always interesting to find the solution myself while
explaining the problem.... I just remembered there is a
<EntitiesDescriptor>-Tag, which can have multiple
<EntityDescriptor>-Tags as child nodes. Let me try this...
Scott Cantors answer to this was:
>> No, it never did, which I have said repeatedly.
>> Please take questions to the list, it's not really on topic here.
So I posted it here instead....
Ok, the test result is that the IdP implementation doesn't seem to
support the <EntitiesDescriptor>-Tag; at least it doesn't like the new
XML structure.
--------- CUT HERE -----
18:55:39.796 - DEBUG
[org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:260]
- Processing new metadata from
'C:\opt\shibboleth-idp\metadata\idp-metadata.xml'
18:55:39.796 - DEBUG
[org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:344]
- Unmarshalling metadata from
'C:\opt\shibboleth-idp\metadata\idp-metadata.xml'
18:55:39.797 - ERROR
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:465] - No
unmarshaller registered for document element EntitiesDescriptor
18:55:39.802 - ERROR
[org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:307]
- Unable to unmarshall metadata
org.opensaml.xml.io.UnmarshallingException:
org.opensaml.xml.io.UnmarshallingException: No unmarshaller registered
for document element EntitiesDescriptor
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.unmarshallMetadata(AbstractMetadataProvider.java:471)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.unmarshallMetadata(AbstractReloadingMetadataProvider.java:304)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.processNewMetadata(AbstractReloadingMetadataProvider.java:345)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.refresh(AbstractReloadingMetadataProvider.java:261)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.doInitialization(AbstractReloadingMetadataProvider.java:236)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.initialize(AbstractMetadataProvider.java:407)
[opensaml-2.5.2.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.6.0_30]
[...]
Caused by: org.opensaml.xml.io.UnmarshallingException: No unmarshaller
registered for document element EntitiesDescriptor
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.unmarshallMetadata(AbstractMetadataProvider.java:466)
[opensaml-2.5.2.jar:na]
... 72 common frames omitted
18:55:39.804 - DEBUG
[org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:264]
- Error occurred while attempting to refresh metadata from '{}'
org.opensaml.saml2.metadata.provider.MetadataProviderException: Unable
to unmarshall metadata
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.unmarshallMetadata(AbstractReloadingMetadataProvider.java:308)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.processNewMetadata(AbstractReloadingMetadataProvider.java:345)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.refresh(AbstractReloadingMetadataProvider.java:261)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.doInitialization(AbstractReloadingMetadataProvider.java:236)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.initialize(AbstractMetadataProvider.java:407)
[opensaml-2.5.2.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.6.0_30]
[...]
Caused by: org.opensaml.xml.io.UnmarshallingException:
org.opensaml.xml.io.UnmarshallingException: No unmarshaller registered
for document element EntitiesDescriptor
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.unmarshallMetadata(AbstractMetadataProvider.java:471)
[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.unmarshallMetadata(AbstractReloadingMetadataProvider.java:304)
[opensaml-2.5.2.jar:na]
... 71 common frames omitted
Caused by: org.opensaml.xml.io.UnmarshallingException: No unmarshaller
registered for document element EntitiesDescriptor
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.unmarshallMetadata(AbstractMetadataProvider.java:466)
[opensaml-2.5.2.jar:na]
... 72 common frames omitted
18:55:39.805 - INFO
[org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:271]
- Next refresh cycle for metadata provider
'C:\opt\shibboleth-idp\metadata\idp-metadata.xml' will occur on
'2012-02-21T18:00:39.804Z' ('2012-02-21T19:00:39.804+01:00' local time)
18:55:39.807 - ERROR
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:411] -
Metadata provider failed to properly initializing, halting
org.opensaml.saml2.metadata.provider.MetadataProviderException:
org.opensaml.saml2.metadata.provider.MetadataProviderException: Unable
to unmarshall metadata
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.refresh(AbstractReloadingMetadataProvider.java:266)
~[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.doInitialization(AbstractReloadingMetadataProvider.java:236)
~[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.initialize(AbstractMetadataProvider.java:407)
~[opensaml-2.5.2.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.6.0_30]
[...]
Caused by:
org.opensaml.saml2.metadata.provider.MetadataProviderException: Unable
to unmarshall metadata
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.unmarshallMetadata(AbstractReloadingMetadataProvider.java:308)
~[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.processNewMetadata(AbstractReloadingMetadataProvider.java:345)
~[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.refresh(AbstractReloadingMetadataProvider.java:261)
~[opensaml-2.5.2.jar:na]
... 69 common frames omitted
Caused by: org.opensaml.xml.io.UnmarshallingException:
org.opensaml.xml.io.UnmarshallingException: No unmarshaller registered
for document element EntitiesDescriptor
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.unmarshallMetadata(AbstractMetadataProvider.java:471)
~[opensaml-2.5.2.jar:na]
at
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.unmarshallMetadata(AbstractReloadingMetadataProvider.java:304)
~[opensaml-2.5.2.jar:na]
... 71 common frames omitted
Caused by: org.opensaml.xml.io.UnmarshallingException: No unmarshaller
registered for document element EntitiesDescriptor
at
org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.unmarshallMetadata(AbstractMetadataProvider.java:466)
~[opensaml-2.5.2.jar:na]
... 72 common frames omitted
18:55:39.808 - ERROR
[edu.internet2.middleware.shibboleth.common.config.BaseService:188] -
Configuration was not loaded for
shibboleth.RelyingPartyConfigurationManager service, error creating
components. The root cause of this error was:
org.opensaml.xml.io.UnmarshallingException: No unmarshaller registered
for document element EntitiesDescriptor
--------- CUT HERE -----
Cantor, Scott
> party defintion for handling this kind of request?
No. It needs *metadata*, period.
> it knows the Profile Binding to be used for receiption (from it's own
> metadata, as defined in C:/opt/shibboleth-idp/metadata/idp-metadata.xml):
No. That is the IdP's metadata, not the SP's. It has nothing to do with the IdP processing the request.
> So the question is, weather I should (or better: need) to change
> something in the relying-party.xml at all.
Other than adding metadata sources, no, not in general.
> The problem: When I comment out everything I added to the
> relying-party.xml I'm getting the error message:
Because you're telling it not to support any profiles.
> But later there's those warnings:
Because you have no metadata supplied.
> This at least states, that the IdP wants the access the service
> provider's metadata. The only way to give it that metadata reference was
> for me to add the definitions in relying-party.xml.
Adding metadata, yes. That is not the same as adding "definitions".
> Just adding the Service Provider Metadata-Definition to the
> idp-metadata.xml doesn't work,
You do not add metadata like that. You need to define additional sources of metadata for the SP(s) to support.
> Ok, the test result is that the IdP implementation doesn't seem to
> support the <EntitiesDescriptor>-Tag; at least it doesn't like the new
> XML structure.
Your XML was just wrong.
When you want to support an SP, you need a source of metadata. How you do that is up to you, but that's it, there's nothing else you need to touch apart from probably the attribute filter.
Normally for testing you package the metadata into a file, and add it as a file source in relying-party.xml in the metadata chain. For more practical handling, you create a local file for all such SPs, and wrap all their metadata into an EntitiesDescriptor. That is NOT at all related to the idp-metadata.xml file.
Peter Schober
> The SP issues the following AuthnRequest (or equivalent):
> AssertionConsumerServiceURL="https://idefix.worldtalk.de/sp/Shibboleth.sso/SAML2/POST"
> Destination="https://idefix.worldtalk.de/idp/profile/SAML2/Redirect/SSO"
> It gets a Destination="https://idefix.worldtalk.de/idp/profile/SAML2/Redirect/SSO",
> so it knows the Profile Binding to be used for receiption (from it's
> own metadata, as defined in
> C:/opt/shibboleth-idp/metadata/idp-metadata.xml):
There is no such thing as a "Profile Binding" and the "Protocol
Binding" is included in the authentication request you cite above.
Also the default reply-party.xml has this commend to offer:
<!--
Load the IdP's own metadata. This is necessary for artifact support.
-->
Unless you're dealing with Artifacts (which you are not, based on the
above) the IdP does /not/ need access to its own metadata and so this
is not where the info comes from.
> So the question is, weather I should (or better: need) to change
> something in the relying-party.xml at all.
Dpends on what you're trying to achive. Usually the only thing to
change is to add new metadata provider. Sometimes you'll also need
special arrangements for specific SPs.
> The problem: When I comment out everything I added to the
> relying-party.xml I'm getting the error message:
> —
> Error Message: SAML 2 SSO profile is not configured for relying
> party https://idefix.worldtalk.de/sp
Start with the default config, not with your butchered version
thereof.
> 18:18:10.128 - WARN [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:287]
> - No metadata for relying party https://idefix.worldtalk.de/sp,
> treating party as anonymous
[...]
> This at least states, that the IdP wants the access the service
> provider's metadata. The only way to give it that metadata reference
> was for me to add the definitions in relying-party.xml.
Documentation https://wiki.shibboleth.net/confluence/display/SHIB2/
->
"Configure" https://wiki.shibboleth.net/confluence/display/SHIB2/Configuration
->
"Communicate with a New Service Provider"
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPSPCommunicate
->
"Loading its Metadata"
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider
So add a metadata provider to your relying-party.xml (check the
existing example, the huge block marked "Metadata Configuration") and
leave idp-metadata.xml alone, that's the metadata describing the IdP
(so you can give it to the SP).
-peter