LDAP Question

[Cantor, Scott]

On 7/9/14, 2:11 PM, "Mark Gibson" <mgibson at taftcollege.edu> wrote:

>                I have my system setup and working up to a certain point.
>When I attempt to login to a site I get the following error ³One or more
>Shibboleth attributes were not passed correctly: eppn, displayName,
>unscoped-affiliation.

You're *not* releasing one or more of them. So don't think you are (you
seem to think so later on in your note).

Debugging-wise, those imply Shibboleth SP attribute mappings, so you can
assume that the underlying SAML attributes it's looking for are the
standard OID-named attributes names for eduPersonPrincipalName,
displayName, and eduPersonAffiliation. Those are all default definitions
in the software, but only you know how they're meant to be populated from
AD or otherwise, and what you're calling them in the resolver so that you
can verify the filter policy is in place for them.

And your logs are telling you exactly what you're releasing to the SP. And
if you look, it will tell you that nothing is being released, or at least
no attributes.

>  When I look at the log file I see this error
> 
>WARN 
>[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2Profil
>eHandler:555] - Error resolving principal name for SAML request
>'_9c1a632382541a99b6674e63f6228bb6' from relying party
>'https://ci.control.openccc.net/shibboleth'.
> Cause: Unable to resolve principal, attribute request ID and subject
>name identifier may not be null

That's a fairly obscure one, and it means a couple of extra things are
wrong, but also tells me you're releasing no attributes.

The warning implies that the SP is performing an attribute query, which it
will only do if it receives no attributes. It's also a SAML 2 query, which
you should have no need to support and your metadata shouldn't be
including. That's just overhead for all concerned.

The actual warning also means something else is wrong with the
configuration. I don't know what kind of NameID you're passing to the SP,
but it's not something the IdP is managing to reverse-map back into a user
ID, which means it's some non-default thing you configured it to supply in
the assertion. I really couldn't say what.

> 
>I do have my attribute-filter.xml setup the way that OpenCCC Apply
>requests.
>Also I know that I am authenticating against my LDAP Server, which is
>Active Directory. Somehow I need to tie in the Attributes that they are
>getting requested to responses from my AD. Any help would be appreciated.

What they're expecting is clear enough, but what you have to do is
entirely a local consideration unless you are directly exposing LDAP
attributes already pre-cooked from the AD. That's about the only case
where somebody could say what the attribute definitions would look like,
mostly what's already in the file by default in examples.

-- Scott