Understanding Attributes Passing

[Sam Agnew]

Peter,

Thank you. I had to configure the SP to accept the other attributes in attribute-map.xml.

Sam


On Apr 3, 2014, at 3:47 PM, Peter Schober wrote:

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<mailto: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.
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider
for the attribute resolver, or
edu.internet2.middleware.shibboleth.common.attribute.filtering.provider
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
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


--
Sam Agnew
System Administrator
IT Department
Weill Cornell Medical College in Qatar



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140408/a55e3a40/attachment.html