Omada Provisioning Service

Omada Provisioning Service is a Omada Identity component service dedicated to provisioning rights within system onboarded to Omada Identity.

This article discusses the security concepts within Omada Provisioning Service such as OPS authorization, secure communication, and Self-service password reset. You should understand these aspects when you plan security in your Omada Identity implementation.

Secure communication

When you install the Omada Provisioning Service Windows Service, they are by default set to run in secure mode. However, this allows ALL authenticated users to access all endpoints.

All security is configured in the configuration file for the Omada Provisioning Service Windows Service and has the file name Omada.OPS.Service.config.

Authentication

Omada recommends that you use a wsHttpBinding, where the security mode is set to Message. The configuration file has a default binding called WindowsSecurity. Use this to ensure secure communication.

<bindings>
   <wsHttpBinding>
     <binding name="WindowsSecurity">
       <security mode="Message">
         <transport clientCredentialType="Windows" />
         <message establishSecurityContext="true" />
       </security>
     </binding>
   </wsHttpBinding>
 </bindings>` 

This binding configuration specifies that the messages should be encrypted, and clients are authenticated using their Windows credentials. The binding is then referenced by the OPS endpoints, of which there are three. You can configure each individually if you need to. Omada recommends that you use the WindowsSecurity binding for all of them:

<system.serviceModel>
   <services>
     <service
           name="Omada.OPS.Service.WCF.Impl.AllWcfServices"
           behaviorConfiguration="ProvisioningServiceServiceBehaviorSecure">
         <endpoint
           address=""
           binding="wsHttpBinding"
           bindingConfiguration="WindowsSecurity"
           contract="Omada.OPS.Service.WCF.Interface.IProvisioningService" />
         <endpoint
           address="configuration"
           binding="wsHttpBinding"
           bindingConfiguration="WindowsSecurity"
           contract="Omada.OPS.Service.WCF.Interface.Configuration.IProvisioningConfigurator" />
         <endpoint
           address="monitoring"
           binding="wsHttpBinding"
           bindingConfiguration="WindowsSecurity"
           contract="Omada.OPS.Service.WCF.Interface.Monitoring.IProvisioningMonitor" />

Authorization

info

In a default installation, no authorization takes place.

For authorization, OPS uses a custom module to specify which users and groups can access which services and operations. This module is referenced from the behaviorConfiguration in the service element:

<service name="Omada.OPS.Service.WCF.Impl.AllWcfServices"
       behaviorConfiguration="ProvisioningServiceServiceBehaviorSecure">

The behavior configuration looks like this:

<behavior name="ProvisioningServiceServiceBehaviorSecure">
     <serviceMetadata httpGetEnabled="true" />
     <serviceDebug includeExceptionDetailInFaults="True" />
     <serviceAuthorization
            serviceAuthorizationManagerType="Omada.OPS.Service.Security.AuthorizationManager, Omada.OPS.Service" />
 </behavior>

Configure through the custom configuration section named authorizationRules.

<authorizationRules>
   <services>
     <!--Configure security for the provisioning service->
     <service name="ProvisioningService/service" defaultAllowed="true" allowUsers="" allowRoles="" denyUsers="" denyRoles="">
       <operation name="SubmitProvisioningBatch" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
     </service>
     <!--Configure security for the configuration service->
     <service name="ProvisioningService/service/configuration" defaultAllowed="true" allowUsers="" allowRoles="" denyUsers="" denyRoles="">
       <operation name="GetTargetSystemConfigurations" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="UpdateTargetSystemConfiguration" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="GetMapperConfigurations" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="UpdateMapperConfiguration" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="GetObjectTypes" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="UpdateObjectType" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="GetPropertyDefinitions" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="UpdatePropertyDefinition" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
     </service>
     <!--Configure security for the monitoring service->
     <service name="ProvisioningService/service/monitoring" defaultAllowed="true" allowUsers="" allowRoles="" denyUsers="" denyRoles="">
       <operation name="QueryJobs" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="GetJobDetails" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="QueryTasks" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="GetTaskDetails" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="RetryFailedJob" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
       <operation name="ArchiveJobs" allowUsers="" allowRoles="" denyUsers="" denyRoles="" />
     </service>
   </services>
 </authorizationRules>

Each Omada Provisioning Service Windows Service has its own section. You can do authorization on service level or individual operation level, using the following attributes.

• defaultAllowed: This attribute is only available on service level. If it is set to True, no authorization is carried out for that service. Set it to False to specify which users and groups to give and deny access.
• allowUsers: A comma-separated list of the users that should be allowed to call the service or operation. You must specify the user name this way: domain\user. To enable authorization, specify the service accounts for RoPE and for the Omada Identity application pool identity.
• allowRoles: A comma-separated list of groups whose members should be allowed to access the service or operation.
• denyUsers: A comma-separated list of the users that should not be allowed to call the service or operation.
• denyRoles: A comma-separated list of groups whose members should not be allowed to access the service or operation.

Order of importance

1. Rules for operations have higher priority than rules for services.
2. Rules for users have higher priority than rules for roles.
3. Deny rules have higher priority than allow rules.

Run in secure mode

1. Set service behavior configuration to ProvisioningServiceServiceBehaviorNotSecure.

       <service name="Omada.OPS.Service.WCF.Impl.AllWcfServices" behaviorConfiguration="ProvisioningServiceServiceBehaviorNotSecure">

2. Set the binding configuration for all endpoints to NoSecurity.

   <endpoint address="" binding="wsHttpBinding" bindingConfiguration="NoSecurity" contract="Omada.OPS.Service.WCF.Interface.IProvisioningService" />
       <endpoint address="configuration" binding="wsHttpBinding" bindingConfiguration="NoSecurity" contract="Omada.OPS.Service.WCF.Interface.Configuration.IProvisioningConfigurator" />
       <endpoint address="monitoring" binding="wsHttpBinding" bindingConfiguration="NoSecurity " contract="Omada.OPS.Service.WCF.Interface.Monitoring.IProvisioningMonitor" />

3. Go to Setup > Master Data > Provisioning Service > Instances and set the Allow insecure connections setting to Default.

Encryption of data

The Omada Provisioning Service uses the same encryption library as other Omada Identity components. You can use the StringEncrypter.exe tool installed to encrypt Data Connection values or provisioning task values.

The encryption key

The Omada Identity and OPS both use an encryption key to encrypt and decrypt values. It is important that the Omada Identity and OPS uses the same encryption key.

The encryption key is stored in the registry in the configuration file for the component.

info

If the encryption key is changed, the Omada Provisioning Service cannot decrypt any passwords that were encrypted with the old password key. For more information on how to update PswEncryptionKey, please refer to the {here} section.

Encrypting OPS Connection strings

The OPS connection strings are maintained in a common configuration file named Omada.OPS.Service.exe.config, which is located at C:\Program Files\Omada Identity Suite\Provisioning Service. This file is used by all the Omada OPS services. The connection strings are located in the section:

<configuration>
   <connectionStrings>
     <add name="DatamodelContainer" connectionString="..." />

The strings can be encrypted entirely or partially, for example, if you only want to encrypt the password. You need to use the StringEncrypter tool to generate encrypted strings.

To encrypt part of the string, you need to use the StringEncrypter on the desired part of the string and then paste the encrypted part manually into the target string. The encrypted part must include special tags at the start and the end of it. The starting tag is "AES256:" and the ending tag is "=AES256", for example:

Server=localhost; User Id=AES256:bGUt1APx1lRsvcdwdf9BXQ===AES256;Password=AES256:bGUt1APx1lRsvcdwdf9BXQ===AES256;Database=OIS

The StringEncrypter adds these tags automatically.

Encrypting provisioning data

Encrypted data sent as part of an OPS provisioning task are automatically decrypted if the data model for the property defines the data type as secureStringType.

info

If properties are of the secureStringType data type, OPS automatically deletes the persisted values from its store after completing the provisioning task.

Encrypting data connection values

Data connection values entered during system onboarding, for example, password or client secrets, are automatically encrypted and stored in the Enterprise and OPS database.

If connection values are manually specified on the collector or the data connection data object, it is recommended to encrypt stored connection values, including the password.

In clear text, the data connection could look like this: hostname=DEMO;username=administrator;password=SomeSecretPassword;scope=DC=megamart,DC=com;

To store the password as encrypted, use the StringEncrypter.exe tool, and store the encrypted value: hostname=DEMO;username=administrator;password=###p43oEMhxLeEh9mDyNMnfkV1MLGcLzZ5wy/gzOjmro1w=;scope=DC=megamart,DC=com;

OPS stores the values as encrypted in its database and automatically detects that the value must be decrypted when in use.

Setting up the Self-service Password Reset integration

OPS integrates with the Self-service Password Reset feature (SSPR).

Enable password reset via Provisioning service ^on-prem

1. In Omada Identity, go to Setup -> Administration -> More -> Master Settings.
2. In the Password Reset section, click the OPS Client link, select the True checkbox, and click OK. You can now use OPS for password reset.
3. Perform an IISReset on the web service that hosts the Enterprise Server website.
4. Go to the Systems view, click the individual system for which you want to use password reset, then in the General settings task under Provisioning, select the checkbox for Enable password reset, and click OK to save the changes.
5. Make another IISReset to make your changes take effect.

Password reset object

The integration receives password reset requests from SSPR for systems on which the Enabled for password reset checkbox is enabled.

The integration sends one provisioning job containing tasks for all the accounts belonging to the identity that is the target for password reset.

Each task is of the object type PasswordReset. This object has the following standard properties:

Name	Type	Description
SSPR_AccountName	stringType	The account name.
SSPR_DistinguishedName	stringType	The distinguished name of the account. The value is only available for calculated assignments with an actual reason.
SSPR_NewPassword	secureStringType	This is the new password as entered by the end-user.The value is encrypted when you submit it in addition to in the database of Omada Provisioning Service.
SSPR_IsPasswordChange	booleanType	Indicates if the password was changed by the owner of the account.

Using provisioning relevant attributes

In addition to the standard properties listed above, attributes that are relevant to provisioning from the resource type are also added to the provisioning task.

If the resource type points to an attribute set that is relevant to provisioning with, for example, an attribute named FIRSTNAME, it is added to the PasswordReset object, with the name SSPR_ATTR_FIRSTNAME.

info

Ensure that the ATTR prefixing and attribute name are in upper case letters.

RoPE calculates provisioning-relevant attributes from either property set on the resource type or an extension.

Master settings relevant to password reset processes

To find the master settings relevant to the password reset processes, go to Master settings section.

Customer settings

To find the customer settings relevant to the password reset processes, go to Customer settings section.