Data Model

Attributes

Memority offers several built-in attributes to compose an Identity or an organization and allows to easily add new ones. Memority has no data model limitation. For each attribute a large set of configuration options are available:

Name
Object kind
Type
Rules: Validation, Initialization, Computation, …
Searchable
Confidentiality (to restrict visibility in the End User Portal), …

Identity Model

Memority allows to create and configure different Identity Types. It’s possible to manage on the same tenant different kind of population as Clients, Partner, Internal, External, Contractor, Administrators, Technical account, Connected Devices, ….

Memority allows to adapt the data model accordingly to each Identity Type configure on a tenant, dedicating specific attributes to some Identity Types when relevant and sharing common attributes across the different Identity Types to avoid configuration redundancy. The configuration of an Identity model relies on the following principles:

Which attributes are mandatory for this Identity type?
Which attributes can be used for filtering?
Unique Identifier rule for each object
Relationship with the organization model
etc.

Organization model

In large companies, it can sometimes be difficult to define a unique organization which supports all identities and habilitations processes.

To respond to this problematic, Memority offers the capability to design several types of organizations simultaneously through:

Hierarchical organization
Functional organization
Companies’ organization
Geographical organization
Project organization.

Once modeled and instantiated, these organizations objects can be assigned to the users depending on their Identity type when required.

These assignments can then be used as part of the rules governing workflows’ execution, administrative delegation, and entitlement automation.

As for an Identity object, Memority allows to configure for each organization type the rules, attributes, forms… to meet to business needs.

Role model

As for an Identity or an organization object, Memority allows to configure for each role type the rules, attributes to meet to business needs.

Identity constraints

Identity constraints are used to configure SOD rules to prevent the assignment of role (of a role type) to identities. They are configured with a groovy script, and they can be used to define rules based on:

Incompatible roles

GROOVY

if (DIMENSION.targetRole.id == "DY1849") {  
  def user = FIND.identity().withAttributesProjection("id").matching(expr { hasRoleMatching(role.eq("LU3596")) & status.eq('NORMAL') & id.eq(OBJECT.id)})  
  if(!user){  
    return ValidationRuleResult.invalid("Default message","ui.errors.identityconstraint.invalid.msg")  
  }  
  else {  
    return ValidationRuleResult.valid()  
  }  
}

When searching for role to assign, this rule will check that:

For role which identifier is “DY1849”, the beneficiary does not already have an active assignment for the role whose identifier is “LU3596”.
For the other roles, the request will be authorized by default.
Attributes of the identity

GROOVY

if (DIMENSION.targetRole.roleName.startsWith("Memority-US")) {  
  if(OBJECT.establishment != "Memority US"){  
    return ValidationRuleResult.invalid("Default message", "ui.errors.identityconstraint.invalid.msg")  
  }  
}  
if (DIMENSION.targetRole.roleName.startsWith("Memority-FR")) {  
  if(OBJECT.establishment != "Memority FR"){  
    return ValidationRuleResult.invalid("Default message", "ui.errors.identityconstraint.invalid.msg")
    }  
}

When searching for role to assign, this rule will check that:

For role which name starts with “ACN-US”, the establishment of beneficiary is “Accenture US”
For role which name starts with “ACN-FR”, the establishment of beneficiary is “Accenture FR”
For the other roles, whose name starts with another string, the request will be authorized by default.

Comment & Validity date rules

Moreover, Memority offers built-in mechanisms to define per role type (and even per role) some rules that need to be considered when assigning this type of role to an identity.

Role Object Type Configuration – Comment & Date rules

Rule on comment: Groovy rule that will check comment when requesting a role of this type
- Example: When Andrea request role B or C which are of the same type:
  - For Role B
    - Andrea must complete the comment to submit the request and it must be or Andrea won’t be able to request the role for the identity.
  - For Role C
    - Andrea can fill in the comment, but it won’t be a condition to request the role for an identity.
Time constraints: Groovy
- Example: When Andrea request role B or C which are of the same type:
  - For Role B
    - If the beneficiary is in Legal unit, then Andrea must complete the end date to submit the request
    - If the beneficiary is in another unit, then Andrea can fill in the begin date, but it won’t be a condition to request the role for an identity.
- For Role C
  - Andrea must complete the begin date to submit the request.
    - If the beneficiary is in Marketing unit, then Andrea must complete the end date to submit the request. And it must be within 6 months.
    - If the beneficiary is in another unit, then Andrea can fill in the end date, but it won’t be a condition to request the role for an identity.

GROOVY

if (DIMENSION.targetRole.id == "ROLEC"){  
  if(OBJECT.marketingUnit == "Marketing"){  
    return true  
  }  
  else{  
    return false  
  }  
}  
return false

To go further

Data Model