(2013-06-15) AD FS 2.0 Claims Rule Language Primer From The ASKDS Team (Part 2)

The guys from the ASKDS Team Blog have written a great follow-up article about the Claims Rule Language in ADFS v2.x. Kudos and credits of course go to the writer of the post on the AskDS Team Blog. The first part can be found through the following link: (2011-10-24) AD FS 2.0 Claims Rule Language Primer From The ASKDS Team

-

SOURCE: AD FS 2.0 Claims Rule Language Primer (Part 2)

-

<QUOTE SOURCE=”AD FS 2.0 Claims Rule Language Primer (Part 2)”>

Hello, Joji Oshima here to dive deeper into the Claims Rule Language for AD FS. A while back I wrote a getting started post on the claims rule language in AD FS 2.0. If you haven’t seen it, I would start with that article first as I’m going to build on the claims rule language syntax discussed in that earlier post. In this post, I’m going to cover more complex claim rules using Regular Expressions (RegEx) and how to use them to solve real world issues.

-

An Introduction to Regex

The use of RegEx allows us to search or manipulate data in many ways in order to get a desired result. Without RegEx, when we do comparisons or replacements we must look for an exact match. Most of the time this is sufficient but what if you need to search or replace based on a pattern? Say you want to search for strings that simply start with a particular word. RegEx uses pattern matching to look at a string with more precision. We can use this to control which claims are passed through, and even manipulate the data inside the claims.

-

Using RegEx in searches

Using RegEx to pattern match is accomplished by changing the standard double equals "==" to "=~" and by using special metacharacters in the condition statement. I’ll outline the more commonly used ones, but there are good resources available online that go into more detail. For those of you unfamiliar with RegEx, let’s first look at some common RegEx metacharacters used to build pattern templates and what the result would be when using them.

-

Symbol	Operation	Example Rule
^	Match the beginning of a string	c:[type == "http://contoso.com/role", Value =~ "^director"] => issue (claim = c); Pass through any role claims that start with "director"
$	Match the end of a string	c:[type == "http://contoso.com/email", Value =~ "contoso.com$"] => issue (claim = c); Pass through any email claims that end with "contoso.com"
|	OR	c:[type == "http://contoso.com/role", Value =~ "^director|^manager"] => issue (claim = c); Pass through any role claims that start with "director" or "manager"
(?i)	Not case sensitive	c:[type == "http://contoso.com/role", Value =~ "(?i)^director"] => issue (claim = c); Pass through any role claims that start with "director" regardless of case
x.*y	"x" followed by "y"	c:[type == "http://contoso.com/role", Value =~ "(?i)Seattle.*Manager"] => issue (claim = c); Pass through any role claims that contain "Seattle" followed by "Manager" regardless of case.
+	Match preceding character	c:[type == "http://contoso.com/employeeId", Value =~ "^0+"] => issue (claim = c); Pass through any employeeId claims that contain start with at least one "0"
*	Match preceding character zero or more times	Similar to above, more useful in RegExReplace() scenarios.

Table 1: RegEx Metacharacters

-

Using RegEx in string manipulation

RegEx pattern matching can also be used in replacement scenarios. It is similar to a "find and replace", but using pattern matching instead of exact values. To use this in a claim rule, we use the RegExReplace() function in the value section of the issuance statement.

The RegExReplace() function accepts three parameters:

1. The first is the string in which we are searching.
1. We will typically want to search the value of the incoming claim (c.Value), but this could be a combination of values (c1.Value + c2.Value).
2. The second is the RegEx pattern we are searching for in the first parameter
3. The third is the string value that will replace any matches found.

-

Example:

