Shibboleth Issue - Attribute-filter.xml

[Peter Schober]

* Byron Sayres <bsayres at rcc.mass.edu> [2016-04-08 17:50]:
> Thanks for the replies! Please look at the new files and let me know
> if this configuration looks correct. Obviously, I need to pass mail,
> givenName, sn, and sAMAccountName. Sorry, if this is repetitive…I

That's not only not obvious, it contradicts what you wrote before:

* Byron Sayres <bsayres at rcc.mass.edu> [2016-04-07 17:48]:
> The requested values to map are
> x-r25-first-name = urn:oid:2.5.4.42
> x-r25-family-name = urn:oid:2.5.4.4
> x-r25-email-work = urn:oid:0.9.2342.19200300.100.1.3
> x-r25-user = urn:oid:1.3.6.1.4.1.5923.1.1.1.6

"urn:oid:1.3.6.1.4.1.5923.1.1.1.6" is the formal name for
eduPersonPrincipalName (ePPN). Now you're saying you don't need to
release ePPN but need to release "sAMAccountName" (whatever the formal
attribute name for this is)?
I don't care either way but you need to know what you should be
sending.

Also:
> Please look at the new files

Is not what I asked you to do:

* Peter Schober <peter.schober at univie.ac.at> [2016-04-07 18:32]:
> First thing would be looking at your IDP logs (idp-audit.log) to find
> out what atributes you actually released to that SP.

Why fly blind when you can see what your IDP does and does not in the
logs?

> attribute-resolver.xml
> <resolver:AttributeDefinition id="mail" xsi:type="ad:Scoped" scope="%{idp.scope}" sourceAttributeID="mail">
> <resolver:Dependency ref="bhccldap" />
> <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString" name="urn:mace:dir:attribute-def:mail" />
> <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
> </resolver:AttributeDefinition>

No, mail is not a Scoped attribute (as per the eduPerson concept of
scope). The Shibboleth IDP comes out of the box with a correct
defintion for mail, why not use that and simply change the Dependency?
(Or better yet, leave the name of the dependency the same and create a
DataConnector with that exact name. Then all you have to do is
uncomment pre-made definitions.)
The correct type is "ad:Simple".

> <resolver:AttributeDefinition id="givenName" xsi:type="ad:Scoped" scope="%{idp.scope}" sourceAttributeID="givenName">

Same thing.

> <resolver:AttributeDefinition id="sn" xsi:type="ad:Scoped" scope="%{idp.scope}" sourceAttributeID="sn">

And again.

> <resolver:AttributeDefinition xsi:type="ad:Simple" id="sAMAccountName" sourceAttributeID="sAMAccountName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
> <resolver:Dependency ref="bhccldap" />
> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sAMAccountName" />
> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.2.840.113556.1.4.221" friendlyName="sAMAccountName" />
> </resolver:AttributeDefinition>

>From http://oid-info.com/get/1.2.840.113556.1.4.221 this looks OK.
But it is /not/ eduPersonPrincipalName, what you said the SP told you
to send.

> <!-- Release mail, givenName,sn, and sAMaccountName -->
> <afp:AttributeFilterPolicy id="releaseToAnyone">
> <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
> 
> <afp:AttributeRule attributeID="mail">
> <afp:PermitValueRule xsi:type="basic:ANY" />
> </afp:AttributeRule>
> 
> <afp:AttributeRule attributeID="givenName">
> <afp:PermitValueRule xsi:type="basic:ANY" />
> </afp:AttributeRule>
> <afp:AttributeRule attributeID="sn">
> <afp:PermitValueRule xsi:type="basic:ANY" />
> </afp:AttributeRule>
> 
> <afp:AttributeRule attributeID="sAMAccountName">
> <afp:PermitValueRule xsi:type="basic:ANY" />
> </afp:AttributeRule>
> </afp:AttributeFilterPolicy>

What the IDs now all match that and that will release the named
attributes to also the SP you're trying to federate with, the above
(releasing PII to anyone known via metadata) is *not* a sane attribute
release policy -- unless you only have that one SAML SP and you don't
have SAML Metadata configured for /any/ other SPs.

Technically it looks OK, but don't stop there. You'll need to develop
a workflow and policy what data to send where.
If you're an InCommon memeber talk to their support to get you started
on the right foot.

Your logs will tell you whether you have been successful. So use them!
-peter