As part of the recent upgrade in Nintex Promapp has implemented support for the SAML (Security Assertion Mark Up Language) conditions as part of its Single Sign-on functionality. These conditions improve the security of single sign-on and ensure that claims generated by your Identity Provider can not be replayed by another party to gain access to your Promapp site. The conditions supported include the time period that a claim is valid, whether that claim can be replayed, and specifying the intended audience for claim.
For more details, see the Single Sign-on help article or our Release Notes.
What are the impacts?
As part of any upgrade we thoroughly test Promapp’s adherence to the SAML protocol and it’s supported Identity Providers – Azure AD, Microsoft Active Directory Federated Services (ADFS), Okta, and OneLogin. However, the audience restriction typically allows for custom configuration and this is where we have seen issues for customers. The audience specified in your Identity Provider must exactly match your Nintex Promapp site URL. As a result when the claim to authenticate a user is received Promapp it is rejecting the request based on mismatch of the audience and responding with the unauthorised message.
How to resolve this issue?
The first step is to review how your Identity Provider is configured and what conditions are being applied to the claims it sends to a service provider like Nintex Promapp. Make sure the audience value is set to your Nintex Promapp site URL. You’ll find that setting here in the following providers:
Microsoft Active Directory Federated Services
An audience restriction does not apply for replying party trust configurations as recommended by our help article. However, after this update, if you have specified multiple identifiers for the relying party trust this may be applying the restriction. Please contact Nintex Support to review your configuration and claim rules.
In the next day, we will be rolling out an update which will allow the Nintex Support team to turn off the SAML conditions for your site. Once available, we’ll turn off the conditions for those customers who have reported issues. Following that we’ll need to work with customers to re-introduce the conditions. We will work with you to better understand how your Identity Provider implements the SAML conditions.
What we’ve learned
We apologise for the disruption caused by the changes. We have certainly realised adherence to a protocol doesn’t necessarily mean that it will work for everyone. In the future we’ll be taking the following actions to prevent a re-occurrence:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.