c:[type == "http://contoso.com/role"%5D => issue (Type = "http://contoso.com/role", Value = RegExReplace(c.Value, "(?i)director", "Manager"); Pass through any role claims. If any of the claims contain the word "Director", RegExReplace() will change it to "Manager". For example, "Director of Finance" would pass through as "Manager of Finance".

-

Real World Examples

Let’s look at some real world examples of regular expressions in claims rules.

-

# Problem 1:

We want to add claims for all group memberships, including distribution groups.

-

# Solution:

Typically, group membership is added using the wizard and selecting Token-Groups Unqualified Names and map it to the Group or Role claim. This will only pull security groups, not distribution groups, and will not contain Domain Local groups.

Figure 1: Retrieving Groups From AD And Sending Claims Out For Each

-

<COMMENT BY JORGE>

Using “memberOf”, you:

• Cannot get nested group memberships
• Can only get direct group memberships (security groups, distribution groups, universal groups, global groups, domain local groups)
• Get the groups in DN format

-

Using “Token-Groups – Unqualified Names” or “Token-Groups – Qualified By Domain Name” or “Token-Groups – Qualified By Long Domain Name”, you:

• Can get direct and nested group memberships
• Can get security groups
• Cannot get distribution groups
• Can get universal groups, global groups
• Cannot get domain local groups
• Get the groups in naming format, with or with the (long) domain name (depends on which token groups was used)

</COMMENT BY JORGE>

-

We can pull from memberOf, but that will give us the entire distinguished name, which is not what we want. One way to solve this problem is to use three separate claim rules and use RegExReplace() to remove unwanted data.

-

Phase 1: Pull memberOf, add to working set "phase 1"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://test.com/phase1"), query = ";memberOf;{0}", param = c.Value);

Example: "CN=Group1,OU=Users,DC=contoso,DC=com" is put into a phase 1 claim.

-

Phase 2: Drop everything after the first comma, add to working set "phase 2"

c:[Type == "http://test.com/phase1"%5D => add(Type = "http://test.com/phase2", Value = RegExReplace(c.Value, ",[^\n]*", ""));

Example: We process the value in the phase 1 claim and put "CN=Group1" into a phase 2 claim.

Digging Deeper: RegExReplace(c.Value, ",[^\n]*", "") c.Value is the value of the phase 1 claim. This is what we are searching in. ",[^\n]*" is the RegEx syntax used to find the first comma, plus everything after it "" is the replacement value. Since there is no string, it effectively removes any matches.

-

Phase 3: Drop CN= at the beginning, add to outgoing claim set as the standard role claim

c:[Type == "http://test.com/phase2"%5D => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = RegExReplace(c.Value, "^CN=", ""));

Example: We process the value in phase 2 claim and put "Group1" into the role claim

Digging Deeper: RegExReplace(c.Value, "^CN=", "") c.Value is the value of the phase 1 claim. This is what we are searching in. "^CN=" is the RegEx syntax used to find "CN=" at the beginning of the string. "" is the replacement value. Since there is no string, it effectively removes any matches.

-

# Problem 2:

We need to compare the values in two different claims and only allow access to the relying party if they match.

-

# Solution:

In this case we can use RegExReplace(). This is not the typical use of this function, but it works in this scenario. The function will attempt to match the pattern in the first data set with the second data set. If they match, it will issue a new claim with the value of "Yes". This new claim can then be used to grant access to the relying party. That way, if these values do not match, the user will not have this claim with the value of "Yes".

-

c1:[Type == "http://adatum.com/data1"%5D && c2:[Type == "http://adatum.com/data2"%5D => issue(Type = "http://adatum.com/UserAuthorized", Value = RegExReplace(c1.Value, c2.Value, "Yes"));

Example: If there is a data1 claim with the value of "contoso" and a data2 claim with a value of "contoso", it will issue a UserAuthorized claim with the value of "Yes". However, if data1 is "adatum" and data2 is "fabrikam", it will issue a UserAuthorized claim with the value of "adatum".

Digging Deeper: RegExReplace(c1.Value, c2.Value, "Yes") c1.Value is the value of the data1 claim. This is what we are searching in. c2.Value is the value of the data2 claim. This is what we are searching for. "Yes" is the replacement value. Only if c1.Value & c2.Value match will there be a pattern match and the string will be replaced with "Yes". Otherwise the claim will be issued with the value of the data1 claim.

-

# Problem 3:

Let’s take a second look at potential issue with our solution to problem 2. Since we are using the value of one of the claims as the RegEx syntax, we must be careful to check for certain RegEx metacharacters that would make the comparison mean something different. The backslash is used in some RegEx metacharacters so any backslashes in the values will throw off the comparison and it will always fail, even if the values match.

-

# Solution:

In order to ensure that our matching claim rule works, we must sanitize the input values by removing any backslashes before doing the comparison. We can do this by taking the data that would go into the initial claims, put it in a holding attribute, and then use RegEx to strip out the backslash. The example below only shows the sanitization of data1, but it would be similar for data2.

-

Phase 1: Pull attribute1, add to holding attribute "http://adatum.com/data1holder"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://adatum.com/data1holder"), query = ";attribute1;{0}", param = c.Value);

Example: The value in attribute 1 is "Contoso\John" which is placed in the data1holder claim.

-

Phase 2: Strip the backslash from the holding claim and issue the new data1 claim

c:[Type == "http://adatum.com/data1holder", Issuer == "AD AUTHORITY"] => issue(type = "http://adatum.com/data1", Value = RegExReplace(c.Value,"\\","");

Example: We process the value in the data1holder claim and put "ContosoJohn" in a data1 claim

Digging Deeper: RegExReplace(c.Value,"\\","") c.Value is the value of the data1 claim. This is what we are searching in. "\\" is considered a single backslash. In RegEx, using a backslash in front of a character makes it a literal backslash. "" is the replacement value. Since there is no string, it effectively removes any matches. An alternate solution would be to pad each backslash in the data2 value with a second backslash. That way each backslash would be represented as a literal backslash. We could accomplish this by using RegExReplace(c.Value,"\\","\\") against a data2 input value.

-

# Problem 4:

Employee numbers vary in length, but we need to have exactly 9 characters in the claim value. Employee numbers that are shorter than 9 characters should be padded in the front with leading zeros.

-

# Solution:

In this case we can create a buffer claim, join that with the employee number claim, and then use RegEx to use the right most 9 characters of the combined string.

-

Phase 1: Create a buffer claim to create the zero-padding

=> add(Type = "Buffer", Value = "000000000");

-

Phase 2: Pull the employeeNumber attribute from Active Directory, place it in a holding claim

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("ENHolder"), query = ";employeeNumber;{0}", param = c.Value);

-

Phase 3: Combine the two values, then use RegEx to remove all but the 9 right most characters.

c1:[Type == "Buffer"] && c2:[Type == "ENHolder"] => issue(Type = "http://adatum.com/employeeNumber", Value = RegExReplace(c1.Value + c2.Value, ".*(?=.{9}$)", ""));

Digging Deeper: RegExReplace(c1.Value + c2.Value, ".*(?=.{9}$)", "") c1.Value + c2.Value is the employee number padded with nine zeros. This is what we are searching in. ".*(?=.{9}$)" represents the last nine characters of a string. This is what we are searching for. We could replace the 9 with any number and have it represent the last "X" number of characters. "" is the replacement value. Since there is no string, it effectively removes any matches.

-

# Problem 5:

Employee numbers contain leading zeros but we need to remove those before sending them to the relying party.

-

# Solution:

In this case we can pull employee number from Active Directory and place it in a holding claim, then use RegEx to use the strip out any leading zeros.

-

Phase 1: Pull the employeeNumber attribute from Active Directory, place it in a holding claim

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("ENHolder"), query = ";employeeNumber;{0}", param = c.Value);

-

Phase 2: Take the value in ENHolder and remove any leading zeros.

c:[Type == "ENHolder"] => issue(Type = "http://adatum.com/employeeNumber", Value = RegExReplace(c.Value, "^0*", ""));

Digging Deeper: RegExReplace(c.Value, "^0*", "") c1.Value is the employee number. This is what we are searching in. "^0*" finds any leading zeros. This is what we are searching for. If we only had ^0 it would only match a single leading zero. If we had 0* it would find any zeros in the string. "" is the replacement value. Since there is no string, it effectively removes any matches.

-

Conclusion

As you can see, RegEx adds powerful functionality to the claims rule language. It has a high initial learning curve, but once you master it you will find that there are few scenarios that RegEx can’t solve. I would highly recommend searching for an online RegEx syntax tester as it will make learning and testing much easier. I’ll continue to expand the TechNet wiki article so I would check there for more details on the claims rule language.

-

Understanding Claim Rule Language in AD FS 2.0

AD FS 2.0: Using RegEx in the Claims Rule Language

Regular Expression Syntax

AD FS 2.0 Claims Rule Language Primer

Until next time,

Joji "Claim Jumper" Oshima

</QUOTE SOURCE=”AD FS 2.0 Claims Rule Language Primer (Part 2)”>

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2013-05-15) Replacing ADFS Certificates

You have an ADFS infrastructure up-and-running smoothly, but your certificates are about to expire. It is very important you start renewing your current certificates as needed and in time way before your current certificates expire. In addition, you may need to notify upstream application owners, upstream federation services and downstream federation services.

As mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x, in ADFS v2.x the following certificates can be used:

1. For Security Token Service (STS) servers only:
   1. Service Communications certificate (CA issued certificate)
   2. Token Signing Certificate (CA issued certificate or ADFS managed self-signed)
   3. Token Decryption Certificate (CA issued certificate or ADFS managed self-signed)
2. Proxy Service (PRX) servers
   1. Service Communications certificate (CA issued certificate)

-

[AD.1.1 – Service Communications Certificate For ADFS STS servers]

Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x and then:

• Import CA issued certificate into the personal store of each ADFS STS server;
• On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
• On each ADFS STS server, bind the CA issued certificate to the default website in IIS
• Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the “Service Communications” certificate

-

[AD.1.2 – Token Signing Certificate For ADFS STS servers]

First you need to determine and understand if you are using a CA issued certificate or an ADFS managed self-signed certificate.

If you are using an ADFS managed self-signed certificate, then ADFS will perform the rollover (add, promote and remove) automatically.

If you are using CA issued certificate you must replace (add, publish, remove)  the certificate manually by performing the following actions:

• Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x
• Import CA issued certificate into the personal store of each ADFS STS server;
• On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
• Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the secondary “Token Signing” certificate

After that publish/communicate [*] the new ADFS Token Signing Certificate to every upstream application and/or upstream federation service that is represented as an Relying Party Trust in your ADFS based federation service and every downstream federation service that is represented as an Relying Party Trust in your ADFS based federation service [**] . The owner of the upstream application and/or upstream federation service must add the new ADFS Token Signing Certificate of your federation service to the Claims Provider Trust or Identity Provider Trust (whatever it is called) that represents your federation service. The owner of the downstream federation service must add the new ADFS Token Signing Certificate of your federation service to the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service [**].

After publishing/communicating [*] the new ADFS Token Signing Certificate to every upstream application and/or upstream federation service that is represented as an Relying Party Trust in your ADFS based federation service and every downstream federation service that is represented as a Claims Provider Trust in your ADFS based federation service, promote the secondary “Token Signing” certificate to become the primary “Token Signing” certificate.

-

[*] Publishing/Communicating New Token Signing Certificates To Upstream Applications And/Or Upstream Federation Services

If the federation metadata is published through an URL AND it is also consumed automatically by those upstream applications and/or upstream federation services, then instruct the owners of those upstream upstream applications and/or upstream federation services to import/read the updated federation metadata through the URL, if not already done automatically. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

If the federation metadata is NOT published through an URL OR it is NOT consumed automatically by those upstream applications and/or upstream federation services, then export the Token Signing Certificate from ADFS and send that certificate with the public key to the owners of those upstream upstream applications and/or upstream federation services and instruct them to import the new Token Signing Certificate into the Claims Provider Trust or Identity Provider Trust (whatever it is called) that represents your federation service. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

-

[**] Token Signing Certificates Also Used By Downstream Federation Services

Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification.

-

TIP: Know which entity consumes your federation metadata automatically and also know which ones do not! You can for example use the NOTES property of each trust to specify if your metadata URL is being used by the entity and if you are using the entity’s metadata URL! That way you would be able to easily query through PowerShell who you would need to contact!

-

[AD.1.3 – Token Decryption Certificate For ADFS STS servers]

First you need to determine and understand if you are using a CA issued certificate or an ADFS managed self-signed certificate.

If you are using an ADFS managed self-signed certificate, then ADFS will perform the rollover (add, promote and remove) automatically.

If you are using CA issued certificate you must replace (add, publish, remove)  the certificate manually by performing the following actions:

• Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x
• Import CA issued certificate into the personal store of each ADFS STS server;
• On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
• Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the secondary “Token Decrypting” certificate

After that publish/communicate [***] the new ADFS Token Decrypting Certificate to every downstream federation service that is represented as an Claims Provider Trust in your ADFS based federation service. The owner of the downstream federation service must add the new ADFS Token Decryption Certificate of your federation service to the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service.

After publishing/communicating [***] the new ADFS Token Decrypting Certificate to every downstream federation service that is represented as an Claims Provider Trust in your ADFS based federation service, promote the secondary “Token Decrypting” certificate to become the primary “Token Decrypting” certificate.

-

[**] Publishing/Communicating New Token Decrypting Certificates To Downstream Federation Services

If the federation metadata is published through an URL AND it is also consumed automatically by those downstream federation services, then instruct the owners of those downstream federation services to import/read the updated federation metadata through the URL, if not already done automatically. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

If the federation metadata is NOT published through an URL OR it is NOT consumed automatically by those downstream federation services, then export the Token Decrypting Certificate from ADFS and send that certificate with the public key to the owners of those downstream federation services and instruct them to import the new Token Decrypting Certificate into the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

-

TIP: Know which entity consumes your federation metadata automatically and also know which ones do not! You can for example use the NOTES property of each trust to specify if your metadata URL is being used by the entity and if you are using the entity’s metadata URL! That way you would be able to easily query through PowerShell who you would need to contact!

-

[AD.2.1 – SSL Communications Certificate For ADFS PRX servers]

Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x and then:

• Import CA issued certificate into the personal store of each ADFS PRX server;
• On each ADFS PRX server, bind the CA issued certificate to the default website in IIS

-

For additional details also see:

• AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover

In the following blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x I wrote about the certificates used by ADFS v2.x. In summary, you can use CA issued certificates for all certificates required by ADFS or you can use ADFS managed self-signed certificates for both the Token Signing Certificate and the Token Decryption Certificate. When automated certificate rollover has been enabled, ADFS managed self-signed certificates for both the Token Signing Certificate and the Token Decryption Certificate will be used!

-

Let’s first have a look at the characteristics self-signed certificates in general. It is considered a bad practice to use self-signed certificates because by default those certificates are not trusted by any entity. Self-signed certificates do not leverage CRLs and cannot be revoked, only replaced. And to my knowledge you cannot store its private key in an HSM. However, in the case of ADFS, the valid usage of a self-signed certificate, and also CA Issued Certificates, (for both the Token Signing Certificate at the IdP STS and the Token Decryption Certificate at the SP STS/App) is determined by the existence of the certificate, its configuration as the certificate for a specific purpose and the publication of such in the federation metadata. Something to be aware of is that other parties, such as both STS’es and applications, still must become aware of the information available in the federation metadata, either manually or automatically.

-

The usage of ADFS managed self-signed certificates lowers the management overhead that comes with the usage of certificates in common. ADFS managed self-signed certificates, and their corresponding private keys are not stored on individual servers, but rather in the ADFS configuration database. In the context of security, all ADFS STS servers and all servers hosting the ADFS configuration database should be secured, physically and logically, in at least the same way as securing RWDCs. Access to these servers should ONLY be allowed to highly skilled knowledgeable and authorized people that understand the working of ADFS. Why? Let’s do a comparison!

In a Windows world, resources are secured through Windows Security Groups. To gain access to those resources you must be a member of the corresponding Windows Security Groups and the DC must hand out an Access Token that contains those Windows Security Groups. If the RWDC has been compromised, the person that compromised the RWDC will also have access to any resource secured by Windows Security Groups because it will be able to generate Access Tokens with any required Windows Security Groups.

In a Claims Based Authorization world, resources are secured through specific Claims. To gain access to those resources you must be able to provide the corresponding Claims and the ADFS STS must hand out a Security Token that contains those Claims. If the ADFS STS has been compromised, the person that compromised the ADFS STS will also have access to any resource secured by Claims because it will be able to generate Security Tokens with any required Claims.

To be able to test this all, I have changed the default values to lower values as shown below. Later on I will explain each and every property.

Figure 1: Automated Certificate Rollover Related Properties

-

AutoCertificateRollover

When set to True, Automated Certificate Rollover is enabled for both the Token Signing Certificate and Token Decryption Certificate. CA issued certificates cannot be used for both.

When set to False, Automated Certificate Rollover is disabled for both the Token Signing Certificate and Token Decryption Certificate. CA issued certificates must be used for both.

-

CertificateThresholdMultiplier

The default value is 1440 minutes (24 hours/1 day).

This is a multiplier unit used by the other parameters and it is measured in the number of minutes.

-

CertificateRolloverInterval

The default value is 720 minutes (12 hours).

This is the frequency in minutes in which the federation service checks the current ADFS managed self-signed certificates.

-

CertificateDuration

The default value is 365 units.

This is the validity period of ADFS managed self-signed certificate. Defined by the number of multiplier units. In this custom scenario, the validity of the ADFS managed self-signed certificate is 10 units of 30 minutes, or 300 minutes (5 hours).

-

CertificateGenerationThreshold

The default value is 20 units.

This is the period of time before expiration of the current primary certificate, a new ADFS managed self-signed certificate is generated and marked as secondary. Defined by the number of multiplier units. In this custom scenario, a new ADFS managed self-signed will be generated and marked as secondary 2 hours (4 units of 30 minutes, 120 minutes) before the expiration of the current primary ADFS managed self-signed certificate.

-

CertificatePromotionThreshold

The default value is 5 units.

This is the period of time before expiration of the current primary certificate, a previously generated ADFS managed self-signed certificate marked as secondary is promoted to become the primary ADFS Managed self-signed certificate. Defined by the number of multiplier units. In this custom scenario, a new ADFS managed self-signed will be promoted to primary 1 hour (2 units of 30 minutes, 60 minutes) before the expiration of the current primary ADFS managed self-signed certificate.

-

CertificateCriticalThreshold

The default value is 2 units.

This is the period of time before expiration of the current primary certificate, a new ADFS managed self-signed certificate is generated and marked as primary immediately. This only occurs is everything else before failed and went down the drain. Defined by the number of multiplier units. In this custom scenario, a new ADFS managed self-signed will be generated and promoted to primary immediately half an hour (1 units of 30 minutes, 30 minutes) before the expiration of the current primary ADFS managed self-signed certificate.

-

When you put everything in a diagram, it looks like as shown below.

Figure 2: Automated Certificate Rollover Related Properties In A Diagram

-

As an example I will show the corresponding event IDs, for every moment, except the one for “CertificateCriticalThreshold”

Figure 3: The Generation Of The Very First ADFS Managed Self-Signed Token Decryption Certificate (“Valid From”)

-

Figure 4: The Generation Of The Very First ADFS Managed Self-Signed Token Signing Certificate (“Valid From”)

-

Figure 5: The Federation Service Checking The Current Certificates (CertificateRollOverInterval)

-

Figure 6: The Generation Of The (New) Next ADFS Managed Self-Signed Token Decryption Certificate And Configured As Secondary (CertificateGenerationThreshold)

-

Figure 7: The Generation Of The (New) Next ADFS Managed Self-Signed Token Signing Certificate And Configured As Secondary (CertificateGenerationThreshold)

-

Figure 8: The Promotion Of The Secondary ADFS Managed Self-Signed Token Decryption Certificate To Primary

-

Figure 9: The Promotion Of The Secondary ADFS Managed Self-Signed Token Signing Certificate To Primary

-

Figure 10: The Removal Of The (Old/Expired) Secondary ADFS Managed Self-Signed Token Signing Certificate (“Valid To”)

-

Figure 11: The Removal Of The (Old/Expired) Secondary ADFS Managed Self-Signed Token Decryption Certificate (“Valid To”)

-

For additional details also see:

• AD FS 2.0: Understanding AutoCertificateRollover Threshold Properties

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2013-05-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x

In ADFS v2.x the following certificates can be used:

1. For Security Token Service (STS) servers only:
1. Service Communications certificate
2. Token Signing Certificate
3. Token Decryption Certificate
2. Proxy Service (PRX) servers
1. Service Communications certificate

-

[AD.1.1 – Service Communications Certificate For ADFS STS servers]

This certificate secures all the HTTP communications with the ADFS STS servers. You should use a CA issued certificate (internal or external) for production and test systems or use a non-ADFS managed self-signed certificate if your test environment does not have a PKI infrastructure. Assuming you are not connecting the ADFS STS servers (the farm) directly to the internet, you could use a CA issued certificate from your internal PKI infrastructure instead of CA issued certificate from a public PKI infrastructure. If you are connecting your ADFS STS servers (the farm) directly to the internet (you nutball you!), you must use CA issued certificate from a public PKI infrastructure.

-

For this certificate you can use any certificate template as long as that certificate template has the “Enhanced Key Usage (EKU)” for “Server Authentication”. In addition, the subject or the SAN should specify the FQDN of the federation service. However, if you want the use a wildcard certificate, then that’s also possible.

The FQDN of the federation service can be found through the GUI by either selecting and right-clicking the “AD FS 2.0” node or the “Service” node and selecting the option “Edit Federation Service Properties”. The TAB “General” will show the FQDN of the federation service.

Figure 1: Federation Service Properties Through The ADFS MMC

-

The FQDN of the federation service can also be found through PowerShell by adding/loading the PowerShell snap-in (for ADFS v2.0) through “Add-PSSnapin Microsoft.ADFS.PowerShell” or the PowerShell module (for ADFS v2.1) through “Import-Module ADFS” followed by the command “Get-ADFSProperties”. The property “HostName” will show the FQDN of the federation service.

Figure 2: Federation Service Properties Through The ADFS PowerShell Snap-In/Module

-

This certificate and private key should be distributed amongst all ADFS STS servers and installed/imported into the personal store of the computers. After that, on each ADFS STS, the ADFS Service account must have at least (and that’s enough!) READ permissions on the private key. Start an MMC console, add a snap-in called “Certificates” for the computer account of the local computer. Right-click the imported certificate and select the options “All Tasks –> Manage Private Keys”, add the ADFS service account and assign it Allow:Read permissions.

Figure 3: Assigning The ADFS Service Account Allow:Read Permissions To The Private Key Of The Service Communications Certificate

-

Again, on each ADFS STS server you need to bind the (new) certificate to the default website in IIS. Open the IIS MMC, navigate to the Default Web Site, right-click it and select the option “Edit Bindings”. Select the binding “https – 443 – *”, click EDIT and select the correct certificate

Figure 4: Binding The Service Communications Certificate To The Default Web Site In IIS

-

And last but not least, you need to configure the (new) Service Communications Certificate as the ADFS Service Communications Certificate through the ADFS MMC. Open the ADFS MMC, navigate to the Certificates node, in the Actions pane click the “Set Service Communications Certificate” option and select the correct Service Communications Certificate for ADFS. This only needs to be done on one ADFS STS as this applies to the ADFS Farm. If you are using SQL you can choose any ADFS STS server and if you are using WID, you need to choose the primary ADFS STS server.

-

[AD.1.2 – Token Signing Certificate For ADFS STS servers]

This certificate signs every issued security token by this ADFS STS server/farm. This is also THE certificate on which the federation trust is based! For this you can use a CA issued certificate (internal or external) or you can use an ADFS managed self-signed certificate. For the first automatic certificate rollover must be disabled and for the latter it must be enabled!

When a federation trust (Relying Party Trust) with an upstream application exists, that application may need to trust the parent issuing/root CAs that issued the certificate. When using a CA issued certificate from your internal PKI infrastructure or a public PKI infrastructure, that most likely is not a problem as the issuing/root CAs are specified in the correct certificate stores. However, if you are using an ADFS managed self-signed certificate you may also need to add that ADFS managed self-signed certificate to the Trust Root Certificate Store. Whether or not that is needed depends on how the upstream application works. Is it enough for the Token Signing Certificate of the issuing ADFS STS to be listed in the federation trust OR must it in addition to that also be listed in the Trusted Root Certificate store of the computer hosting the application! For example, Sharepoint 2010 would need both!

When a federation trust (Relying Party Trust) with an upstream federation service exists, that federation service may need to trust the parent issuing/root CAs that issued the certificate. When using a CA issued certificate from a public PKI infrastructure, that most likely is not a problem as the issuing/root CAs are specified in the correct certificate stores. However, if you are using a CA issued certificate from your internal PKI infrastructure or an ADFS managed self-signed certificate you may also need to respectively add the issuing/root CAs of your internal PKI infrastructure or the ADFS managed self-signed certificate to the Trust Root Certificate Store. Whether or not that is needed depends on how the upstream federation service works. Is it enough for the Token Signing Certificate of the issuing ADFS STS to be listed in the federation trust OR must it in addition to that also be listed in the Trusted Root Certificate store of the computer(s) hosting the upstream federation service! If two ADFS based federation services have a trust between each other you can use an ADFS managed self-signed certificate for the Token Signing Certificate without adding it to the Trust Root Certificate Store.

-

For this certificate you can use any certificate template, when CA issued, as long as that certificate template has the “Key Usage (KU)” for “Digital Signature”. In addition, the subject or the SAN should specify something that makes sense. No known or used FQDN must be explicitly used, you can basically use anything. Preferably you specify something like “ADFS.Token.Signing” or “<FQDN Federation Service>.Token.Signing” (e.g. FS.ADCORP.LAB.TOKEN.SIGNING).

-

If you are using an ADFS managed self-signed certificate the next steps are not needed. However, if you are using a CA issued certificate, from either your internal PKI infrastructure or a public PKI infrastructure, you must perform the next steps.

This certificate and private key should be distributed amongst all ADFS STS servers and installed/imported into the personal store of the computers. After that, on each ADFS STS, the ADFS Service account must have at least (and that’s enough!) READ permissions on the private key. Start an MMC console, add a snap-in called “Certificates” for the computer account of the local computer. Right-click the imported certificate and select the options “All Tasks –> Manage Private Keys”, add the ADFS service account and assign it Allow:Read permissions.

Figure 5: Assigning The ADFS Service Account Allow:Read Permissions To The Private Key Of The Token Signing Certificate

-

And last but not least, you need to configure the (new) Token Signing Certificate as the (secondary) ADFS Token Signing Certificate through the ADFS MMC. Open the ADFS MMC, navigate to the Certificates node, in the Actions pane click the “Add Token Signing Certificate” option and select the correct Token Signing Certificate for ADFS. The new certificate will be listed as the secondary ADFS Token Signing Certificate. In time you need to promote the new certificate to become the primary ADFS Token Signing Certificate. This only needs to be done on one ADFS STS as this applies to the ADFS Farm. If you are using SQL you can choose any ADFS STS server and if you are using WID, you need to choose the primary ADFS STS server.

-

The (new) Token Signing Certificate is published automatically in the federation metadata.

-

[AD.1.3 – Token Decryption Certificate For ADFS STS servers]

This certificate encrypts every issued security token by this ADFS STS server/farm using the certificate of the receiving ADFS STS server/farm. For this you can use a CA issued certificate (internal or external) or you can use an ADFS managed self-signed certificate. For the first automatic certificate rollover must be disabled and for the latter it must be enabled!

When a federation trust (Claims Provider Trust) with an downstream federation service exists, that downstream federation service may need to trust the parent issuing/root CAs that issued the certificate. When using a CA issued certificate from a public PKI infrastructure, that most likely is not a problem as the issuing/root CAs are specified in the correct certificate stores. However, if you are using a CA issued certificate from your internal PKI infrastructure or an ADFS managed self-signed certificate you may also need to respectively add the issuing/root CAs of your internal PKI infrastructure or the ADFS managed self-signed certificate to the Trust Root Certificate Store. Whether or not that is needed depends on how the downstream federation service works. Is it enough for the Token Decryption Certificate of the receiving ADFS STS to be listed in the federation trust OR must it in addition to that also be listed in the Trusted Root Certificate store of the computer(s) hosting the downstream federation service! If two ADFS based federation services have a trust between each other you can use an ADFS managed self-signed certificate for the Token Decryption Certificate without adding it to the Trust Root Certificate Store.

-

For this certificate you can use any certificate template, when CA issued, as long as that certificate template has the “Key Usage (KU)” for “Key Encipherment”. In addition, the subject or the SAN should specify something that makes sense. No known or used FQDN must be explicitly used, you can basically use anything. Preferably you specify something like “ADFS.Token.Decryption” or “<FQDN Federation Service>.Token.Decryption” (e.g. FS.ADCORP.LAB.TOKEN.DECRYPTION).

-

If you are using an ADFS managed self-signed certificate the next steps are not needed. However, if you are using a CA issued certificate, from either your internal PKI infrastructure or a public PKI infrastructure, you must perform the next steps.

This certificate and private key should be distributed amongst all ADFS STS servers and installed/imported into the personal store of the computers. After that, on each ADFS STS, the ADFS Service account must have at least (and that’s enough!) READ permissions on the private key. Start an MMC console, add a snap-in called “Certificates” for the computer account of the local computer. Right-click the imported certificate and select the options “All Tasks –> Manage Private Keys”, add the ADFS service account and assign it Allow:Read permissions.

 

Figure 6: Assigning The ADFS Service Account Allow:Read Permissions To The Private Key Of The Token Decryption Certificate

-

And last but not least, you need to configure the (new) Token Decryption Certificate as the (secondary) ADFS Token Decryption Certificate through the ADFS MMC. Open the ADFS MMC, navigate to the Certificates node, in the Actions pane click the “Add Token Decryption Certificate” option and select the correct Token Decryption Certificate for ADFS. The new certificate will be listed as the secondary ADFS Token Decryption Certificate. In time you need to promote the new certificate to become the primary ADFS Token Decryption Certificate. This only needs to be done on one ADFS STS as this applies to the ADFS Farm. If you are using SQL you can choose any ADFS STS server and if you are using WID, you need to choose the primary ADFS STS server.

-

The (new) Token Decryption Certificate is published automatically in the federation metadata.

-

[AD.2.1 – SSL Communications Certificate For ADFS PRX servers]

This certificate secures all the HTTP communications with the ADFS PRX servers. You should use a CA issued certificate (external only!) for production and test systems or use a non-ADFS managed self-signed certificate if your test environment does not have a PKI infrastructure. You should use a CA issued certificate from a public PKI infrastructure because you are connecting/exposing your ADFS PRX servers directly to the internet. So, if you are receiving traffic from the internet that is related to the federation service (e.g. metadata exchange, authentication, home realm discovery, etc.) you should use some kind of reverse proxy such as for example the ADFS Proxy Server!

-

For this certificate you can use any certificate template as long as that certificate template has the “Enhanced Key Usage (EKU)” for “Server Authentication”. In addition, the subject or the SAN should specify the FQDN of the federation service. However, if you want the use a wildcard certificate, then that’s also possible. To determine the FQDN of the federation service see above!

-

This certificate and private key should be distributed amongst all ADFS PRX servers and installed/imported into the personal store of the computers.

Last but not least, and again on each ADFS PRX server you need to bind the (new) certificate to the default website in IIS. Open the IIS MMC, navigate to the Default Web Site, right-click it and select the option “Edit Bindings”. Select the binding “https – 443 – *”, click EDIT and select the correct certificate

Figure 7: Binding The Service Communications Certificate To The Default Web Site In IIS

-

For additional details also see:

• AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2013-02-15) Update Rollup 3 For ADFS v2.0 Has Been Released

Microsoft has released update rollup 3 for ADFS v2.0. This rollup contains both bug fixes and additional capabilities. Read all the details by clicking on the following link Description of Update Rollup 3 for Active Directory Federation Services (AD FS) 2.0.

The Update Rollup 3 update is a cumulative update package that contains all the fixes and new features that were contained in Update Rollup 1 and 2.

-

Issue 1

AD FS 2.0 does not issue an ActAs token for a relying party who is using a Security Assertion Markup Language (SAML) 2.0 bootstrap token. When this issue occurs, the following error is generated:

System.IdentityModel.Tokens.SecurityTokenException: ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.

After you apply AD FS 2.0 update rollup 3, AD FS 2.0 successfully issues the token in this situation.

-

Issue 2

AD FS 2.0 update rollup 2 introduced strict Uniform Resource Identifier (URI) checking. When AD FS 2.0 acts as a federation provider and trusts an identity provider whose identifier is not an URI, the response that is returned from the identity provider is rejected by AD FS 2.0. The validation fails because AD FS 2.0 tries to validate the value of the identity provider’s identifier. This behavior breaks previously functioning AD FS 2.0 deployments in which identity providers use non-URI identifiers. AD FS 2.0 update rollup 3 removes this URI checking.

-

Issue 3

AD FS 2.0 acts as a federation provider and receives an invalid SAML 2.0 signed request (for example, the signature is not valid or the requestor is unknown). In this situation, AD FS 2.0 rejects the request only after it forwards the request to the downstream identity provider and receives a valid SAML response.
In order to make sure the validity of the requests that are sent to the downstream identity provider, the expected behavior is that AD FS 2.0 validates SAML requests and rejects any requests that have invalid signatures.

-

Issue 4

Relying parties require that signature certificates are applied to the relying party for SAML request. This is because signature certificates provide an important security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 allows unique signature certificates to be applied to a relying party trust. However, it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction.

UPDATE 2013-05-17: Post-update configuration for issue 4

Note however that simply applying the update rollup doesn’t allow you to implement multiple relying party trusts with the same certificate.  After applying the update you have to update the configuration database. The steps differ from when using WID or SQL server.

-

+++ Are you using WID? Then use the following steps! +++

The script “PostReleaseSchemaChanges.ps1” is located under the AD FS binaries directory “C:\Program Files\Active Directory Federation Services 2.0\SQL”.

Manually execute the script first on the secondary federation servers in the farm, and then on the primary federation server!

-

+++ Are you using SQL? Then use the following steps! +++

Download the SQL script “RelaxedRequestSigningCertsv2.sql” and execute it against the configuration database.

To execute this script, run the following command by using the Sqlcmd utility: Sqlcmd -S <ConnectionString for SQL> -i RelaxedRequestSigningCertsv2.sql

OR,

Use SQL Server Management Studio to execute the SQL Query. Connect to the SQL Server database that has the AD FS 2.0 configuration database. Create a new SQL query. Paste the contents of the RelaxedRequestSigningCertsv2.sql file into the query, and then execute the query.

After running the script, you can create RP trusts with the same signing certificate.

-

Issue 5

Consider the following scenario:

• You use a third-party hardware security module (HSM) to speed up the signing processes.
• You use the third-party HSM and to generate and store the private keys.
• The private keys are for AD FS 2.0 signing and for AD FS 2.0 encryption certificates.

In this situation, the performance of AD FS 2.0 is not as good as when you use Microsoft CSP. AD FS 2.0 update rollup 3 significantly improves the performance of AD FS 2.0 when HSM is used.

-

Issue 6

AD FS 2.0 update rollup 1 introduces the Congestion Avoidance Algorithm. If you accidentally disable the Congestion Avoidance Algorithm by changing the configuration, a handle leak occurs on an AD FS 2.0 federation server proxy every time that the federation server proxy processes a request. AD FS 2.0 update rollup 3 removes the setting that enables you to disable Congestion Avoidance Algorithm by changing the configuration. You can fine tune the Congestion Avoidance Algorithm by adjusting the latencyThresholdInMsec and minCongestionWindowSize settings.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2012-09-23) Claims Based Authorizations For Sharepoint Through ADFS (Part 10)

-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 9)

