Overview of Claims-based Authentication

Microsoft Azure Active Directory is now Microsoft Entra ID

Claims-based authentication (CBA) is built on Windows Identity Foundation (WIF), a framework for building Windows-based, claims-aware applications and security token services (STSs) that is standards-based and interoperable. Interoperability is provided through reliance on industry standard protocols such as WS-Federation, WS-Trust, and Security Assertion Markup Language (SAML).

In CBA, an identity provider (IdP), along with the associated security token service, responds to authentication requests and issues SAML security tokens that include any number of claims about a user, such as a user name and groups the user belongs to. A relying party application receives the SAML token and uses the claims inside to decide whether to grant the user access to the requested resource. Claims-based authentication can be used to authenticate your organization's internal users, external users, and users from partner organizations.

The system relies on the configuration of a user manager to provide authentication and user/group resolution for identity stores such as Active Directory, SQL, LDAP, or a custom IdP. For more information see the topic: Introduction to User Managers.

The system provides the ability for incoming claims-based authentication through mappings between claims-based identity providers and a user manager. For more information, see the Claims References topic.

For information on how to configure Services to support Claims Authentication, see KB001426

Do not register multiple security labels against the SSPI (Windows Security Provider). Doing so will result in users being resolved incorrectly.

Claims-based Authentication needs to be configured and working on the server before starting the claims configuration for sites.

Known Supported Scenarios

The following CBA scenarios are supported. Note that this list is not exhaustive since there may be other CBA scenarios that also work. There are many different IdP and trust scenarios, so focus your efforts on integrating with those that support the technologies required for the system.

  • Claims-based Authentication for federated claims identities such as AD, AD FS, and Azure AD.
  • The use of a Windows Identity Foundation (WIF 3.5) utility (FedUtil) to configure a SmartForms runtime site to support federated claims-based users. New installs do not need any changes to the SmartForms web.config in terms of claims config as it is preconfigured for claims and uses the out-of-the box Windows STS and Forms STS.
  • When the runtime site is used in the Forms Viewer web part on a SharePoint site, flow-through of the claims users’ identities is managed for providers in SharePoint that are trusted. However, there is a one-to-one mapping between the identity provider and the SmartForms runtime site and you cannot have multiple identities at the same time with the web part.
  • Windows-based users (wrapped in claims or not) with a standard Windows authentication runtime site.
  • Multiple identity providers on the same runtime site (see Introduction to Multi-Auth).
  • Multiple trusted providers configured or using a Windows or Forms-based user login where the runtime site is used in the SmartForms Viewer Web Part on a SharePoint site (see Introduction to Multi-Auth).
  • Forms-based users wrapped in claims when configured using the FormsSTS, and the appropriate security provider is configured.
When Windows STS authentication OR Forms STS authentication is enabled, it is important to frequently save work that has been done in the Nintex Designer as work might be lost when the same session is left open for 8 hours or longer.