SharePoint Hybrid and Multiple Identity Provider Configurations

This topic explains what multiple identity providers means when configuring authentication, its implications on the end-user experience, and how SharePoint hybrid configuration affects the product.

When integrating the product into an environment with multiple Identity Providers (IdPs), you must be aware of the technical aspects of introducing this complexity into your environment and how it impacts the products functionality, especially for end-users. This includes environments where the product is integrated with SharePoint hybrid environments (although multiple IdP scenarios are also possible without any SharePoint integration).

The product works with SharePoint and non-SharePoint configurations that include multiple IdPs. In SharePoint, this is called a hybrid configuration, since it uses both an on-premises Active Directory (AD) provider for some users, and an online Azure AD (AAD) provider for other users. Sometimes these users are the same actual identity, but technically they are two separate identities. It is important to understand how the product works with SharePoint hybrid configurations, and what impact hybrid configuration has on the products SharePoint integration.

It is also important to understand what functions are not enabled by configuring multiple IdPs, such as presenting a unified task list to a user which spans all of that user’s identities from multiple IdPs.

• This document illustrates the issues and considerations to be aware of when:
• Integrating the system with a SharePoint hybrid configuration.
• Integrating the product into an environment where multiple identity providers are present.
• For Nintex Automation, converting the primary Nintex Automation (AD) label to a different label, such as ADFS, and needing to maintain historical data, workflow definitions and active workflow instances.
• End-users need to interact with their task lists and forms, and their identity information is not located in a single IdP.

Example Scenario and Illustration

You have Nintex K2 for SharePoint solutions on SharePoint Online and SharePoint 2019 on-premises, as well as SmartForms-based applications that do not integrate with SharePoint. All users authenticate against the label using their domain name when using the on-premises or non-SharePoint applications. However, when they log in to SharePoint Online and access a SmartForm, they are authenticated in the system against the AAD label using their UPN (e-mail address) as the identifier.

In other words, if Bob logs in to his PC and browses to a SmartForm, Bob is authenticated as Nintex:DOMAIN\Bob. However, if Bob has not opened a SmartForm, and then he logs in to SharePoint Online and browses to a SmartForms page, he is authenticated as AAD:bob@domain.com.

The custom domain (domain.com) is in place because Azure AD Connect is used to sync all domain accounts to Azure AD, and the way in which a user logs in determines which user they are authenticated as. (More specifically, the way in which they log in determines which IdP is used to authenticate that user). Furthermore, when a person authenticates against different IdPs, that person is not considered the same user according to the product, because their user identities are from two different locations (stores), and therefore they have two different, unique identities.

The user's unique identities, stored in two separate repositories, means that the server does not see the unique identities as related to a single identity.

This behavior is not unique to the product. Other systems such as SharePoint treat these users as different identities as well. As an example, if you were to switch a SharePoint on-premises server from using Active Directory to using Azure AD as its primary authentication method, you would notice that all of your previous rights and membership (based on the identities stored in AD) would not apply to the Azure AD users. You would need to grant all Azure AD users access to the SharePoint sites, essentially recreating the AD rights but with Azure AD users.

Illustrating Different Identities in SharePoint

Although SharePoint does a good job of masking who your identity is and tries to make it seamless between on-prem and online, you can easily demonstrate the differences by creating two lists, one on your local on-prem SharePoint site and one in SharePoint Online. Add the Account field to the newly-created list and then create an item in each list.

In the on-prem server you'll see the domain name as you would log in to your computer on the corporate network.

In SharePoint Online, you'll see that your identity is different, and looks more like an e-mail address.

This scenario exists when SharePoint is not setup in hybrid mode and there is no mechanism in place for syncing accounts between AD and Azure AD.

The sequence of steps below illustrates the impact on worklists and SmartForms when multiple identity providers are used, using a typical SharePoint hybrid scenario:

1. A user navigates to a non-SharePoint SmartForm, such as a SmartForm with the worklist control, and is authenticated as Nintex:<domain>\<user>, such as Nintex:DENALLIX\Johnny, and the cookie is kept in memory.
2. The user is assigned as the destination user in a SharePoint Online workflow as AAD:<email address>, such as AAD:johnny@denallix.com
3. The user receives a task e-mail from the SharePoint Online workflow with a link to open the task.
4. The user clicks on the link and when the SmartForm page loads, it recognizes that this user has an authentication cookie already saved and uses these credentials to open that page.
5. The user is authenticated as Nintex:DENALLIX\Johnny because the cookie was created like this the first time when the original worklist SmartForm was opened in step 1.
6. The product throws an error stating that Nintex:DENALLIX\Johnny is not allowed to open this worklist item. This is because the user's FQN does not match who was assigned the task (AAD:johnny@denallix.com).