-

Now I’m going to log on with the user “ADCORP\Claims.UserR1.C” which has been configured with the role “ROLE_adcorp.app.ADFSAppClaimsContributor” through the group membership of a group called “GRP_R1_ADCORP-ADFS-Claims-App-Contributors”. So ADFS extracts, the user’s group memberships and tranforms the group “GRP_R1_ADCORP-ADFS-Claims-App-Contributors” into a role “ROLE_adcorp.app.ADFSAppClaimsContributor” along the way. So, let’s have a look at this!

Figure 1: The User Leveraging Forms Based Authentication

-

Figure 2: The Claims Issued To The User And Processed By Sharepoint

-

With regards to sign-out from both Sharepoint and ADFS, you might want to have a look at the following

• ADFS 2 Sharepoint 2010 Signout
• ADFS 2 SharePoint 2010 Signout
• Signout issue from Claim enabled Site in SharePoint 2010 with adfs 2.0
• Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users

-

With regards to Claims Based Authorization you might also have a look at the following:

• Make Sure You Know This About SharePoint 2010 Claims Authentication – Sticky Sessions Are REQUIRED

-

Other explanation of configuring Sharepoint 2010 to leverage claims from ADFS v20:

• Configuring SharePoint 2010 and ADFS v2 End to End
• Configuring Claims Based Authentication for SharePoint with AD FS 2.0
• UPDATED: How To Add ADFS 2.0 as a Federated Identity Provider in SharePoint 2010
• Real World Claims Part 1: Prelude to a SharePoint Presentation
• Real World Claims Part 2: Begin at the Beginning – Provision the ADFS and SharePoint Demo Environment
• Real World Claims Part 3: Setting Up the Demo Web Sites
• Real World Claims Part 4: Configuring ADFS and SharePoint STS
• SharePoint 2010 and ADFS 2.0 the complete Step-by-Step guide
• SharePoint 2010 and ADFS 2.0 Setup
• Claims Based Authentication using ADFS 2.0
• Implementing Claims-Based Authentication with SharePoint Server 2010 

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2012-09-22) Claims Based Authorizations For Sharepoint Through ADFS (Part 9)

