Authentication and Authorization

Microsoft Azure Active Directory is now Microsoft Entra ID

Introduction

The product authenticates the current user name against an identity store which authorizes that user (or system account like one used by the server) to perform actions within the platform.

In the past, the product, like most platforms built on Windows, required an Active Directory (AD) from which to retrieve a user's identity. User authentication happened behind the scenes and, as long as you were a valid user with rights, you could do things like impersonate and act on the user's behalf. Then when Windows switched to Kerberos as the more secure, default mechanism, administrators had to understand and configure a lot more trusts and constrained delegations than they were used to. To alleviate some of this, we introduced Pass-Through Authentication (PTA) which was used in cases where Kerberos wasn't entirely necessary or was simply overkill, and got administrators out of the business of configuring their environments for Kerberos.

Beyond Kerberos, the internet and widely-used sites and applications, such as Facebook, Twitter, and the like, forced the Windows world and platforms built on Windows, to work with those other systems across standard internet ports of 80 and 443 (a.k.a. HTTP and HTTPS). This, along with the drive to put Office in the cloud, resulted in Microsoft introducing authentication mechanisms in its products that could interoperate with other providers on the internet.

Authentication options for the product

Out of the box the product has always included the ability to install and work with a user source other than AD, which was and is SQL Server. Users don't have to belong to AD as long as you point the product to user information stored in SQL. SQLUM (the abbreviation for SQL User Manager) is the security label associated with users from a SQL identity store, just like Nintex is the label associated with AD users.

The product also supports other user managers, including custom ones, so technically the product could understand user information from any identity store.

SharePoint 2010 introduced an authentication mechanism different than Windows/NTLM, namely claims-based authentication (CBA). With SharePoint 2016 and 2019, even if your network runs Windows/NTLM, your tickets from SharePoint are Windows identities wrapped in a claims token, and this is the default mechanism for how SharePoint handles identities. Claims tokens from SharePoint are sent in specially-formatted XML called SAML. So when referring to a claims token from SharePoint or the product, they are SAML tokens. Other formats are out there but not supported by SharePoint or the product.

Any system that needs to do something with users coming from SharePoint must at least be able open (sometimes referred to as crack or resolve) the claims token to figure out who the user is, and more importantly, where they're coming from.

For information on the product and SharePoint authentication, see the topic: SharePoint Integration with Nintex Automation.

Be sure to read the following topics for background before configuring your security:

The articles that describe authentication and authorization in detail, including CBA and OAuth, can be found here:

The following sections describe installation scenarios from a security viewpoint and links to topics with information on configuration.

The product requires either Active Directory or SQL as your identity store already set up on your environment before you can install the product. Once installed, you can configure another authentication method.
  1. Standard Windows environment with AD as identity store
    • The standard Windows environment contains Active Directory (AD) as your identity store. All your user accounts are managed in AD, the only preparation necessary is creating the Service accounts.
    • Depending on your network setup, you may need to configure Kerberos or Pass-Through Authentication.
    • If integrating the product with SharePoint in this scenario, all claims mappings and OAuth configuration is set up automatically during registration of Nintex K2 for SharePoint if AD or AAD (Azure Active Directory) is used as your identity store.
  2. Non-AD identity store