ADFS – Combining Claims from Provider Trusts and AD

adfsauthenticationsingle-sign-on

As part of implementing a SharePoint 2013 installation, I have configured SSO with ADFS on Windows Server 2012R2.

There are two separate AD forests, one as part of the Hosted SharePoint/ADFS and one onsite corporate forest.

Currently, I have the corporate AD set up as a Claims Provider Trust in the SharePoint ADFS. I am able to successfully pass through the email attribute from the corporate AD to SharePoint.

What I want to achieve is some form of claim injection from the Hosted AD Forest as part of logging on with a Corporate AD account.
Specifically, users will be members of security groups to determine SharePoint licencing. For security reasons I do not want to get this claim information from the Corporate AD as this means users will be able to change their licencing status.

So, all users will actually have an AD account in both forests. Single Sign On provided by entering their Corporate credentials as part of the sign in process.

Is there some way that I can tell my hosted ADFS to look for a user in it's own AD forest which matches the incoming Email Address Claim from the Corporate ADFS, and then inject the Role claim from the hosted forest with said email claim?

Please see the picture below for what I'm trying to achieve (Sorry for the quick MS Paint drawing!):
ADFS Problem Description

How do I achieve steps 4 & 5?

Current Claim Rules
On the Hosted ADFS, Acceptance Transform Rules for the Corporate Claim Provider Trust:

Pass Through incoming E-mail Address claim, pass through all values

On the Hosted ADFS, Issuance Transform Rules for the SharePoint Relying Party:

Send LDAP Attributes as Claims (UPN -> UPN, Token Groups -> Role, Email-Addresses -> Email)
Pass Through incoming E-mail Address claim, pass through all values

Best Answer

Yes, that should work. If you control the claim rules on the hosted ADFS and if you have some key from the Corp ADFS in a claim, then you can do the regular AD search claim rule with that key.

Related Solutions

ADFS v.2.0 transitive trust in a federation scenario

Well, since nobody did answer, i took the time, setup a test lab and sniffed the HTTPS traffic. Here are my research results in case anybody else will ever come across this thing:

I still got no official source for this questions
First off: yes, transitive trust is possible and there is no way to block it except of legal affairs. A propper SLA is the basis for any federation scenario anyways.
There is no special "setting" to disable or enable it, but using the claims rule engine a trusted partner may configure ANY kind of outgoing claims IF ANY kind of incomming claims are detected, so there is no way to "protect" illegal access.
In my tests, none of the rule templates that come with ADFS changed the OriginalIssuer property of the claims. One may think: Okay so i can use that property to verify the original source of any claim and build a filter to only allow claims comming directly from (and not traversed through, which by default only affects the Issuer but not the OriginalIssuer property) a trusted partner. But thats wrong, why? Look at the next line.
As i said, the default templates don't touch the OriginalIssuer property. But you may create custom rules using the rule engine. Using that one, you can change pretty much every claim type, value and their properties. And yes: also the OriginalIssuer. So to the federation provider it looks as the claims are comming directy from the trusted partner, where in reality they're only transformed there.

So, what i would suggest to atleast minimize "transitive" scenarios if they're unwanted, is to check for the OriginalIssuer. It dosn't protect from transitive logins, but a admin would have to explicitly configure it - which would make legal affiars much more easier in a case of SLA voilation. Also, i'm not thinking of the possibility to change the OriginalIssuer as a "bug", in fact: even without that feature, every thrid party software could always make it able to act as a proxy between backend systems and the trusted identity provider. For example the IdP could create shadow accounts for partner (C) - so there will always be a workaround since when using federation, you're giving away the control on who is able to delegate access rights to specific ressources.

Anyway - if you have been as curious as i about how ADFS 2.0 handles transitive trusts, now you know without the need to build a testlab and sniff HTTPS traffic.

Issue multiple claims in a single rule

An ADFS rule is composed of a condition, the => token, a command (issue or add), and terminated with a semicolon. You cannot issue multiple literals per rule, but you can use powershell to make it easier to work with.

Instead of going in the UI, and going through that wizard 5 times, you can use Set-AdfsRelyingPartyTrust to set all of the rules at once.

Set-RelyingPartyTrust -TargetName SharePoint_Prod -IssuanceTransformRulesFile c:\drop\rules.txt

where rules.txt looks like

c:[Type == incomingClaim, Value =~ incomingMatch] => issue(Type = type1, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = value1, ValueType = c.ValueType);
c:[Type == incomingClaim, Value =~ incomingMatch] => issue(Type = type2, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = value2, ValueType = c.ValueType);
c:[Type == incomingClaim, Value =~ incomingMatch] => issue(Type = type3, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = value3, ValueType = c.ValueType);
c:[Type == incomingClaim, Value =~ incomingMatch] => issue(Type = type4, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = value4, ValueType = c.ValueType);
c:[Type == incomingClaim, Value =~ incomingMatch] => issue(Type = type5, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = value5, ValueType = c.ValueType);

The difference relative to the UI? I used copy and paste.

Best Answer

Related Solutions

ADFS v.2.0 transitive trust in a federation scenario

Issue multiple claims in a single rule

Related Topic