-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 8)

-

At this point everything is in place for at least the primary site collection administrator to be able to logon against the SP2010 claims based web application. This way I’m able to configure roles within the SP2010 claims based web application to use roles to assign permissions. This allows other (federated) users to access the SP2010 web application based upon their assigned role.

SP2010 knows of three permissions and for each permission I have configured a role. If you have the role, you also get the corresponding permission.

ROLE: ”ROLE_adcorp.app.ADFSAppClaimsOwner” –> PERM: ”Full Control”

ROLE: ”ROLE_adcorp.app.ADFSAppClaimsContributor” –> PERM: ”Contribute”

ROLE: ”ROLE_adcorp.app.ADFSAppClaimsViewer” –> PERM: ”Read”

So, now lets configure these roles and corresponding permissions within the SP2010 web application.

So, open up internet explorer and navigate to “https://app-claims.adcorp.lab:446/” and:

• Click on “Site Actions” –> “Site Permissions”
• Click on “Grant Permissions”
• In the lower right corner of the users/groups field click on the address book icon
• Enter ONE OF THE ABOVE ROLES in the FIND field and click on the search button
• Make sure to select the Role node and the click on the role that was found and then click OK
• Click OK

Repeat these steps for every role that needs to be configured and assign the correct permissions as also stated above.

