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.