Shibboleth Not Releasing Needed Attributes

[Brian Moon]

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

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

>
> On Apr 5, 2017, at 4:20 PM, Bob Dill <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170405/734a15a7/attachment.html>