ADFS to Shibboleth

[Nancy Kerr]

We are looking to sync\transfer EmployeeID from ADFS (on prem) to an external Shibboleth system.

Nancy


Nancy A. Kerr
LAN Administrator
Mount Saint Vincent University
166 Bedford Highway
Halifax, NS  B3M 2J6

Tel: (902) 457-6685
Fax: (902) 445-4121
www.msvu.ca

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Peter Schober
Sent: Thursday, June 28, 2018 7:33 AM
To: users at shibboleth.net
Subject: Re: ADFS to Shibboleth

* 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/windowsaccoun
> tname", 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/claimproper
> t 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
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net