I need to connect an AD FS 3.0 identity provider (idP) to a Shibboleth service provider / relying party I don't control. Unfortunatley, AD FS and Shibboleth don't quite use the same format for claims/attributes.
There's a lot of information out there one the web about this, and the need for two rules (one to retrieve the value from Active Directory, and one to transform it to match what Shibboleth expects), but much of it is written for AD FS 2.0 or uses the e-mail address as the Name ID (I really need SamAccountName for this).
How can I get my AD FS idP to produce a claim using the windows-account-name that Shibboleth will accept?
I finally found the answer here:
https://cccnext.jira.com/wiki/spaces/CSF/pages/147817839/Attributes+for+the+Proxy+AD+FS
That link lists custom rule pairs for a number of Active Directory fields, including SamAccountName / windows-account-name.
The rules I used look like this:
@Rulename="Get sAMAaccountName"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("urn:oid:1.2.840.113556.1.4.221"), query = ";sAMAccountName;{0}", param = c.Value);
@Rulename="Convert sAMAccountName / uid xml"
c:[Type == "urn:oid:1.2.840.113556.1.4.221"]
=> issue(Type = "urn:oid:0.9.2342.19200300.100.1.1", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");
These were included as part of a PowerShell script, but you can add them via the AD FS interface by adding custom claim rules.
This may still require a change on the Shibboleth end. Before I got this far, a service tech on the other end reported seeing attributes that were excluded, and making a change to allow that attribute. However, that was a different set of rules. I don't know if this set of rules is taking advantage of that change or not.