Freigeben über

Best practices for establishing federation trust between two organizations.

  • Artikel

Hi,

Recently, I saw a few questions on best practices for establishing federation trusts. I've listed out a few based on past experience with customers. There definitely may be more. Feel free to provide feedback via the comments section.

First some terminology:

IDP  Identity provider that authenticates the user
 FedP  Federation Provider that accepts tokens from an IDP, validates the token and issues a new token for the application
 Relying Party (RP) Trust  Object that represents the application on the FedP. Note that a FedP can also be represented in the same manner on the IDP
 Claims Provider (CP) Trust  Object that represents the IDP on the FedP

 

Before we get to the best practices, a couple of operational procedure references

  1. How to create a Relying Party Trust in ADFS
  2. How to create a Claims Provider Trust in ADFS

Now onto best practices.

  • Use auto-update of federation metadata if possible on both sides. This allows roll over of keys in an automated fashion without any manual intervention. This is feasible if these were ADFS instances on both sides.
    • If auto-update is not possible, establish an operational procedure.
  • Agree on the claims that is required for the Identity Provider (the IDP that authenticates the user) to issue to the Federation Provider (the
    FedP that accepts these claims).
    • Decide upfront on what is the ID for the user that is immutable (does not change). This could be UPN, email, employeeID based on what is considered as unique and would not change for the user authenticated by the IDP.
  • If you are the Federation Provider.
    • Pass through claim information that is only agreed upon in #2
    • It is a good practice for you to add a claim that represents the IDP in the claims acceptance rules on the CP trust. This is useful when you want additional logic on the RP trust later that may need to differentiate across different IDP’s.
    • [Optional] Add validation rules in the claims acceptance rules on the Claims Provider Trust for the IDP. For example, you only want to pass through a certain UPN suffix or email suffix that the IDP is responsible for. This is good security practice.
    • [Optional] If you want to normalize certain claims values that works across all the RP trusts in the FedP, do so in the claims acceptance rules on the CP trust for the IDP.
    • [Optional] If you need to augment additional claims data that works across all the RP trusts in the FedP, do so in the claims acceptance rules on the CP trust for the IDP. Otherwise you can always augment in the RP trust rules if this is RP specific.
    • [Optional] Optimize HRD experiences as needed via sign-in customizations offered in Windows Server 2012R2
    • [Optional] Enforce additional authorization rules for specific apps.
  • If you are the Identity Provider
    • Only issue claims that you have agreed upon in #2
    • Add additional authentication rules on the RP Trust that represents the FedP based on the conditions that you would need MFA. If the user were accessing multiple applications behind the FedP, these rules would be applicable to all the applications. Read this blog post from Ramiro to understand the rule logic.

Hope this provides some of the best practices. If you have additional best practices, please add them in the comments section.

Thanks//Sam

Comments

  • Anonymous
    October 26, 2015
    Hi Sam. Is it possible to construct a URL for a partner (our claims provider) so that their users go through HRD, authenticate and end up at the target app (our relying party) - by just clicking on the link?