Hybrid and Multiple Identity Provider FAQs

So how do end-users work with the product when there are multiple IdPs in the environment, and what doesn't work?

Multiple IdPs (and their default labels) would be systems like AD, Azure AD (AAD), AD FS (ADFS), SQL (SQLUM) and SharePoint (SP).

Any combination of these IdPs, excluding SharePoint in most cases, require your end-users to be aware of which identity they are logging into their task list with and how to switch identities when necessary.

Perhaps what you desire is a unified task list that has all of your tasks related to SharePoint on-premises, SharePoint Online and even non-SharePoint related tasks. This amounts to Single Sign-On (SSO), which the product supports but only for configuring service instance authentication.

SSO for your task list is not currently possible today because each IdP issues what it believes to be a unique user's complete information. A better way to think about it would be like wanting your Facebook and Linked In messages to be in the same shared inbox. This is not possible because it is two completely different systems in the background.

SSO solutions, like Okta, Ping and others, essentially log you in to the appropriate system at the appropriate time. Your identities in those systems does not become shared or the same. SSO systems do not solve the problem of having multiple, unique identities, but rather allow end-users to more easily manage their different identities so they don't have to remember multiple login names and passwords. But these systems do not provide data consolidation capabilities that would allow the product to be unaware that multiple identities are present.

If you are moving functionality to Microsoft 365 you may find yourself in this position: you have created new users on Microsoft 365 that map to current users, and you have not synced your AD users to Azure Active Directory.

The product supports users from multiple directories, and can inter operate between SharePoint on-premises and SharePoint Online. However, this scenario means that you have duplicated users in two different directories (AD and AAD), but there are scenarios where separate and distinct users have access to the online properties. Where there are effectively the same users in both directories, the product does not equate the AD users with the AAD users but rather treats them a separate and distinct users.

Having separate users means that there cannot be a unified worklist and that, when designing workflows, your destination users must be chosen from the correct label depending on the business rules. For example, if a client event step in your workflow requires that online users take action on the workflow, such as reviewing, approving or rejecting the request, if you choose users from the AD label (typically Nintex Automation), then the workflow participants coming in from SharePoint Online may not be able to see the task on their worklist or open the task.

One workaround, as a temporary measure to facilitate the move from SharePoint on-premises to SharePoint Online, would be to use the Management tooling to redirect tasks from AD user accounts to AAD User accounts for any existing tasks.

Another workaround (although this would only work when there is only one slot for a user task), is to assign all of the same user’s identities (e.g. Nintex:domain\bob and AAD:bob@domain.com) as destinations for the task. This way, the user can successfully open the workflow task regardless of which account was used to authenticate in the product.

You can use direct SmartObject calls using the SmartObject Services Tester Tool to ensure that users are resolved correctly and as expected. You can find the following SmartObjects under the All SmartObjects category in the tester tool:

• UMLabel
• UMGroup
• UMRole
• UMUser

These SmartObjects are part of the User Role Manager service and represent how the product manages to resolve users across all registered labels. If you are unsure how a user's information is being resolved, use this to test a known FQN.