Configuration Guide
Configuration Guide
Breadcrumbs

SoD Policies

Definition

In Memority, SoD rules are based on a SoD policy.

A SoD Policy allows to define what kinds of conflicts you can specify and what attributes the system will use to detect them.

Configuration

🎯

You can access the SOD Policy configuration :

  • by clicking on "Portal" → “SoD Policy”

  • by clicking on "System" → "Configurations" → "Data Model" and perform an import/export.

Properties

Properties name

Type

Mandatory

Description

Modifiable after creation

id

String

YES

The id is the unique identifier of the SoD Policy. 

It is case sensitive and no special characters (except - or _) are allowed.

NO

name

String

YES

The SoD Policy name.

The name may be different from the identifier.Must be at least 4 characters long.

YES

active

Boolean

NO

Allows to define if the SoD is activated or not.

ON, OFF

description

String

NO

Allows to describe the SoD Policy.

YES

sodRuleTypeId

String

NO

Used to indicate the id of the SoD Rule Type which refers to the Policy.

YES

decisionRule

Compute Rule

NO

An optional compute rule that must return an SodDecisionResult. This rule is executed right before the creation of an SoD violation.

The outcome depends on the return value:

  • SodDecisionResult.compliant(): instruct the system that the identity is actually compliant regarding SoD and that the violation should not be created

  • SodDecisionResult.violation("some message"): instruct the system that the identified SoD violation should indeed be created. A message can be provided and will be stored on the field decisionMessageof the SoD violation stored on the identity. This additional message will be displayed below the normal explanation of SoD conflicts on the UI.

  • SodDecisionResult.violation(): Same as the previous point, the violation should indeed be created, without the additional message.

This rule is mostly useful to interface the SoD decision with an external system (ERP, governance systems etc.)

The rule is provided with a SOD_VIOLATION context containing the different information about the current SoD.

Example:

Groovy
def role1 = SOD_VIOLATION.role1
def role2 = SOD_VIOLATION.role2
def ra1 = SOD_VIOLATION.roleAssignment1
def ra2 = SOD_VIOLATION.roleAssignment2
def policyId = SOD_VIOLATION.policyId
def identity = SOD_VIOLATION.identity

// business logic to decide SoD compliance
def compliant = ... 
  
if (compliant) {
  return SodDecisionResult.compliant()  
} else {
  return SodDecisionResult.violation()
}

It is common to use this rule when interrogating an external service. This means that the SoD policy is also tied to the rules on this external service. If the rules change on the external service, the refresh of SoD will not be automatic since it is outside of the perimeter of the solution. To perform this refresh the recommended way is to modify the value of the builtin attribute “sodRuleVersion” on rules. This will always trigger the refresh of active SoD rules on identities. Use this attribute to control the versioning of your SoD rules in relation to the rules of the external system.

YES

type

Enum

YES

Used to indicate the SoD Policy Type.

Different types are : APPLICATION_TO_APPLICATION, ROLE_TO_ROLE, APPLICATION_CATEGORY_TO_APPLICATION_CATEGORY,

ROLE_CATEGORY_TO_ROLE_CATEGORY

YES

SoD Type Properties

Application to Application type

This type will be used when the incompatibility is determined based on the values of the Role Attributes (flagged as resource).

Property name

Type

Mandatory

Description

application1SodAttribute

String

YES

Indicates the id of the Attribute that will hold the first incompatible Application.

Must be a mono-valued RESOURCE_REFERENCE attribute bound to the configured SOD Rule Object Type

application2SodAttribute

String

YES

Indicates the id of the Attribute that will hold the second incompatible Application.

Must be a mono-valued RESOURCE_REFERENCE attribute bound to the configured SOD Rule Object Type

Role to Role type

This type will be used when the incompatibility is determined based on the value of a given Role Attribute.

This is the strategy to prevent multiple assignments of a Role (i.e., make it incompatible with itself), or some refinements on dimension combinations.

Property name

Type

Mandatory

Description

role1SodAttribute

String

YES

Indicates the id of the Attribute that will hold the first incompatible Role

Must be a mono-valued ROLE_REFERENCE attribute bound to the configured SOD Rule Object Type.

role2SodAttribute

String

YES

Indicates the id of the Attribute that will hold the second incompatible Role.

Must be a mono-valued ROLE_REFERENCE attribute bound to the configured SOD Rule Object Type.

Application category to Application category type

This type will be used when the incompatibility is determined based on the value of a given attribute of the Role's resource.

Property name

Type

Mandatory

Description

applicationCategory1SODAttribute

String

YES

Indicates the id of the Attribute that will hold the first incompatible Application Category.

Must be a mono-valued RESOURCE_REFERENCE attribute bound to the configured SOD Rule Object Type.

applicationCategory2SODAttribute

String

YES

Indicates the id of the Attribute that will hold the second incompatible Application Category.

