Establishing Federation Trust

 

Conceptually within a Federation Trust configuration one party holds accounts of the participating users and another party serves applications to such users. The party holding the accounts is typically referred to as account domain and the ADFS server residing in this domain is referred to as Account STS (STS-A). The party serving the application is referred as resource domain and the ADFS server in this domain is called Resource STS (STS-R). This walkthrough will demonstrate how to establish a federation trust between account and resource domains, so that users from the account domain can access a claims-aware application in the resource domain.

The screenshots were taken in my lab environment where DMZ.NET domain is the account domain (users are coming from the Internet to authenticate against AD located in the DMZ). INSIDE.NET is the resource domain hosting an ASP.NET claims-aware application. Please note that DMZ.NET domain may also host applications, in effect being both account and resource domain. The idea here is that once a user authenticates against DMZ.NET STS she can access applications in both DMZ and INSIDE.NET domains by virtue of the federated trust. Of course any application participating in such trust would need to be explicitly configured with a relying party trust.

Prerequisites:

1. 2 separate AD forests (unless you plan to utilize authentication store other than AD).

2. Each forest needs to contain an ADFS STS, see this link for instructions on how to configure ADFS STS

3. In the resource domain setup an ASP.NET claims aware application and configure it with a relying trust with the STS-R in that forest. Instructions on this could be found here.

Add Relying Party Trust from Account STS to Resource STS

Perform steps below on the Account STS

Note: to the Account STS the resource STS is just another relying party which expects claims about the users in the account domain. So the steps below very closely resemble the steps required to configure trust with a claims-aware application.

For the account STS to be able to establish trust with the resource STS it will need to access the FederationMetadata.xml file generated by the resource STS. If the resource STS is accessible via network you can use the following URL format to access it https://FQDNnameOfTheServer/FederationMetadata/2007-06/FederationMetadata.xml. Also since the connection to the FederationMetadata.xml is made over SSL ensure that the certificate of the resource STS is trusted by the account STS host.

Click on Next

Click on Close

Click on Add Rule

Based on this rule once a user is authenticated by the account STS, STS will query AD to determine the userPrincipalName and the group membership of the user and package this information into a SAML token as claims (Name, Role), which will be sent to the resource STS.

 

Add Claims Provider Trusts on the Resource STS

Perform the steps below on the resource STS

Since the resource STS will not be authenticating users but rather accepting claims about the users from the account STS we will be setting up a Claims Provider Trust.

The same principals apply here as in the case with the account STS. Make sure that the SSL certificate of the account STS is trusted and that you have access to the FederationMetadata.xml either over network or this file was copied locally.

Click on Next

Click on Close and then Click on Add Rule

Remember that the claims will be coming from the account STS, so at the resource STS we can either pass the claims through or filter them before they are passed to the application.

For the sake of this walkthrough I will keep things as simple as possible, but capabilities exist here to apply some validation logic to filter out unexpected values. For example for the userPrincipalName we may specify that only values with a specific email suffix will be passed through (ex. dmz.net). Certainly this would be considered a good practice to shield the application from erroneous data at the resource STS level.

Click on Add Rule to add another rule this time for the Role claim

Notice that we created a pass through rule for each claim generated by the account STS. The claims for Name and Roles were chosen arbitrarily, the same process would apply to any other claims.

Pass claims from Account STS to the web application in the resource environment

The reason for the next several steps probably requires some explanation, since it may feel at this point that we are done with establishing the federation trust, but in fact not quite. We still need to configure how claims will be passed to the application which we are making available to the account domain.

Since a resource domain may have many different applications which are utilized by the account domain it may be possible that different applications may require different claims, hence we need to explicitly define at the application level how claims are passed to it. Again because, I am trying to keep this walkthrough as simple as possible, the claims will be passed to the applications as is, but specifying the claims handling rules is nevertheless required.

Perform this steps against the relying party trust for the application which we will be exposing to the account domain. For details on how to configure a test claims-aware application please, see this link.

The first rule (UserNameAndGroups) was created to allow users in the INSIDE domain to access this application, and it is not required if only the account domain users are accessing this resource.

 

Test SSO from account domain to web applications

Before testing ensure the following:

1. If you would like to achieve SSO experience ensure that DNS spaces of the resource and account domains are in the Local Intranet Zones in IE.

2. Client can resolve DNS names of the account and resource STSes.

3. Client trusts the certificates of both account and resource STSes

When connecting to the resource application for the first time, the resource STS will perform what is known as home realm discovery of the client. Make sure the pick the domain which corresponds to your account STS, since this is where the user needs to be authenticated.

For more details on the realm discovery and the ways to customize its behavior follow this link

 

Validate that the claims have come from your account STS.