When accessing a federated application, from a troubleshooting perspective, it can be very interesting in knowing/seeing which claims are being send to the application. ADFS itself logs that information in the Security Event Log, assuming auditing has been enabled. However, to know about all the claims send to an application you might need to go through multiple event IDs.
–
For more information about enabling the auditing of issued claims see in ADFS:
–
If you have a farm consisting of multiple ADFS STS servers, you need to understand first which of the ADFS STS servers in the farm serviced the issuance of the security token. In summary, it can be quite a pain to get the required information when needed. Now, wouldn’t it great to have a claims-based application that shows the claims from the security token that was issued by the (last) federation system? Yes it would!
So how would you display the issued claims for a specific claims-based application on another claims-based application? That’s easy!
Let’s say that the "Display The Issued Claims" claims-based application is the application that display all the claims from a security token.
Let’s say that the "Collaboration" claims-based (SharePoint) application is the application for which you want to see the issued claims.
Configure the exact same issuance transform rules in ADFS from the RP trust representing the "Collaboration" claims-based (SharePoint) application on the RP trust representing the "Display The Issued Claims" claims-based application. Now tell the user to navigate to the "Display The Issued Claims" claims-based application and ask the user to e-mail the contents of the website by pressing [CTRL]+[A], followed by [CTRL]+[C] and followed by [CTRL]+[V] in an e-mail to the service desk.
–
In this blog post, the "Ask PFE Platform" guys explains how to setup the website I’m talking about. However, it requires different manual steps to implement it. I used the exact same website and created a brand new deployment script that helps you setup the website in IIS and the RP trust in ADFS. So, let’s get started and see how you can deploy this.
–
You can download my version of this from here and unpack it on the Windows Server 2012 (R2) where you want to deploy it.
Before running the script, make sure the following is clear:
–
After unpacking the ZIP file on the server where you want to deploy website, AND taking care of all the points above, execute the script ‘Deploying-Claims-Based-Application.ps1’ that is also available in the unpacked folder. The script will guide you step by step in deploying the website and creating the RP trust in ADFS. The script always specifies what the next step will be before executing it.
–
After pressing any key, the script will install all required roles and features…
Figure 1: Current Step: Initial Screen Warming About Prerequisites – Next Step: Installing Roles And Features
–
After pressing any key, the script will check if ‘FedUtil.exe’ is available on the local server. If it is not available, the script will abort. ‘FedUtil.exe’ is required to generate the federation metadata of the application, so that a RP trust can be created by using the federation metadata URL of the application.
Figure 2: Current Step: Installing Roles And Features – Next Step: Checking Availability Of ‘FedUtil.exe’
–
After pressing any key, the script will check if ‘New-SelfSignedCertificateCustom.ps1’ is available on the local server. If it is not available, the script will abort. ‘New-SelfSignedCertificateCustom.ps1’ is required to generate a self-signed certificate as the Token Encryption Certificate for the application.
Figure 3: Current Step: Checking Availability Of ‘FedUtil.exe’ – Next Step: Checking Availability Of ‘New-SelfSignedCertificateCustom.ps1’
–
After pressing any key, the script will create a new application pool or use an existing one, depending on what you specify. When the choice is made to create a new application pool, a name and credentials need to be provided for the new application pool.
Figure 4: Current Step: Checking Availability Of ‘New-SelfSignedCertificateCustom.ps1’ – Next Step: Creating The Web Application Pool
–
After pressing any key, the script will create a new website or you can use an existing website and create a subfolder, depending on what you specify. When the choice is made to create a new website, HTTP binding information needs to be specified. When the choice is made to use an existing website, the virtual folder an its path need to be specified. In both cases the HTTPS URL to access the application, including the custom port if applicable, needs to be specified.
Figure 5: Current Step: Creating The Web Application Pool – Next Step: Creating The WebSite
–
After pressing any key, the script will check if SSL is enabled and enforced. If not, HTTPS binding information needs to be specified, including a certificate for SSL.
Figure 6: Current Step: Creating The WebSite – Next Step: Enabling SSL
–
After pressing any key, the script will retrieve ADFS related information (i.e. identifier, token signing certificate and endpoints) to configure the WEB.CONFIG of the application with.
Figure 7: Current Step: Enabling SSL – Next Step: Getting ADFS Information
–
After pressing any key, the script will use ‘New-SelfSignedCertificateCustom.ps1’ to generate a self-signed certificate with the subject you specify. Additional characteristics of the certificate are:
- EnhancedKeyUsage "Server Authentication"
- KeyUsage "KeyEncipherment","DigitalSignature"
- StoreLocation "LocalMachine"
- ProviderName "Microsoft Enhanced Cryptographic Provider v1.0"
- AlgorithmName RSA
- KeyLength 2048
- SignatureAlgorithm SHA256
- NotBefore $([datetime]::now.AddDays(-1))
- NotAfter $([datetime]::now.AddDays(3650))
- FriendlyName "Show My Claims ASPNET TOKEN" -exportable
Figure 8: Current Step: Getting ADFS Information – Next Step: Generating The Self-Signed Certificate
–
After pressing any key, the script will assign the account used in the application pool Allow:Read permissions in the private key of the certificate.
Figure 9: Current Step: Generating The Self-Signed Certificate – Next Step: Assigning The Application Pool Account Permissions On The Private Key Of The Self-Signed Certificate
–
After pressing any key, the script will copy the website from the specified source folder to the specified target folder of the website of the virtual folder.
Figure 10: Current Step: Assigning The Application Pool Account Permissions On The Private Key Of The Self-Signed Certificate – Next Step: Copy The Website Files To The Target Folder
–
After pressing any key, the script will configure the WEB.CONFIG of the application with the gathered information.
Figure 11: Current Step: Copy The Website Files To The Target Folder – Next Step: Confguring The Web.Config Of The Application
–
After pressing any key, the script will generate the federation metadata for the application based upon the WEB.CONFIG.
Figure 12: Current Step: Confguring The Web.Config Of The Application – Next Step: Generate The Federation Metadata For The Application
–
After pressing any key, the script will try to create the RP trust within ADFS using the federation metadata URL of the application. The issuance authorization rules will allow access for everyone (permit all). The issuance transform rules will send the userPrincipalName (UPN) as nameIdentifier to the application including any other issued claim.
Figure 13: Current Step: Generate The Federation Metadata For The Application – Next Step: Create The Relying Party Trust Within ADFS
–
The script will display all the RP trusts in ADFS and you need to decide if the name you specified for the RP trust is now included in the list of RP trusts. If it is in the list you are done and can specify Y or Yes. If it is not in the list you may need to solve why it did not create the RP trust by checking for example the Event Logs and fix what needs to be fixed. Then you can retry the creation by specifying N or No.
Figure 14: Current Step: Create The Relying Party Trust Within ADFS – Next Step: Confirm Creating Of The Relying Party Trust Within ADFS
–
Assuming you specified Y or Yes, the script ends and displays both the application URL as the federation metadata URL of the application. You can copy the that into a browser and try the application.
Figure 15: Script Finished Succesfully
–
If the federation metadata URL was specified in the browser you would see something similar.
Figure 16: Federation Metadata Of The Application
–
If the application URL was specified in the browser, the application should redirect you to ADFS and possibly ask you to perform Home Realm Discovery (HRD) by telling ADFS from which IdP you are coming from.
Figure 17: Home Realm Discovery Within ADFS v3.0 and Higher
–
Assuming WIA is enabled, the logged on credentials will be used. To configure and support WIA for different browsers, see:
–
The application now display the issued claims from the security token send to the application (begin of the list)
Figure 18: The List Of Issued Claims Within The Security Token
–
The application now display the issued claims from the security token send to the application (end of the list)
Figure 19: The List Of Issued Claims Within The Security Token
–
Enjoy!
–
PS: Mylo from the Access Onion has written a blog post about SimpleSAMLphp which is the similar PHP version of an application like this
–
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
Like this:
Like Loading...
Jorge's Quest For Knowledge! 