Shibd没有收到正确的POST请求

我正在尝试使用mod_shib为在tomcat容器中运行的应用程序提供SSO。 在Tomcat容器前有一个Apache服务器，作为反向代理运行。

我在shibboleth2.xml中设置了以下比例的mod_shib：

<ApplicationDefaults entityID="myapp-sp" REMOTE_USER="eppn persistent-id targeted-id"> ... <SSO entityID="ssg-idp"> SAML2 SAML1 </SSO> ... <MetadataProvider type="XML" file="/etc/shibboleth/metadata/SAM-metadata.xml"/> 

这是我的这个虚拟主机的apache2 conf：

 <VirtualHost *:80> ServerName server.com UseCanonicalName on ProxyPreserveHost On ProxyPass /myapp http://localhost:8080/myapp ProxyPassReverse /myapp http://localhost:8080/myapp LogLevel debug ErrorLog ${APACHE_LOG_DIR}/myapp.error.log CustomLog ${APACHE_LOG_DIR}/myapp.access.log combined </VirtualHost> <Location /Shibboleth.sso> SetHandler shib </Location> <Location /myapp> ShibRequestSetting requireSession 1 AuthType shibboleth ShibExportAssertion Off Require valid-user </Location> 

如果我导航到server.com/myapp ，我将被redirect到IDPlogin页面。 我使用了一个跟踪器来确定发生了什么事情，好像IDPredirect到使用以下SAML断言向http://server.com/Shibboleth.sso/SAML/POST发出POST请求：

• Apache2：如何使用ProxyPass限制对特定IP的访问？
• configurationnginx反向代理发送TCP保活数据包给服务器
• Nginx：连接（）到xxx.xxx.xxx.184：3000失败（22：无效参数），当连接到上游时，
• 在向squid发送多个请求时，向后端发送一个请求，并在未命中时排队其他请求
• 使用haproxy捕获并转发扩展的PKI证书属性（例如UPN）

 <?xml version="1.0" encoding="UTF-8"?> <saml2p:Response Destination="http://server.com/Shibboleth.sso/SAML/POST" ID="_stsfnerwkh_70d9842a74e3e08f16efa8c0dc12d121" InResponseTo="_70d9842a74e3e08f16efa8c0dc12d121" IssueInstant="2016-05-04T23:43:37.927Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">ssg-idp</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_stsfnerwkh_70d9842a74e3e08f16efa8c0dc12d121"> <ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>lhEjyr7or/1HiJy3B0PCwydxJ9o=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Lpy1RvtHO8G2iQIdYslN3o4GnxFzDXAwjzhdUCSqOnfQ/8jhv5Et+/APBl6Xp7xoHhfEidomOc8b7u9OrfJFl5Oac9kdWcwZs3ADqmy6rfLxkkalUXBA/f5g4tTHJl7BjTI4uwvqU5LeujMORY/dChY2lPGDgk9yI4WLgWj3P4q6BYZ3Yjh44wEzqFodwUNLVtiUn+cZXCuCDiiw6UtaZG/E4VGCngpMayp7ML8KUTnmqcLnMGfYtoJBdG0OjvJxuqhaH9DbSG6VtIMcSXSlJPKlG7Ohz/FKDFtYLAM8MKG/6CgyK61jqDgiV0jOZCsNDx+2H/2/TU9qxi4jOTpF2Q==</ds:SignatureValue> </ds:Signature> <saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status> <saml2:Assertion ID="_7f550c02-ee46-41eb-96fc-884971e92651" IssueInstant="2016-05-04T23:43:37.928Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">ssg-idp</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_7f550c02-ee46-41eb-96fc-884971e92651"> <ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>TEaINCBQjk29gFzZZEW2rAMr2Jo=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Q9ympsGe9QQt1NwOnXx2zJzxkJbTCEXJ1hmDyQO8DL+KLr7wEE+6dEcbKJSzKjSRI1uiYqlrpXx2smjCf/WXA5c61HbO6bQXR8YSBcpzjWrmNtRUnJm49Nh7gUnawdp4YWrOQTfYulfbMvvzBwoEcKNNN+az/b+wQtCF/NEActAJdsyZqlPTRdGziKW2Tb8q2THoJAdSHRQQHZVoGu4npUVdhQsn8H93YhLxcz5pIBBJPBy7j2fSEEQdwzrD0bT7GK7wDXqRS5SAmpoapnVouVVCaXiJDNwDcUXx8R30RNbDAox8WSfEBXZEr58akXqaq64EHd5zY6Gusbjw4qUQcg==</ds:SignatureValue> </ds:Signature> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">user_x</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData Address="172.22.164.92" InResponseTo="_70d9842a74e3e08f16efa8c0dc12d121" NotOnOrAfter="2016-05-04T23:48:37.928Z" Recipient="http://server.com/Shibboleth.sso/SAML/POST"/></saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2016-05-04T23:38:37.927Z" NotOnOrAfter="2016-05-04T23:48:37.928Z"> <saml2:AudienceRestriction> <saml2:Audience>myapp-sp</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2016-05-04T23:43:37.927Z" SessionIndex="_7f550c02-ee46-41eb-96fc-884971e92651"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> </saml2:Assertion> </saml2p:Response> 

但是，在查看shibd日志时，我在事务日志中find以下内容：

 2016-05-05 00:00:58 INFO Shibboleth-TRANSACTION [10]: New session (ID: ) with (applicationId: default) for principal from (IdP: none) at (ClientAddress: 172.22.164.92) with (NameIdentifier: none) using (Protocol: urn:oasis:names:tc:SAML:1.1:protocol) from (AssertionID: ) 2016-05-05 00:00:58 INFO Shibboleth-TRANSACTION [10]: Cached the following attributes with session (ID: ) for (applicationId: default) { 2016-05-05 00:00:58 INFO Shibboleth-TRANSACTION [10]: } 

似乎shibd守护进程接收到一个空的SAML断言。 我已经在这个问题上困扰了很长时间了。 任何帮助将不胜感激。