How Identities are Handled in Appit

  • 16 February 2021
  • 0 replies
  • 68 views

  • Anonymous
  • 0 replies
 

How Identities are Handled in K2 Cloud

KB001958

PRODUCT
K2 Cloud

 

Introduction

Beginning with K2 Appit 1.5 Update 6 and continuing in K2 Cloud, identities from Azure Active Directory (AAD) and SharePoint Online are synchronized to the Identity Cache using the Identity Microservice. This service eliminates the need for the K2 server to resolve identities on-demand and to expire identities, resulting in better performance and handling of identity information.

 

The identity microservice is managed by K2 Operations and requires little involvement or configuration. Use this article, and especially the Considerations section at the end, to understand the changes and implications of this service.

 

 

 

 

About the Identity Microservice

The identity microservice automatically synchronizes identities and updates from AAD and SharePoint Online to K2. Supported identities include users and groups stored in Azure Active Directory, Office 365 groups (which are AAD groups), and SharePoint groups.

 

SharePoint group membership is limited to AAD users and groups. If you have any non-AAD identities in a SharePoint group, they are not synced to K2.

When K2 is provisioned, an AAD sync job is created and all AAD groups and users are synced to the identity cache in K2. This process can take some time to complete, depending on the number of AAD users and groups you have. Additionally, when you run the K2 for SharePoint Site Collection Activation Wizard, a SharePoint sync job is created for that SharePoint site collection and then SharePoint groups and memberships are synced. Once the full sync is completed, differential syncs occur every 15 minutes. You can contact K2 Support if you need to change this interval.

For Appit instances that are upgraded from K2 Appit 1.5 Update 5, the SharePoint sync functionality occurs when you run the SharePoint Registration Wizard. This ensures that sync jobs are created for previously-activated site collections.

Synced Properties

The following properties are synced from AAD:

Users

  • deletionTimestamp 
  • displayName 
  • mailNickname 
  • mail 
  • accountEnabled 
  • givenName 
  • refreshTokensValidFromDateTime 
  • surname 
  • userPrincipalName 
  • userType

 

Groups

  • displayName 
  • mailNickname 
  • mailEnabled 
  • securityEnabled

 

The following properties are synced from SharePoint:

Users

  • PrincipalType
  • Id
  • Title
  • LoginName
  • Email

 

Groups

  • Id 
  • Title 
  • LoginName 
  • Users/Id* 
  • Users/Title* 
  • Users/LoginName* 
  • Users/Email*

 

* related to members in the group

 

 

Considerations

There are several considerations to keep in mind when working with identities in K2.

  1. The K2 server never queries AAD or SharePoint Online directly when needing to resolve a user or group.  For example, when a task is to be assigned to members of a SharePoint group, the K2 server only looks at the data in the internal cache previously populated by the identity microservice sync.  It does not query SharePoint to get the group membership.  The only time the K2 server queries AAD directly is if a solution uses the AAD SmartObjects, for example when using the AAD wizards to manage data in AAD.
  2. SharePoint group membership synchronization is limited to AAD users and groups. If you have non-AAD users or groups in a SharePoint group, they are not synced. This means that if you use such a group to assign tasks, those non-AAD users will not be assigned tasks.
  3. Synchronization happens every 15 minutes by default, and this can only be changed by K2 Support.
  4. The Cloud Identity service broker is used during the SharePoint Activation and Registration Wizards to configure and run group synchronization during SharePoint configuration. If you need to run the broker directly, you must be a K2 Administrator.
  5. The identity microservice and the Cloud Identity service broker does not work with SharePoint on-premises or Active Directory.
  6. You cannot configure the list of user and group properties that are synchronized.
  7. A UPN is required for all users, and duplicate UPNs are not permitted by AAD.
  8. Group names are matched based on the DisplayName attribute in AAD. AAD allows different groups to have the same DisplayName value, however, this is not a recommended configuration in K2. You should have unique display names for every AAD group before integrating with K2. If you imported groups from an on-premises AD, you can change them in the source or by using a transformation rule in AAD Connect.
  9. If duplicate group names are found, K2 updates the existing group with the duplicate group's attributes and merges both group's membership.
  10. If you change the group name in AAD, the old group is disabled in the identity cache. This means that you must update any tasks that are assigned using the old group name to the new group name, and redeploy those workflows.
  11. If a user or group has not been synced, they cannot log in to K2 or get access to any K2 artifacts. You must wait until the identity microservice has picked up the change and populated the local cache.
  12. The identity cache itself is not new, only the identity microservice. This means that K2 operates in almost the same way when it resolves users and groups. However, the server does not try to resolve them directly using AAD, it denies users and groups who are not already in the cache, and the cache contains all users and groups from AAD and SharePoint versus only those who have integrated with K2 in some way. This new way of caching all users does not affect K2 licensing.

 


0 replies

Be the first to reply!

Reply