ADFS to Shibboleth

[Peter Schober]

* Nancy Kerr <Nancy.Kerr at msvu.ca> [2018-06-27 20:24]:
> We are trying to transfer the info that is in the EmployeeID
> attribute in AD to a Shibboleth.  We have the following claim rules
> set-up.
> 
> c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
> => issue(store = "Active Directory", types = ("EmployeeID"), query = ";employeeID;{0}", param = c.Value);
> 
> 
> c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
> => issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimpropert ies/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");

Your SP log files will tell you that the SP is recieving the attribute
but that it is throwing away the value:

You're encoding that attribute to the formal name of the
eduPersonPrincipalName attribute. That attribute has built-in policy
rules in the Shibboleth SP software in order to prevent one IDP
asserting values in the domain ("scopes", specifically) of another
IDP.

The proper way to fix that (and keep that protection the software is
providing) is by extending the asserting IDP's SAML Metadata with a
shibmd:Scope attribute, see for example an IDP that asserts
eduPersonPrincipalName values that look like "whatever at aco.net":

https://met.refeds.org/met/entity/https%3A//idp.aco.net/idp/shibboleth/?viewxml=true&federation=aconet-identity-federation-eduidat
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <md:Extensions>
    <shibmd:Scope regexp="false">aco.net</shibmd:Scope>
  etc.

If that's already in place with a proper scope/domain then the
asserting IDP is asserting the wrong scope.

You could also work around that brokenness by turning off the
SP's protection for scoped attributes, but that's a bad idea.

If you did not intend for the attribute
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" to end up
as eduPersonPrincipalName specifically you can map it to a different
attribute on-the-wire, of course, in which case the SP also cannot
offer the same protection, as that's specific to a few attributes.

-peter