Figure 1: Configuration Of The “ROLE_adcorp.app.ADFSAppClaimsOwner” Role With The SP2010 Web Application And Assigning The “Full Control” Permission To It

-

Figure 2: Configuration Of The “ROLE_adcorp.app.ADFSAppClaimsContributor” Role With The SP2010 Web Application And Assigning The “Contribute” Permission To It

-

Figure 3: Configuration Of The “ROLE_adcorp.app.ADFSAppClaimsViewer” Role With The SP2010 Web Application And Assigning The “Read” Permission To It

-

After this the roles and permissions look like:

Figure 4: The Configured Roles/Accounts And Corresponding Permissions For The SP2010 Web Application

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 10)

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2012-09-21) Claims Based Authorizations For Sharepoint Through ADFS (Part 8)

-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 7)

-

At this point, right after the creation of the RP trust, no issuance transform rules exist and also no delegation authorization rules exist. However, one claim rule exists in the issuance authorization rules and that is whatever you selected (“Permit All” or “Deny All”) previously during the creation of the RP trust.

Figure 1: Default List Of Issuance Authorization Rules For The “Claims Based Sharepoint App” Relying Party Trust

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App").IssuanceAuthorizationRules

Figure 2: Default Configuration Of Each Issuance Authorization Rule For The “Claims Based Sharepoint App” Relying Party Trust

-

Using a PowerShell script I imported my own defined list of issuance transform rules for the “Claims Based Sharepoint App” Relying Party Trust. The total list now looks like is shown below.

 

Figure 3: Total List Of Issuance Transform Rules For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App").IssuanceTransformRules

Figure 4: Configuration Of Each Issuance Transform Rule For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

Using a PowerShell script I imported my own defined list of issuance authorization rules for the “Claims Based Sharepoint App” Relying Party Trust. The total list now looks like is shown below.

Figure 5: Total List Of Issuance Authorization Rules For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App").IssuanceAuthorizationRules

Figure 6: Configuration Of Each Issuance Authorization Rule For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 9)

-

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

(2012-09-20) Claims Based Authorizations For Sharepoint Through ADFS (Part 7)

-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 6)

-

Now we need to create a relying party trust for the SP2010 web application and configure that accordingly! You can do that through the GUI or through PowerShell. I’m going to create the RP trust through the GUI and the configure it (issuing transform rules and authorization transform rules) through PowerShell.

Start the ADFS v2.0 MMC and navigate to the “AD FS 2.0\Trust Relationships\Relying Party Trusts” node. Right-click it and select the “Add Relying Party Trust…” option.

Click on “Start”.

Figure 1: The Add Relying Party Trust Wizard – Welcome Screen

-

Select the option “Enter data about the relying party manually” and click on “Next >”. By the way, for more information about all the three options about creating a federation trust, see: (2012-08-31) Leveraging Federation Metadata To Setup A Federation Trust (Claims Provider Or Relying Party)

Figure 2: The Add Relying Party Trust Wizard – Select Data Source

-

Specify a display name (e.g. Claims Based Sharepoint App) and click on “Next >”

Figure 3: The Add Relying Party Trust Wizard – Specify A Display Name

-

For the SP2010 web application select the “AD FS 2.0 profile” and click on “Next >”

Figure 4: The Add Relying Party Trust Wizard – Choose Profile

-

The connection to the SP2010 is already secured by SSL and therefore the security token, which is transmitted over the same connection, will also be secured by that! So, it is not needed to additionally encryption the security token itself. I honestly do not know if SP2010 supports this or not. If SP2010 would support this and you would want to enable it, you would need to provide the public part of the token decryption from SP2010. When encrypted, SP2010 would use its private key to decrypt the encrypted security token. In addition, after creating this RP trust, we also need to force ADFS not to encrypt the security token when using this RP trust.

So in this case, just click on “Next >”.

Figure 5: The Add Relying Party Trust Wizard – Token Decryption Certificate From Web App (RP)

-

Select the option “Enable support for the WS-Federation Passive Protocol” and specify the exact same URL as when the web application was created in SP2010 and add the _trust part to it. So, in total the URL should something like “https://app-claims.adcorp.lab:446/_trust/” (without the quotes).

