Windows Server 2016 ships with version 4.0 of Active Directory Federation Services (ADFS), which turns out to play a bigger and bigger role in providing SSO capabilities for companies using the Azure Cloud Services. Watch the Ignite 2017 session of Principal Group Program Manager Sam Devasahayam from the Microsoft Identity Divison for more information about new ADFS extensions like “Hello for Business” or the Azure Stack support for ADFS.
One of the most important changes when comparing ADFS version 3.0 of Windows 2012 R2 with ADFS 4.0 of Windows 2016 are the Access Control Policies, which act now as the standard method of granting access, while we no longer see the Issuance Authorization Rules of ADFS 3.0 in the AD FS GUI by default.
However, ADFS 4.0 still supports Issuance Authorization Rules. This post will show how they can be used with ADFS 4.0 and why it makes sense.
Let’s first have a quick look on the modern easy way of granting access by using Access Control Policies:
ADFS 4.0 Access Control Policies
Access Control Policies in ADFS 4.0 allow to configure access to a Relying Party Trust via ADFS authentication based on several criteria.
You can either create Access Control Policies directly adding a new Access Control Policy in the Access Control Policy Container of the AD FS Management GUI (like stand-alone without connecting it to Relying Party Trust) or you can create it when creating the Relying Party Trust. The same functionality can be achieved via Powershell by using the appropriate ADFS commandlets.
Rule Editor of Access Control Policies
You can only assign one single Access Control Policy to one Relying Party Trust, but the Access Control Policy itself can consist of several rules, which are all “Permit” rules. Inside the rule, you can select multiple conditions, which are connected by, AND operators and multiple “except conditions that are connected by OR conditions.
Example for a Policy statement:
Permit users who access ADFS from a specific network AND who are member of a specific group, but even if those conditions are met, deny (Except) access when users are member of a deny group OR when users connect from devices with wrong trust level.
No matter how many rules are defined in an Access Control Policy – as long as the requesting user and device meet the conditions of one of these rules, the policy is valid and ADFS will grant access. If no condition is met, users are not allowed to use the Relying Party Trust and therefore are “denied”.
Multiple Rules in Access Control Policy
Some of the rules allow us to use parameters instead of defined values when creating an Access Control Policy. By doing this, we create rather an Access Control Policy template than a finalized Access Control Policy. Templates give us the advantage, that we can assign the same Access Control Policy to multiple Relying Party Trusts and still use different settings.
In the list view of the Access Control Policy container, you can see in the third column which Access Control Policies are parameterized and which are not. One of the pre-defined templates is based on group membership. The name of the group cannot be set in the template itself, but when it is assigned to a Relying Party Trust.
Access Control Policy with parameters in rule
Assigning the Control Access Policy to a Relying Party Trust allows replacing parameters by selecting groups from Active Directory.
Replacing the parameter placeholder by selecting groups
Another special type of rule in an ADFS Access Control Policy is to permit users (or devices) “with specific claims in the request”.
Based on an incoming claim you can decide by various operators including regex matching, who will get access by this rule.
Permit Rule for filtering on specific claims
||You can only use claim types that are defined by your incoming claims. For example, if you want to filter by e-mail address suffix, you have to be sure that claim type E-Mail Address is part of the incoming claim. Therefore, this special rule depends heavily on the resource’s (cloud application) behavior in sending incoming claims.
Assigning and Removing Access Control Policies
You can create a Relying Party Trust with the AD FS Management GUI without assigning an Access Control Policy at all, but you cannot remove an existing one from a Relying Party Trust completely by using the GUI. You only can edit and replace by another one. However, the ADFS Powershell commandlets provide a way to achieve that and we described it in part 2 of this blog post.
||Be aware, as long as you do not assign an Access Control Policy to a new Relying Party Trust, access to the Relying Party Trust is denied for all users automatically.
Access Control Policies vs. Issuance Authorization Policies
Overall, Access Control Policies are a very handy and administrator-friendly way of configuring complex access structures for securing Relying Party Trusts.
However, the rule editor does not allow you to make extended filters based on group names other than selecting specific group names one by one, which is too static for many Cloud scenarios.
We often see the case where all users should have access to a SAML Cloud Application whenever they are member of special Cloud security groups that start or end with a special syntax.
To fulfill such a request, using the Claim Rule Language with Issuance Authorization Rules is pretty much straightforward and very flexible when adding multiple conditions. We will show the advantages of Issuance Authorization Rules by playing the following use case:
Use Case Example:
All users who are member of any security group starting with CLOUD_ should get access to the Relying Party Trust (and get authorization for the Cloud application). If they are also member of any group starting with DE_, they should get a denial for that Relying Party Trust. Additionally, access is limited only to users who connect from inside the corporate network
By default, for Relying Party Trusts created in ADFS 4.0 / Windows 2016 the Issuance Authorization Rule interface is not available in the GUI. Nevertheless, there is a way to switch over and we will explain that in post “Access Control Policies and Issuance Authorization Rules in ADFS 4.0 – Part 2”.