In the previous post we setup Azure ACS and we were able to logout and authenticate. But we haven’t configured the return on what we do after the user has been authenticated. This video walks through the setup of handling the return identity.

Below are example sections that I used to edit my web config file as you see in the video. It’s important to note these are specific to SharePoint 2013.

 

1. Add to the bottom of the SharePoint Group
——


——

Example
—————————–




















—————————–

2. Add to section before Dynamics.
——


——

Example
——————————-







—————————-

3. Add to bottom of the config file.
——





http://axr3mavm11/sites/public/Enterprise%20Portal/UserRequestLoginAzure.aspx”; />
http://axr3mavm11/sites/public/”; />



http://axr3mavm11″; />








http://schemas.microsoft.com/sharepoint/2009/08/claims/userid”; />





https://none”; realm=”https://none”; />






——

Example
————————————










http://axr3mavm11/sites/public/Enterprise%20Portal/UserRequestLoginAzure.aspx”; />
http://axr3mavm11/sites/public/”; />



http://axr3mavm11″; />








http://schemas.microsoft.com/sharepoint/2009/08/claims/userid”; />





https://none”; realm=”https://none”; />







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

 

In the second half of the video we configured the TrustedRootAuthority to be out Azure ACS namespace. These where the commands we used in that sequence

1. Establish the claims mappings

$claim1 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”; -IncomingClaimTypeDisplayName “ACS Name Identifier Claim” -LocalClaimType “http://schemas.microsoft.com/custom/claim/type/2013/07/acs-nameidentifier”;
$claim2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider”; -IncomingClaimTypeDisplayName “ACS Identity Provider” -LocalClaimType “http://schemas.microsoft.com/custom/claim/type/2013/07/acs-identityprovider”;
$claim3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”; -IncomingClaimTypeDisplayName “ACS username” -LocalClaimType “http://schemas.microsoft.com/custom/claim/type/2013/07/acs-username”;

2. Provide path to the certificate

$acscert = Get-PfxCertificate c:\temp\ACSCertVM6.cer

It’s important that the certificate you are importing here matches the certificate you have used on you Azure ACS setup.

3. Establish the TrustedIdentityTokenIssuer

New-SPTrustedIdentityTokenIssuer -Name “AzureACS” -Description “Azure ACS” -Realm “urn:axr3mavm6:AzureACS”  -ImportTrustCertificate $acscert -SignInUrl “https://axr3mavm6.accesscontrol.windows.net/v2/wsfederation”; -ClaimsMappings $claim1,$claim2,$claim3 -IdentifierClaim $claim1.InputClaimType

 

-Name

In this example I used AzureACS. You can use any name but remember what you use as it gets entered into AX in a later step.

-Relam

As you saw in the video the realm I created to match the Relay part I created on ACS.

-SignInUrl

This will need to match your Azure ACS namespace.

 

4. Load cert

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($acscert)

5. Associate Cert with the TrusedRoothAuthority

$spcert = New-SPTrustedRootAuthority -Certificate $cert -Name “ACSTokenSigningCert”

 

Also in the video I turned on debugging on my web site which is done in this line in the web.config.

 

Links for Reference

https://technet.microsoft.com/EN-US/library/dn715949.aspx

 

There are a lot of steps in this one so tread carefully as things like the thumbprint can get extra characters when copy and pasting or lines can get truncated so just check what you have copied and pasted before changing the web.config or executing the command in power shell.

Cheers

Lachlan


Filed under: Infrastructure