Server Fault Asked by pete.k on November 22, 2021
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:
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
Miscellaneous
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)
Attributes
eppn: [email protected]
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:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
<AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
</Attribute>
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:1.3.6.1.4.1.5923.1.1.1.6) 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..
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
</Location>
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.
Answered by charlesdeb on November 22, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP