Understanding Attributes Passing

Peter Schober peter.schober at univie.ac.at
Thu Apr 3 08:47:11 EDT 2014

Not fully clear what you're asking. I'm guessing it's "I run both a
Shib IDP and Shib SP and I'm trying to pass attributes from the former
to the latter, but some are not making it through"?

* Sam Agnew <saa2012 at qatar-med.cornell.edu> [2014-04-03 13:54]:
> We are trying to establish how to pass metadata in our test
> Shibboleth setup. We expect to be joining inCommon when we go
> production so we have set up a test AD with the eduPerson schema
> added.

Fyi, metadata is something else in SAML, you're talking about data (or
"attributes", more commonly).

> Also we are asking for some POSIX attributes like:

Asking how? "We" is the SAML SP here? And you're asking the SAML IDP
to send certain attributes? Does the IDP have all desired attributes
available from LDAP (if not that's what needs fixing). The IDP's log
files will tell you what the IDP has available and what not (mybe
increasing the log level to DEBUG for e.g.
for the attribute resolver, or
for the attribute filter).

> We are receiving a mixed bag and I'm feeling like there's something
> I'm not quite understanding. We receive:

Recieve from whom? When you (as the SAML SP) don't recieve what you
expect that's for you to take up with the issuer of that data (the
SAML IDP), but first make sure you really don't recieve it but
checking the SP's log files (see below).

> We receive an eppn (eduPersonPrincipalName?) which is not the
> populated value but rather the sAMAccountName+ at +dnssuffix

What is the populated value then? Also check the spec so you know what
to expect, http://macedir.org/specs/eduperson/
What you got above seems like something I would expect to recieve.

> We receive an unscoped-affiliation which appears to be the value for eduPersonAffiliation
> We get nothing for uid
> We get nothing for eduPersonNickname
> We get nothing for eduPersonPrimaryAffiliation

> I can see all the values being asked for:
> 12:26:37.859 - INFO [Shibboleth-Audit:1028] - 20140403T092637Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_08ae5fccee401616aa52a038eb6aa180|https://sp.qatar-med.cornell.edu/shibboleth|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://idp.qatar-med.cornell.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_c5a9e00627597559c401066471b214c3|student2013|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|uid,eduPersonPrincipalName,eduPersonAffiliation,eduPersonPrimaryAffiliation,surname,givenName,eduPersonNickname,commonName,transientId,email,displayName,|_4e803ba53b7bd0e909551a8ef7e6b138||

These are not the values "being asked for", these are the values
*sent* by that IDP as far as the IDP is concerned. If you don't
"receive" them on the SP side check the SP's log files, e.g. look for
"skipping" in shibd.log
Note that by default the Shib SP will only map eduPerson attributes
and ignore all others. You'd need to uncomment the existing
definitions (using the urn:oid syntax, as you're usingn SAML2 above)
in your SP's attribute-map.xml

More information about the users mailing list