Figure 6: The Add Relying Party Trust Wizard – URL

-

By default ADFS uses the URL as the identifier. Whatever identifier is used is not important. The only important things to remember are that it must be unique and it must be exactly the same (case-sensitive!) as what has already been configured within the SP2010 web application. In this case that would be: urn:app:sharepointclaimsapp

Add the identifier, click "on “Add” and click on “Next >”.

Figure 7: The Add Relying Party Trust Wizard – Configuring Identifiers

-

By default you can only configure “Permit All” or “Deny All”. After the creation of the RP trust you can configure all kinds of complicated conditions if you want to!. For now select the option “Permit all users to access this relying party” and click on “Next >”.

Figure 8: The Add Relying Party Trust Wizard – Issuance Authorization Rules

-

This page lists through the different tabs the configured options. Review them all and after that click on “Next >”.

Figure 9: The Add Relying Party Trust Wizard – Summary

-

By default the option “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” is selected. At this time UNcheck it as we will further configure the RP trust through PowerShell.

Figure 10: The Add Relying Party Trust Wizard – Finishing

-

To get the full configuration of the just created RP trust “Claims Based Sharepoint App”, use the following powershell command

Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App"

Figure 11: The Configuration Of The RP Trust “Claims Based Sharepoint App”

-

First, we are going to disable security token encryption on the RP trust “Claims Based Sharepoint App”.

Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App" | FL Name,EncryptClaims
Set-ADFSRelyingPartyTrust -TargetName "Claims Based Sharepoint App" -EncryptClaims $false
Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App" | FL Name,EncryptClaims

Figure 12: Disabling Encryption Of The Security Token For The RP Trust “Claims Based Sharepoint App”

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 8)

-

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

(2012-09-19) Claims Based Authorizations For Sharepoint Through ADFS (Part 6)

-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 5)

-

For information about how to install ADFS v2.0 see the blog post about Installing And Configuring ADFS v2 As An STS Server (part1, part 2, part 3) and about Installing And Configuring ADFS v2 As A PRX Server.

-

By default ADFS has one claims provider trust defined and configured called “Active Directory”. That CP trust is also configured with a default list of claims rules (see picture below). For more information about this also see:

• (2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0
• (2011-10-24) AD FS 2.0 Claims Rule Language Primer From The ASKDS Team
• (2011-10-24) Configuring The New Five Claim Types In ADFS After Installing Rollup Package 1 For ADFS v2.0

-

Figure 1a: Default List Of Acceptance Claims Rules For The “Active Directory” Claims Provider Trust

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSClaimsProviderTrust "Active Directory").AcceptanceTransformRules

Figure 1b: Default Configuration Of Each Acceptance Claims Rule For The “Active Directory” Claims Provider Trust

-

Using a PowerShell script I imported my own defined list of claims rules for the “Active Directory” Claims Provider Trust. The total list now looks like is shown below.

 

Figure 2a: Total List Of Acceptance Claims Rules For The “Active Directory” Claims Provider Trust (Default And Custom)

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSClaimsProviderTrust "Active Directory").AcceptanceTransformRules

Figure 2b: Configuration Of Each Acceptance Claims Rule For The “Active Directory” Claims Provider Trust (Default And Custom)

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 7)

-

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————