Shibboleth IdP not passing AD LDAP attributes to TestShib SP

[Matthew X. Economou]

Todd James writes:

> it seems that the LDAP attributes are being returned successfully
> according to ldaptive DEBUG logs, but the attributes are not being
> passed back to the SP.

I don't see where you configured the attributes returned by the LDAP
DataConnector, so it's possible you've configured attribute release
incorrectly.  When you log into the IdP, you should be prompted by
default to consent to releasing attributes to the SP.  If you don't see
that consent screen, then you aren't releasing anything to the SP.  In
general you should release the REFEDS R&S attribute bundle to all SPs.
Here's an example attribute resolver configuration that includes the
REFEDS R&S attribute bundle plus attributes for Slack, Meraki Dashboard,
and Amazon Web Services:

https://gist.github.com/xenophonf/1645e22c9dbd7fbfc76d4d8aac6a09f6

And here's the corresponding attribute filter configuration that
releases the REFEDS R&S attribute bundle to all SPs plus the specific
attributes needed by services like Slack, Meraki Dashboard, and Amazon
Web Services:

https://gist.github.com/xenophonf/dd45138aed0215f318158d41123c06b6

There's another log setting that will cause Shibboleth to log the
AuthnResponse.  I think you need to set idp.loglevel.messages or
idp.loglevel.encryption to DEBUG in idp.properties.

If you aren't encrypting your responses, you can use SAML Tracer
(https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) to easily
capture the SAML AuthnResponse.

> FWIW, I would prefer to use sAMAccountName as the canonical username
> for our users, but allow them to authenticate using any email alias on
> their account. In other applications, finding the correct account by
> email address is done using a query like this in AD:
> (proxyAddresses=smtp:EMAIL_ADDRESS)

You can change idp.authn.LDAP.userFilter in ldap.properties to do this.
For example, I use the following, which allows users to log into the IdP
with their username, email address, or Kerberos UPN:

      (|(sAMAccountName={user})
        (mail={user})
        (userPrincipalName={user}))

I also allow users to provide their NetBIOS domain name, but I strip off
the domain part in client-side JavaScript.  I didn't think to try
searching on proxyAddresses, so I might try that on my test IdP.

> ******** attribute-filter.xml ********
>        <PolicyRequirementRule xsi:type="Requester"
> value="https://idp.testshib.org/idp/shibboleth" />

This is wrong.  An IdP release attributes to a service provider, so a
Requester PolicyRequirementRule's value must be the entity ID of an SP,
not an IdP.
 
> ******** ldap.properties ********
>
> idp.authn.LDAP.useSSL                           = false

You should enable LDAPS on all of your domain controllers.  I've
deployed both AD CS and Let's Encrypt dns-01-validated certificates on
my domain controllers.

> idp.authn.LDAP.userFilter                       =
> (proxyAddresses=smtp:{user})

Note that you need to configure a similar-looking filter in the LDAP
DataConnector in the attribute resolver configuration.  For example:

https://gist.github.com/xenophonf/1645e22c9dbd7fbfc76d4d8aac6a09f6#file-
attribute-resolver-xml-L119

> # I have tried both of the following and suspect this may be where the
> problem is? AD doesn't typically use uid
> #idp.attribute.resolver.LDAP.searchFilter        =
> (uid=$resolutionContext.principal)

Correct.  You would use sAMAccountName instead of uid.

> idp.attribute.resolver.LDAP.searchFilter        =
> (proxyAddresses=smtp:$resolutionContext.principal)

I ended up putting the search filter directly into the DataConnector
configuration, but by default it uses the value of this Java property.
It shouldn't matter where you set it as long as the search is the same
as used for the userFilter.

Again, you don't set idp.attribute.resolver.LDAP.returnAttributes, which
means the LDAP connector won't return anything at attribute resolution
time.  Either set it here or directly in the DataConnector, which is how
I did it.

> ******** attribute-resolver.xml ********
> 
>    <AttributeDefinition xsi:type="Simple" id="uid"
> sourceAttributeID="uid">
>        <Dependency ref="LDAP" />

Not only does AD not have a uid attribute, you aren't returning
sAMAccountName (the correct attribute) in the DataConnector
configuration.  Refer to my example for a working config.

Hope this helps,
Matthew

-- 
"The lyf so short, the craft so longe to lerne."