Users and user group

Built in user groups

Here you will find the different user groups in Omada Identity:

User Group	Description	How to become one
Application Onboarding Admins	Users tasked with reviewing the result of the Application onboarding process.	Requested through access request, assigned through policy, or manually added to the Auditors user group.
Auditors	Internal and external auditors who access Omada Identity occasionally to verify that things are as they are supposed to be.	Requested through access request, assigned through policy, or manually added to the Auditors user group.
CIAM End Users	Users external to the organization who have performed self-registration via the CIAM portal.	A person who completes CIAM self-registration becomes a member of this user group.
CIAM Service Users	Service user group for the CIAM portal. See also the Impersonation service users user group.	Requested through access request, or manually added to the CIAM Service Users user group.
Constraint Owners	Individuals appointed as owners of one or more constraints.	Requested through access request, or manually added to the Constraint owners user group.
Contractors	Individuals working for an external organization and hired as contract workers for a specified period.	Classify the identity as Contractor to automatically add them to the Contractors user group.
Data Administrators	Individuals managing the "master data" related to identity management, including identities, resources, and systems. Note: Data admins cannot change the configuration of OIS or manage properties and data object types	Requested through access request, assigned through policy, or manually added to the Data administrators user group.
Employees	Regular employees.	Classify identity as Employee to automatically add them to the Employees user group.
Everyone	All users.	All users are added automatically to this group
Impersonation Service Users	Service users that are used for integration from third party integrations for example the Omada ServiceNow application.	Requested through access request, or manually added to the Impersonation service users user group.
Managers	Individuals who are managers of employees and contractors.	Add the user to the Manager property of an identity or the configured Owner property on a business context data object. This automatically adds them to the Managers user group.
Operation Administrators	Individuals tasked with ensuring that Omada Identity runs smoothly.	Requested through access request, assigned through policy, or manually added to the Operation administrators user group.
Platform Administrators	Individuals tasked with ensuring that Omada Identity is installed correctly.	Managed by Omada Service Desk in Omada Identity Cloud. Only Platform adminsitrators can manage access to the Platform administrators user group.
Request Interpreters	Individuals appointed to interpret access requests stated in clear text into specific access rights.	Requested through access request, assigned through policy, or manually added to the Request interpreters user group.
Resource Owners	Individuals appointed as owners of one or more resources, responsible for approving access requests and monitoring assignments.	Add the user to the Owner property of a resource or resource folder to automatically add them to the Resource owners user group.
Security Officers	Individuals appointed to conduct evaluation approvals in the SoD violation workflow.	Requested through access request, assigned through policy, or manually added to the Security officers user group.
Service Desk Agents	Individuals working in the service desk for a part of the organization.	Add the user to the configured Service desk members property on a business context data object to automatically add them to the Service desk agents user group.
System Administrators	Individuals administering the configuration of Omada Identity, including properties and data object types.	Requested through access request, assigned through policy, or manually added to the System administrators user group.
System Owners	Individuals who own one or more systems.	Add the user to the Owner property of a system to automatically add them to the System owners user group.
Vault Service Users	Service users that are used for integration from third party vault integrations.	Requested through access request, or manually added to the Vault service users user group.

Create a new user

A user is anyone with the authorization to view or use Omada Identity. For a list of all users, go to Setup > Administration > Users. When window opens, click any of the users to see the details or click New to create a new one.

info

Only a user with System Administrator role can create new users from the users list.

The New User view is where you add or edit users. It is also where you assign group memberships to a user. In this example, Samuel Clarke is a new user who becomes a member of the Managers group.

For the existing users, you can change their password if you want to.

To do this, click the ellipsis (...) > Change password. Select Notify user of new password to send an email about the .

You can decide if you want to make it a requirement to always create a password for a new user when you create one.

Go to Setup > Administration > More... > Customer Settings and locate the Set new user password setting. If you set the value to True, a new password dialog box appears after you have created a new user.

Create new user group

A user group is a collection or bundled group of users you can assign to one or more authorization roles. For a list of all users, go to Setup > Administration > Users & Security > User Groups. When window opens, click any of the user groups to display the deatils or click New to create a new user group. The user groups view is where you add or edit user groups. It is also where you define members of a user group and assign resources to that group.

info

Only a user with System Administrator role can modify user group memberships.

The security summary link is where you can view the authorization roles assigned to this user group.

Create user groups via CM and OData API

You can also create users group via code method and OData API.

• To create the user group via OData API, you should create a sample request for creating the user group as below: POST: http://\[Omada Identity server\]/OData/DataObjects/UserGroup Body: { \"NAME\": \"NewUserGroup\", \"DESCRIPTION\": \"Description for NewUserGroup \" }

• You can also create the user group via the following code method CreateDataObjectFromTemplate. In order to use this code method, you must configure it with the parameter newDataObjectTypeUIdStr pointing to User Group data object type UId.

Give users access to process templates

info

If needed, you can give users access to start processes based on a particular process.

1. Go to Setup > Administration > Users and user group security setup > Process templates.

2. Enable the Read and Clone permissions for user groups that should have access to launch processes based on the template. When you are done, click OK to save the settings and close the dialog box.

   

3. In Setup > Administration > Users & security > Data object security setup, move the target object of the process to below the Target objects folder in the Tree structure.

   

Authentication level concept

The authentication level concept in Omada Identity allows a user session to have differentiated access levels for user group memberships and accesses derived through user groups, depending on the authentication method.

The default required authentication level for the following user groups is set to Medium.

• System administrators
• CIAM service users
• System owners
• Data administrators
• Operation administrators
• Auditors
• Application onboarding admins
• Security officers
• Service desk agents

The authentication level for all other groups is set to Low.To change the authentication level of a user group in the Omada Identity portal, go to Setup > Administration > Users & security > User groups and select a user group. Change the value of the Required authentication level field accordingly and click Apply.

The authentication level of a user group is evaluated when a user session is initiated.

Only memberships in groups with an authentication level that is equal or higher than the session's authentication level are applied to the user session.

The authentication level of a user session is determined by the authentication method:

• Regular authentication: authentication level is set to Medium.
• Authentication with impersonation (via an Impersonation Service User): authentication level is set to Low.

Changing the default authentication level using a custom authentication module on-prem

It is possible to change the default authentication level in Omada Identity by overriding the GetAuthLevel method in a customized Omada Identity authentication module.

Authentication level for specific authentication method or provider

It is possible to control what maximum authentication level is applied, based on the authentication provider. The AuthLevel column in the tblCustomerAuth table can be used to specify what authentication level is applied to the specific authentication method or provider. You can use it, for example, to limit the access to Platform and System administration for less secure providers or users from a specific provider.

Setting the authentication level to Medium will prevent users logged via an IDP provider from obtaining Platform administrator permissions.

info

Please ensure through a firewall that the host header parameter is not tampered. Spoofing the host name could be misused to elevate the authentication level.