OneList maintains it its own user accounts which includes include the following information:
- UserId - internal use for OneList;
- UserName - a unique key for every user. Its value is based on the customer's main user sourceThis is mapped to the common user ID of the organization;
- Profile - user profile, e.g. first name, last name, email;
- Manager - optional, the user's reporting manager;
Linking OneList User with Identity
...
It is important to identify which system OneList is the customer's main user source. The main user source is the source of truth of user information and is used to propagate users in other systems in the organisation. Generally, it is the organisation's Identity Provider system (IDP), e.g. active directory, Azure AD, or the ERP system, e.g. SAP.
OneList creates new user accounts based on the main user source and synchronise user profile with the main user source periodically or on demand.
Identity how users are linked between OneList and other source systems
The OneList Adapter for each source system is responsible for linking the source system user with OneLIst user account. Generally a user can be automatically linked by his or hers UserName or Email.
...
Provider (IDP) and Source System User
For OneList to automatically surface tasks to the user, it needs to establish the above link between the user’s IDP login and his/her source system user id. The OneList username is the key in this link. The general process of identifying the value for the OneList username is:
- Identify and agree on the common user identifier in the organisation. SAMAccountName and UPN are commonly used as the user id;
- Identify the claim from the Identify Provider that holds the common user id;
- Verify each source system if it can map its user account to this common user id. The adapter is responsible for producing the user mapping for OneList.
If a source system is unable to provide the user mapping then OneList will prompt the user to log on to that source system once before tasks are surfaced from that source system.
Where is the user linkage saved and how it is used
The linking between the OneList user and the external user is saved in the ExternalLogin table in the RoleManager database. The user linking information in this table is used by the RoleManager external log in process and the OneList task generation and task action processes:
- When the user logs in on via external Idp accountIDP, RoleManager OneLIst uses the Idpthe IDP's use user id to find the RoleManager OneList user id in the ExternalLogin table and grants access to the user;
- When OneList receives a task from Source System, it first uses the source system user id to find to find the RoleManager user, then finds the OneList user from the RoleManager userid in the ExternalLogin table, then assigns the task to the OneList user. The reverse lookup process is used to identify the source system user id when user actions a task.
OneList user account creation
...
There are two scenarios that an on how OneList user account is created:
- When a new task assignee is identified in a source system. In this case, the OneList Adapter makes a query to OneList after every task upload, to find if there is any user for that source system requires linking requiring a link to OneList user account. If OneList returns a list of the source system user id then the OneList Adapter can post the full detail of those uses that user to OneList. OneList then creates a new user account if require required and links the source system user id with the OneList user account. The prerequisite of this scenario is that the OneList adapter has full information of the use account including UserName and email.
- When a user logs on to OneList (via RoleManager) for the first time. In this case, the user either register a new account (via the Register link on the login page), or after authenticated by the organisation's IdpIDP. If using IdpIDP, RoleManager goes through the external log in process discussed above and creates a new user account if no existing user is found for the Idp user login.
Single-sign-on with organisation's Idp is achieved by linking the Idp's user login with OneList user account. This process consists of the following steps:
- Find existing user by UserName if a particular Idp claim is configured for user name match. Common claims for this purpose are SAMAccountName, UPN, prefered_username.
- Find existing user by email if the above user name claim is not configured.
- If an existing user is found, then update the ExternalLogin record for the user, otherwise, create a new user and insert the record to the ExternalLogin table.
- exists for the Idp user login.
Claims required from source system to setup OneList user profile
Claim Type | Source System Value | OneList User |
---|---|---|
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier | Source system user id | UserName |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | First name | FirstName |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname | Surname | LastName |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
ADFS configuration
Use OneList root URL as the RelyParty URL, e.g. https://iqx.onelistapprovals.com follow this link for step-by-step instruction at the ADFS side: https://docs.microsoft.com/en-us/aspnet/core/security/authentication/ws-federation?view=aspnetcore-2.2
Use ADFS server Windows Event Log to investigate errors.
Configure RoleManager using the following JSON:
{
"MetadataAddress": "https://adfs.cloud.weir/FederationMetadata/2007-06/FederationMetadata.xml",
"Wtrealm": "https://onelist-dev.cloud.weir/"
}
Azure AD configuration
DO NOT use the .Net MicrosoftAccount provider for Azure AD because it uses OAuth flow and won't be able to get custom claims. Only OIDC flow can retrieve custom claims.
Steps to register OneList on AAD: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app
The Redirect URI for OneList is: https://iqx.onelistapprovals.com/rolemanager/signin-azure
If OneList is registered for multi-tenant then tenant_id = common
Configure RoleManager using this JSON:
{
"clientid": "xxxxx",
"clientsecret": "xxxx",
"Authority": "https://login.microsoftonline.com/<tenat_id>/v2.0",
"CallbackPath": "/signin-azure",
"Prompt": "select_account",
"SaveTokens": false,
"UserNameClaim": "<custom user name claim>"
}
To avoid auto sign-in, add the following to the JSON.
...