1

I'm attempting to use mod_shib to provide with SSO for an application that is running in a tomcat container. There's an Apache server, running as a reverse proxy, in front of the Tomcat container.

I set up mod_shib with the following proprities in shibboleth2.xml:

<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"/>

Here's my apache2 conf for this vhost:

<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>

If I navigate to server.com/myapp, I'm redirected to the IDP login page. I used a tracer to identify what's going on and it seems as though the IDP redirects me to make a POST request to http://server.com/Shibboleth.sso/SAML/POST with the following SAML assertion:

<?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>

However, when looking through the shibd logs, I find the following in the transaction logs:

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]: }

It seems as though the shibd daemon receives an empty SAML assertion. I've been scratching my brain around this for quite some time. Any help would be greatly appreciated.

1

The IDP was configured to make a POST request to http://server.com/Shibboleth.sso/SAML/POST which maps to the SAML 1.1 protocol. As you can see from the assertion, the protocol is SAML 2.0. Therefore I had to change the ACS URL to http://server.com/Shibboleth.sso/SAML2/POST

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.