I am building a SAML based federated authentication mechanism in which the IdP is ADFS 2.0 and the SP is Shibboleth running on Linux. I am able to do the following:

  1. Attempt to access a protected page, which redirects me to the IdP login page.
  2. Log in via the IdP login page and get returned to the protected page.
  3. Browse to spserver.internal/Shibboleth.sso/Session and see the returned attributes, including eppn.

I am, however, unable to extract the eppn attribute in the form of the REMOTE_USER header in PHP.

I have disabled attribute-policy.xml (commented it out in shibboleth2.xml).

I am missing something trivial, I suspect for the world of me I don't know what. Either PHP is not picking up the server variables set by Shibboleth or Shibboleth is never setting them. Any ideas?

Output from spserver.internal/Shibboleth.sso/Session

Session Expiration (barring inactivity): 479 minute(s)
Client Address: a.b.c.d
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Identity Provider: http://veragence.thesixthflag.com/adfs/services/trust
Authentication Time: 2014-10-28T11:55:23.947Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)

eppn: user.id@adfs.idp.server

Relevant line from shibboleth2.xml:

    <ApplicationDefaults entityID="https://spURL/shibboleth"
                     REMOTE_USER="eppn persistent-id targeted-id">

Relevant line from attribute-map.xml

<Attribute name="urn:oid:" id="eppn">
    <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>

Relevant output from shibd.log

2014-10-28 11:55:21 DEBUG Shibboleth.SSO.SAML2 [2]: extracting issuer from SAML 2.0 assertion
2014-10-28 11:55:21 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [2]: evaluating message flow policy (replay checking on, expiration 60)
2014-10-28 11:55:21 DEBUG XMLTooling.StorageService [2]: inserted record (_06157709-48ab-4701-90b2-b3ecea5df51f) in context (MessageFlow) with expiration (1414497564)
2014-10-28 11:55:21 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [2]: validating signature profile
2014-10-28 11:55:21 DEBUG XMLTooling.TrustEngine.ExplicitKey [2]: attempting to validate signature with the peer's credentials
2014-10-28 11:55:21 DEBUG XMLTooling.TrustEngine.ExplicitKey [2]: signature validated with credential
2014-10-28 11:55:21 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [2]: signature verified against message issuer
2014-10-28 11:55:21 DEBUG OpenSAML.SecurityPolicyRule.BearerConfirmation [2]: assertion satisfied bearer confirmation requirements
2014-10-28 11:55:21 DEBUG Shibboleth.SSO.SAML2 [2]: SSO profile processing completed successfully
2014-10-28 11:55:21 DEBUG Shibboleth.SSO.SAML2 [2]: extracting pushed attributes...
2014-10-28 11:55:21 DEBUG Shibboleth.AttributeExtractor.XML [2]: unable to extract attributes, unknown XML object type: samlp:Response
2014-10-28 11:55:21 DEBUG Shibboleth.AttributeExtractor.XML [2]: unable to extract attributes, unknown XML object type: {urn:oasis:names:tc:SAML:2.0:assertion}AuthnStatement
2014-10-28 11:55:21 INFO Shibboleth.AttributeExtractor.XML [2]: skipping unmapped SAML 2.0 Attribute with Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
2014-10-28 11:55:21 DEBUG Shibboleth.AttributeDecoder.Scoped [2]: decoding ScopedAttribute (eppn) from SAML 2 Attribute (urn:oid: with 1 value(s)
2014-10-28 11:55:21 DEBUG Shibboleth.SSO.SAML2 [2]: resolving attributes...
2014-10-28 11:55:21 DEBUG Shibboleth.AttributeResolver.Query [2]: found AttributeStatement in input to new session, skipping query
2014-10-28 11:55:21 DEBUG Shibboleth.SessionCache [2]: creating new session
2014-10-28 11:55:21 DEBUG Shibboleth.SessionCache [2]: storing new session..
  • Problem solved. I was not protecting the PHP file with an .htaccess file, so in the absence of needing authentication the PHP file was presented without asking for credentials. – pete.k Oct 28 '14 at 14:20
  • 1
    Please post your solution as an answer and mark it as correct. – D34DM347 Dec 2 '15 at 22:04

I think that the answer that @pete k provides, is correct - although I didn't understand it at first. For others with limited Apache knowledge (like me) trying to configure Shibboleth, Shibboleth doesn't automatically make its server variables available to every page in your application, unless you explicitly tell it to. You can do this by putting the following sort of code either in a .htaccess file, or in a file in /etc/httpd/conf.d/

<Location /location-you-want-to-access-server-variables>
   AuthType shibboleth
    # ShibRequestSetting requireSession 1
   Require shibboleth

If you uncomment the middle directive, pages in the specified location will be forced to authenticate via shibboleth. If you leave it commented, authorisation won't be forced, but you will have access to your shibboleth server variables. In PHP, for example, they would be found in $_SERVER - although of course they won't be set until you do authenticate via Shibboleth.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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