Must be a mono-valued RESOURCE_REFERENCE attribute bound to the configured SOD Rule Object Type.

applicationCategoryApplicationAttribute

String

YES

Indicates the id of the Attribute that will materialize the Application category.

The attribute must be bound to the Application type.

Role category to Role category type

This type will be used when the incompatibility is determined based on the value of a given attribute of the Role Attribute.

This type is suited for administration Roles, that are not linked to Applications.

Property name

Type

Mandatory

Description

roleCategory1SODAttribute

String

YES

Indicates the id of the Attribute that will hold the first incompatible Role Category.

Must be a mono-valued RESOURCE_REFERENCE attribute bound to the configured SOD Rule Object Type.

roleCategory2SODAttribute

String

YES

Indicates the id of the Attribute that will hold the second incompatible Role Category.

Must be a mono-valued RESOURCE_REFERENCE attribute bound to the configured SOD Rule Object Type.

roleCategoryApplicationAttribute

String

YES

Indicates the id of the Attribute that will materialize the Role category.

The attribute must be bound to the Role type.

Examples

SOD Policy - Application to Application
XML
   <ctdidm:SodPolicy id="sodApplicationPolicy">
      <name>sodApplicationPolicy</name>
      <description>SOD Policy - Application to Application</description>
      <active>true</active>
      <sodRuleTypeId>sodRuleApplication</sodRuleTypeId>
      <strategy xsi:type="ctdidm:ApplicationToApplicationSodStrategyType">
         <application1SodAttribute>sodApplication1</application1SodAttribute>
         <application2SodAttribute>sodApplication2</application2SodAttribute>
      </strategy>
   </ctdidm:SodPolicy>
SOD Policy - Role to Role
XML
   <ctdidm:SodPolicy id="sodRolePolicy">
      <name>sodRolePolicy</name>
      <description>SOD Policy - Role to Role.</description>
      <active>true</active>
      <sodRuleTypeId>sodRuleRole</sodRuleTypeId>
      <strategy xsi:type="ctdidm:RoleToRoleSodStrategyType">
         <role1SodAttribute>sodRole1</role1SodAttribute>
         <role2SodAttribute>sodRole2</role2SodAttribute>
      </strategy>
   </ctdidm:SodPolicy>
SOD Policy - Application Category to Application Category
XML
   <ctdidm:SodPolicy id="sodApplicationCategoryPolicy">
      <name>sodApplicationCategoryPolicy</name>
      <description>SOD Policy - Application Category to Application Category.</description>
      <active>true</active>
      <sodRuleTypeId>sodRuleApplicationCategory</sodRuleTypeId>
      <strategy xsi:type="ctdidm:RoleToRoleSodStrategyType">
         <applicationCategory2SODAttribute>sodRole1</applicationCategory1SODAttribute>
         <applicationCategory2SODAttribute>sodRole2</applicationCategory2SODAttribute>
        <applicationCategoryApplicationAttribute>appCategory</applicationCategoryApplicationAttribute>
      </strategy>
   </ctdidm:SodPolicy>
SOD Policy - Role Category to Role Category
XML
   <ctdidm:SodPolicy id="sodRoleCategoryPolicy">
      <name>sodRoleCategoryPolicy</name>
      <description>SOD Policy - Role Category to Role Category.</description>
      <active>true</active>
      <sodRuleTypeId>sodRuleRoleCategory</sodRuleTypeId>
      <strategy xsi:type="ctdidm:RoleToRoleSodStrategyType">
         <roleCategory1SODAttribute>sodRole1</roleCategory1SODAttribute>
         <roleCategory2SODAttribute>sodRole2</roleCategory2SODAttribute>
        <applicationCategoryRoleAttribute>roleCategory</applicationCategoryRoleAttribute>
      </strategy>
   </ctdidm:SodPolicy>
  • Business Policies

    A Business Policy allows to configure how to trigger actions on Object Types through a Feature with an optional configured Workflow.

  • Object Policies

    An Object Policy is an Identity Management Service Policy allowing to execute arbitrary actions on Managed Objects, either on a scheduled basis, or in reaction to an Object Operation.

  • Deduplication Policies

    A Deduplication Policy describes how duplicates should be searched for when creating a managed object.

  • Manual Provisioning Policies

    A Manual Provisioning Policy allows to define that manual provisioning or deprovisioning Workflow is launched when the Role assignment status changes.

  • Object Lifecycle Policies

    An Object Lifecycle Policy allows to configure rules, on all Object Types, that will alter an Object attribute directly when certain lifecycle events occur.

  • Password Policies

    A Password Policy determines how passwords should be composed and which rules apply to their lifecycle.

  • Role Request Policies

    A Role Request Policy allows to define if a Role can be requested, for whom, by whom, and using which Workflow.

  • Memority MFA Account Policies

    A Memority MFA Policy allows to configure how multi factor authentication should be applied to a population of user