Summary

This document explains the process of troubleshooting claims suppose to be sent in SAML messages through the WS Federation protocol in a Federated App (hosted in MS Azure) using IDP servers as an Identity Service in Access Manager 3.1.4 and later. Basically by following this quick and dirty process you will be able to see how the values configured in an attribute set are being sent from Access Manager to the Microsoft Azure App.

Symptoms

The Federated App's Administrators reported an unexpected behaviour related to the “claims” (user attributes) that are supposed to be sent through a SAML set messages via WSFederation Protocol. The App is expecting 4 different claims (IdCustomer, TypeCustomer, CustomerId, and NameCustomer) and just 3 of them are actually being received (IdCustomer, TypeCustomer, CustomerId)

Notice that each attribute sent trough a SAML message has the following syntax:

<saml:Attribute AttributeName="SomeName" AttributeNamespace="http://schemas.xmlsoap.org/ws/path/to/WSFed/Mapped/Claim"><saml:AttributeValue>ActualValue</saml:AttributeValue>

</saml:Attribute>

Note that the bold letters vary depending of the current configuration you have.

Procedure

The first thing to do is to review the current configuration in the Administration Console by selecting Access Manager -> Devices -> Identity Servers -> NameOfyourCluster (in my case tqidnuatclidp)

IDP Cluster

After that, select the WS Federation tab

WSFed tab

In the WS Federation tab, you will see the configured Service Providers of the Federated App's. In order to check the specific configuration you need to search for the domain name of the app reporting the problem, and look for an exact match in the ssoUrl property of the Service Provider Metadata.

Example:

Federated App: preprodcon.accesscontrol.windows.net/v2/wsfederation

Service Provider: Prepod

Service Provider

Once hit the service provider, look for ssoUrl in the Metadata module.

Metadata

ssoUrl = preprodcon.accesscontrol.windows.net/v2/wsfederation

ssoUrl

Once you find this occurrence, go back to the configuration tab and select the Attributes sub tab and verify which attributes are sent each time a user gets access to the Federated App.

At this moment, you can certainly be sure that the problem was originated by a misconfiguration (the Ldap Attribute: fullname is an available attribute in the Attribute set “WSFederationCNew”, but it is not configured to be sent with authentication.

In order to solve this issue, it is necessary to select the missing ldap Attribute and send it to the left side through the little arrows in the middle of the screen.

Validation

Once the configuration is correct, it's necessary to do a double check... as you can see, the initial report was that the Federated App was expecting 4 different claims (IdCustomer, TypeCustomer, identityProvider and CustomerId ) and just 3 of them (IdCustomer, TypeCustomer, identityProvider) were actually being received. In order to check what the exact configuration of the claims are, it's necessary to review the Mapping Attribute set by selecting Devices -> Identity Servers -> Shared secrets -> NameOfTheAttributeSet -> Mapping.

In the Left side (Local Attribute) you can see the available attributes of your User Store and in the right side the name of Federated App attribute which maps to

Mapping

In order to validate that the configuration is working, you only need to test the App and follow the trace with some addon able to catch a set of SAML messages (in my case I'm using Firefox with SSO tracer addon)

validation

Conclusion

By following the steps above you can verify the claims that a Federated Application (under WS Federation protocol) is expecting. I hope this can help you.