Shibboleth Not Releasing Needed Attributes

[Bob Dill]

Thanks so much guys!

After enabling debugging, I found that no attributes were even returned from LDAP. It turns out that the default value for idp.attribute.resolver.LDAP.searchFilter   was set to   (uid=$resolutionContext.principal), and I discovered that we do not even have a uid in our AD. I changed the filter to (sAMAccountName=$resolutionContext.principal). I also changed PolicyRequirementRule to reflect the correct AW SP URL <PolicyRequirementRule xsi:type="Requester" value="https://cameron.academicworks.com/shibboleth-sp" /> as suggested. Finally, I have attributes being returned. I have yet one more question regarding multiple bind points for another thread, but I feel I’m a lot closer to getting this to work.

Thanks again,

Bob

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Brian Moon
Sent: Wednesday, April 05, 2017 4:37 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth Not Releasing Needed Attributes

In troubleshooting something like this, I find it useful to turn up the debug logging.  In conf/logback.xml, modify idp.loglevel.idp and idp.loglevel.ldap to DEBUG and restart.  The tail logs/idp-process.log while you test the login.  In the logs you will then see the LDAP connection happening, you will see the LDAP attributes that come back, you will see the attribute resolution happening, and then finally you will see the attribute filtering process.  Somewhere in there you will hopefully see the problem.

And as Michael mentioned, that entity ID may not be correct (in which case you will see in the logs that the filtering is where the breakdown is happening).  If you are not sure of the entity ID, you may want to take a look at using RequesterRegex in the filter (https://wiki.shibboleth.net/confluence/display/IDP30/RequesterRegexConfiguration).

Cheers!


Brian Moon
Senior System Administrator
Enterprise Systems
Santa Clara University
Office: 408.554.4830
bmoon at scu.edu<mailto:bmoon at scu.edu>

On Wed, Apr 5, 2017 at 2:32 PM, Michael A Grady <mgrady at unicon.net<mailto:mgrady at unicon.net>> wrote:

On Apr 5, 2017, at 4:20 PM, Bob Dill <rdill at cameron.edu<mailto:rdill at cameron.edu>> wrote:

Hi All,

I am working to authenticate students for scholarship information provided by Academic Works (AW). I have successfully installed and tested Shibboleth with testshib, but I still can’t authenticate with AW because Shibboleth is not releasing uid or mail attributes.

Inside my ldap properties, I have
idp.authn.LDAP.returnAttributes                 = passwordExpirationTime,loginGraceRemaining,uid,mail

Technically, that property in ldap.properties was meant for attributes to be returned at the Authentication stage, not at the Resolver stage. There was another property in the resolver section of the property file,  but everyone decide that trying to manage the set of attributes to be returned to the resolver as a property in that file is a mistake. Which is why a resolver specific property is no longer in that file. Just put the list of attributes to be returned to the resolver *in* the attribute-resolver Data Connector directly.



Inside my attribute-resolver.conf, I have
<AttributeDefinition id="uid" xsi:type="Simple" sourceAttributeID="uid">
        <Dependency ref="myLDAP" />
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:uid" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false" />
    </AttributeDefinition>

    <!--
    In the rest of the world, the email address is the standard identifier,
    despite the problems with that practice. Consider making the EPPN value
    the same as your official email addresses whenever possible.
    -->
    <AttributeDefinition id="mail" xsi:type="Simple" sourceAttributeID="mail">
        <Dependency ref="myLDAP" />
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
    </AttributeDefinition>

<DataConnector id="myLDAP" xsi:type="LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseDN1}"
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:false}"
        connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
        trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}"
        responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
        <ReturnAttributes>%{idp.authn.LDAP.returnAttributes}</ReturnAttributes>
        <FailoverDataConnector ref="myLDAP2" />
    </DataConnector>

Finally, in my attribute-filter.xml file, I have
    <!-- Release some attributes to an SP. -->
    <AttributeFilterPolicy id="example1">
        <PolicyRequirementRule xsi:type="Requester" value="https://cameron.academicworks.com/Shibboleth.sso" />

Are you sure that is actually the entityID value in the Academic Works metadata you have? I've seen Academic Works entityIDs in the past, and none ended in 'Shibboleth.sso'. The value you list for Requestor in that rule must be the *entityID* for the SP, check your Academic Works metadata to see what that value is.



--
Michael A. Grady
IAM Architect, Unicon, Inc.




--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170406/94756f7f/attachment-0001.html>