To temporarily workaround this problem, the user closes all browsers and then deletes all cookies. They click again on the link in the task e-mail. This prompts them to log into Microsoft 365 and, once they do, the SmartForm page is displayed without the error in Step 6.

User Information in Nintex Automation

The first item to familiarize yourself with is how the product handles identities. Using what's known as a User Manager, the product associates each user based on where their user information is stored, and prefixes a label to that user's login name, forming what's called a Fully Qualified Name (FQN). Think of this as your label if you have AD, and the SQL, AAD, SP and ADFS labels if you've already configured the product to use a different User Manager or if you’ve added the Nintex K2 for SharePoint app to your SharePoint Online sites.

For example:

• A typical AD user's FQN: Nintex:DENALLIX\Johnny
• A typical AAD user's FQN: AAD:johnny@denallix.com

For a complete discussion of this topic see Introduction to User Managers. For an example of an environment where multiple user managers are used, take a look at the following User Browser. This environment has five different user managers in use:

• CRM
• K2
• K2ADFS
• SHAREPOINT
• SP

It's important to understand that each of these user managers stores user information, and while a user's actual identity might be the same across multiple labels, to the product each of these users are distinct users and there is no mechanism to treat two or more users across different labels as the same user. This is true for the product as well as SharePoint and most other line of business systems – a user's unique identity cannot be shared or equated with another, unique identity. What makes a unique identity is the label and the user's login name from the IdP, such as Nintex:DENALLIX\Johnny or AAD:johnny@denallix.com.

It is important to understand the implications of having multiple user identities for a single, actual user, present in multiple IdPs. Because the product and other systems must store the unique identity of a user, changing that user's unique identity (or needing to equate it with another, unique identity) has fundamental challenges associated with historical data, workflow definitions, and running workflow instances.

Assigning Work to Someone

When you use the Context Browser to assign work to someone, such as adding them as a destination user on a workflow task, you must choose a user that is known to the system. If the product has not been configured to resolve users from a particular user identity store, then you cannot assign those users any work.

When using a SharePoint group as a destination user e.g. to assign work to anybody contained in that group, the SP object is used by other user managers, such as the label, to resolve users in the group. However, if a user in that group is not known by the product, they will not be able to get work assigned to them.

How You Authenticate with the product

When you browse to a SmartForm directly, and you're on your company's network that is based on Windows Active Directory, your credentials are automatically passed to the system via a Kerberos token. This verifies your identity and registers you as a user with a label. If you browse to the Nintex Designer you'll see that the product knows your identity.

If you hover over your username you'll see your FQN in a tooltip. In this case, the tooltip says Nintex:DENALLIX\Johnny. If Johnny had signed in with his AAD credentials, the tooltip would be AAD:johnny@denallix.com, but would still look the same from simply glancing at his name in the upper right corner of the Nintex Designer.

If you are browsing a SharePoint site (on-prem or online), and you open a form or integrate a list or library with the Application, your identity is passed to the system. Your username is matched against a known user manager in the product. If you're not known to the product, you may see errors such as the following:

• Error: You do not have permission to open this form.

• Error: You must be a member of the Solution Designers group to design applications.

Many times this means that although SharePoint knows who you are, the product does not. You might check your various permissions if you think the product should know who you are, but if the permissions appear to be OK, you are most likely dealing with a problem of the identity only being configured for SharePoint and not the product. In the SharePoint 2019 and SharePoint Online architecture, any third-party app such as the product must directly trust all identity providers used by SharePoint.

You may see a different error, namely

The user "K2ADFS:johnny@denallix.com" cannot be found in SharePoint.

If you see this error, it means that you have multiple identity providers configured across multiple SharePoint farms, and your workflow has most likely assigned a task to a user that doesn't exist on, or have permissions to browse, a particular site.

How you access a item such as your worklist, determines what you're able to get to and see. For example, your worklist lists all the work assigned to the identity that you are currently logged in to SharePoint with. If you have two logins for SharePoint, and you're working with multiple apps across multiple SharePoint sites, there is no way currently to see a consolidated list of tasks. The workaround is to have the Worklist app part in each SharePoint environment where you expect to get assigned tasks.

Recommendations

We recommend that you establish your identity store strategy before building, deploying and starting product solutions. Changing your identity strategy after you've had the product in place for a while will affect your reports and possibly other purposes for which you're using data captured by the system processes.

If you have concerns about how the product works with multiple IdPs, you can log a support ticket in order to discuss your strategy moving forward. For more information see Nintex Customer Central

Conclusion

Handling the SharePoint Hybrid scenario, and any other scenario that requires the product to handle users from multiple identity providers (IdPs), results in some challenges and behaviors in the product that may not be desired. If you can plan your identity strategy before deploying solutions, you can avoid some issues that cause identity problems when moving to a new identity provider when running and completed process instances are present.

FAQs

For a list of Frequently Asked Questions about this topic, see Hybrid and Multiple Identity Provider FAQs