The information passed from the provider in invalid

Issue

When configuring Federated Security and attempting to log in to the Designer or Workspace, we get the error:

The information passed from the provider in invalid

Or:

The issuer string specified in authentication provider configuration is invalid

Cause

There are numerous causes of this issue, we have documented some causes below:

Cause 1

When using the OKTA service provider, this issue is caused by an invalid configuration within OKTA itself

Solution 1

Within the Application settings in OKTA,
The checkbox 'Allow this app to request other SSO URLs' should be checked:

The Requestable SSO URL should be:    https://<<servername>>/TotalAgility/FederatedLogin.aspx
The Audience URI should be:                  https://<<servername>>/Agility.Server.Web

Working configuration:

Cause 2

This error can also be caused by an invalid certificate being passed in the SAMLRequest

Solution 2

Run a Fiddler trace whilst replicating the issue
Fiddler has the ability to send the SAMLResponse (or SAMLRequest) data to the TextWizard

To do this:

1. Find the row in the Fiddler Trace containing FederatedLogin.apsx
2. Double-click on the row which should open the "WebForms" tab under Inspectors (right-hand side)
   In the body, there may be RelayState, under that should be the SAMLResponse
3. Right-click on the Value for the SAMLResponse
4. From here, select "From DeflatedSAML" in the Transform dropdown
5. Copy the XML from the bottom textbox into NotePad++ and format it so that it is easier to read

Copy the X509Certificate value and paste it into the Federated Security settings in the KTA Designer
(Access the Designer using the Recovery Mode)

Remember to restart IIS and the Core Worker/Streaming services after updating and saving the Federated Security settings

Cause 3

This error can also be caused by a mismatch in the User Claims Mappings being passed to what is configured in KTA

Solution 3

To confirm, enable KTA logging the KTA web.config by un-commenting the following line & update the location of KTALog.txt (the folder must already exist):  

<add name="KTALog" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:\temp\KTALog.txt"> 

Capture a Fiddler Trace whilst replicating the issue
Check the generated KTALog for any error
Check the Claims that were passed in the SAMLResponse using the steps provided in Solution 2
Ensure that the format of the Claims match what is configured in TotalAgility User Claims Mappings
(Access the Designer using the Recovery Mode)

Remember to restart IIS and the Core Worker/Streaming services after updating and saving the Federated Security settings

Cause 4

This error can also be caused by the name, display name, given name, first name, surname etc. containing a Unicode Character which is not encoded in the SAMLResponse
e.g.
ą (Latin Small Letter A with Ogonek Unicode Character) - Unicode Hex Character Code &#x105;
ø (Latin Small Letter O with Stroke) - Unicode Hex Character Code &#248;

Some providers e.g. OneLogin will encode the character correctly and it is passed in the SAMLResponse using the hex code, however, other providers e.g. Azure, PingIdentity will pass the characters with no encoding

To confirm if this is the cause of the issue, capture a Fiddler Trace whilst replicating the issue
Check the Attributes that were passed in the SAMLResponse using the steps provided in Solution 2
i.e. look at the attributes and check for any un-encoded special characters in the attribute values
e.g.

Solution 4

Ensure the IdP is using an attribute name format i.e Basic, name e.g. User.FirstName and XS type i.e. String
In Azure we can use transformations to alter claims in order to facilitate reserved/special characters

Level of Complexity 

Moderate

Applies to