General Configuration Principles

Overview

The diagram below presents the main concepts used in Memority's Identity Management. You can refer to it again after reading the overview.

Object Kind

Object Kinds represent the different kinds of objects that can be managed through the Memority solution.

Object Kind values are built-in.

The existing kinds are : Identity, Organization, Resource, Role and Role Publication.

An Object Kind express the nature of an object.

Each Object Kind define properties that are specific (and configurable) to the Object Types created with this Object Kind.

For example:

• An Organization allows the management of a hierarchy of children organizations and the inheritance of certain properties between the parent and its children.

• An Identity allows specific customization in terms of authentication

• etc.

Object Types

Object Types always belong to an Object Kind and allows to define the types of object that will be managed in the Memority Portal application and for each of these types the characteristics (attributes, validation rule…).

For each Object Kind, you can define one or several Object Types.

For example, one can choose to name and create the object types “employee” and “partner” of Object Kind Identity.

Each type of identity will be composed of :

• Built-in properties common to all Object Kind (identifier, name, description, etc..)

• Built-in properties specific to the Identity kind

• Bindings with Attributes Definition (for example an “employee” can have a binding to a “commonName” attribute with the “searchable” modifier).

To illustrate, one can create an Identity Type with the id “employee”, enforce that they must have 3 mandatory attributes bindings “firstName”, “lastName”, “salary” and apply a normalization Rule on the “lastName” to capitalize the value and a transform Rule to convert the salary value in a specific unit. Thus when creating identities of the type “employee”, all these requirements will apply. When configuring MFA access, because this type is of kind Identity, it can be referenced in the configuration.

To summarize, from the kind IDENTITY, one can create many “Identity Type” with different name and configuration for the attributes and rules. An “Identity Type” is not an Identity, it is a configuration that describes how instances (an identity) will be created, what are the mandatory attributes, what rules they need to respect and so on.

Attributes Definition

Attributes Definition are entities that define the properties of Objects Types. When starting to configure a Memority environment, you need to create Attributes Definition to be able to link them to Object Types (this was referred as “attribute bindings” previously).

By Default, When the Memority environment is created, we propose some standard attributes definition, that can be customized according to the needs. Therefore if the existing attributes definition are sufficient to configure the client's data model, it is not mandatory to create new ones.

Attributes properties are used to describe the core characteristics of the attributes. 
By default, all configured Attribute Definition are available for use on all Object Types (this can be restricted by explicitly setting the target Object Kind on the Attribute Definition).

In the same way that “Identity Types” are not identities, “Attribute Definitions” are not attributes “values”. They represent a configuration that describe the type of value expected (string, boolean, number etc.) and the rules that will be applied (lowercase format, unicity of the value among other members of the type etc.). When we talk about the attribute “firstName”, we mean its definition and the rules defined on the definition. When we talk about an identity’s firstName, we mean its value (ex: “John”).

Attribute Binding

Once we understand the concepts of Object Type and Attribute Definition, the concept of Attribute Binding is pretty easy to grasp: it is the link between an Object Type and an Attribute Definition. For instance, given a type “employee” we can bind it the attribute “firstName”. This means that instances of employees will have an attribute called “firstName” as part of their definition.

The Attribute Definition of the bound attribute can provide its own set of rules and constraints (ex: forbidding some values, enforce encryption of the value etc.). However, these rules are independent from the Object Type to which the attribute is bound. There are however rules that apply only to the Attribute Binding only, expressed as modifiers and configured on the Object Type binding table.

Attribute binding can be configured with different modifiers such as:

• “Mandatory” (when creating or updating an instance of the Object Type, it is mandatory to provide a value for this attribute)

• “Filtering” (the attribute value can be used when searching objects of this type)

• “Excerpt” (when asking for a short representation of the object the attribute will be part of the excerpt)

• etc. (the entire list of binding modifiers will be covered in their dedicated section).

Scope

A Scope defines a filter in order to target a specific population of Objects.

From this point on we will refer to the authenticated user performing an action in the portal as the Subject.

A Scope can be composed of at most 3 elements:

• an Object Kind which indicates which kind of Objects is allowed. A scope can only act on a single kind (Identity, Organization etc.).

• A list of Object Types of the previously mentioned ObjectKind

• a Search Expression selecting the set of Objects (already constrained by the ObjectTypes list) that can be accessed, and that might contain references to the Subject's properties.

Scopes can be used in many places, for instance to:

• Restrict access to a Feature (for instance an update form to edit identities, see next section) to a category of users.

• Specify the population to export in an Export Task.

• etc.

Search Expression

Search Expression are used to select the set of Objects that can be accessed based on fine-grained conditions. It can reference properties of the current Object (the object on which an action will be carried out, such as an employee update form) or even the Subject (authenticated identity that performs the action).

For example, if we want to restrict an action to the identities that are in the “Memority” organization and in the same “team” as the Subject (“team” being an attribute bound to the identity), we can write  organization = 'Memority' AND team = @SUBJECT.team@ as a search expression.

Features

Features allow users to manage Objects in the Memority Portal.

Access to a Feature must be granted by a Right specific to each Feature.

In a nutshell a Feature is composed of the following properties :

• a Scope, to specify which objects can be managed through the Feature. For example, we can have a feature that allows an action only on “Internal” Identities that are currently “disabled”, with the intent to reactivate each of them.

• a Screen that defines the user interface of the Feature, and contains Widgets to allow display or edition of object information.

Memority offers a large customization of the screen display (tabs, columns, sections, modals, etc.). The customization possibilities will be described in more detail in the Features page, but have been simplified here.

• One or many Operations (for CRUD actions on objects). For instance an UPDATE operation which will provide a button to patch the object with the values of the fields provided in the Screen.

• Additional Actions (notifications, custom rules, etc.).

Different types of features are proposed to allow the complete management of the object in Memority (Create, Read, Update, Search, Custom UI etc.)

A Feature is accessed by the user on the Memority Portal on /features/<feature id> after a permission check on the Subject and where the Screen is rendered with the configured elements and the operation actions displayed.

Widgets

A “widget” is an element of a Screen. The position of the widget in the Screen configuration allows to configure the ordering in the UI. The widget configuration allows to define the behavior.

Widgets are used (and are mandatory) in the configuration of a Feature Screen to allow the display or edition of object’s Attributes or manage Memority Portal functionalities. 

To meet all needs, Memority offers different types of widgets:

• Attributes Widgets for viewing or editing attributes. Depending on the attribute value type one will choose a checkbox, input text, file upload widget etc.. These can also be auto configured according to the attribute value type.

• Features Widgets offering a full functionality. For example, Search widgets (which allow to configure all search options for associated features), Reporting widget to display analytics, Provisioning widget to display the status of provisioning, MFA enrollment widgets (which allow to configure the enrollment possibilities of an MFA device) etc.

• Fields Widgets, this type of widget allows the edition of an information, as for an attribute, except that in this case the information is not attached to an attribute and is therefore not stored on the object (and in the database). These fields are mostly useful in Rules execution context (ex: add a checkbox field “notify my manager” and check its value in a Groovy Action Rule to send a notification or not upon submitting the feature).

Workflows

Workflows are used to implement a validation process of one or several step(s) to validate a task.

To meet all needs, Memority uses the BPMN standard to configure :

• The validation process itself (number of validation steps, sequence of steps, delegation...)

• The screen of the validation task(s) (the attributes presented and submitted)

• The workflow actors (workflow approvers, administrators ....)

• The notifications sent for each step of the workflow (workflow initialization, validation of the first task...)

Policies

A Policy is a set of rules that apply to a scope of managed objects. These rules or actions can be executed periodically or when an object (which belongs to the scope of the policy) triggers an event (such as being updated).

Memority proposes the following policy types to support all client needs :

Use Case Example

In order to make this as clear as possible we will present these concepts and how to use them in a concrete case for the company Acme.

Implementation of the Data Model

The first step of the configuration is to define the Data Model of the Acme company.

As we specified in the context of our use case, Acme wants to manage two different types of identities: the company's internal identities and the external service providers who may intervene from time to time on Acme projects.

These 2 types of identities each have specific properties :

• An internal collaborator must have a first name, a last name, a date of birth and a manager (this one being also an internal of Acme). In terms of organization, he will be attached to one of Acme's business units.

• An external provider will have a first name, a last name, a date of birth and an order number. In terms of organization, he will be attached to an external company.

Thus, to meet the needs of the company Acme we will have to configure 2 identity types, 2 organization types and 7 attributes definitions.

Identity types

• Internal : For them, the identity type will have to be composed of the following attributes:

• Provider : For them, the identity type will have to be composed of the following attributes:

Organization types

• Business Unit

• External Company

In the same way as we have just presented the identity types, each of the organization types can be configured to describe the specific attributes attached to it.

Identity management with dedicated features

The second step of the configuration is to define the Features needed by the Acme company to manage Objects (of Object Types) configured in the Data Model.

As we specified in the context of our use case, Acme wants to have dedicated features for each Identity types.

More precisely, Acme wants, for the 2 types of identities, to be able to :

• Create an identity

• Search for an identity according to certain criteria

• Visualize the information of an identity

• Edit the information of an intern

• Be able to assign roles to an intern and view the assigned roles.

Since the two types of identities have different characteristics in terms of attributes, validation process or management perimeter, most of the functionalities must be dedicated to one type of identity. As shown in the following diagram, the only exception in this use case will be the visualization and role assignment functionality where the characteristics will be the same and therefore the functionality (Feature) can be common.

We will now present the configuration of 3 of these features :

• The creation feature of a provider

• The feature to edit an internal

• The search feature of an internal

Provider Creation feature

The functionality for creating providers will be configured as follows:

• An Operation type CREATE to allow, as its name indicates, the creation of objects

• With a Scope on the provider identity type to restrict the creation of identity only of this type

• In the Screen, we will find Widgets in edit mode to allow the entry of values for the main attributes associated with the partner identity type

• Finally, in the configuration of this functionality we will associate the validation workflow for the creation of partners. Thus, after the submission of the functionality, the partner identity will not be created because its creation will be subject to validation by HR. A workflow will therefore be triggered allowing identities with an HR role to validate (with possible correction for certain attributes) or refuse the partner creation request.

The details of the workflow configuration triggered by the execution of the functionality will be detailed in the validation process part.

Internal Update feature

In the same way, the internal update functionality will be configured as follows:

• An Operation type UPDATE to allow as its name indicates the modification of object

• With a Scope on the internal identity type, to restrict the modification of identity only of this type. The Scope will also declare a Search expression to restrict the edition to the active internals only

• In the Screen, we find Widgets in display mode and others in edit mode to allow the visualization of certain attributes (not modifiable in the context of this functionality) and the edition of values for other attributes associated with the internal identity type

• Finally, in the configuration of this functionality we will associate the validation Workflow of modification of the end date of the internal. Thus, after the submission of the functionality, all the modifications will be taken into account immediately, except for the modification of the end date which will be submitted for validation. A workflow will therefore be triggered allowing manager then the HR to validate (with possible correction of the departure date) or refuse the request to modify the “endContractDate” attribute of this identity.

The details of the workflow configuration triggered by the execution of the functionality will be detailed in the validation process part.

Internal Search feature

A search functionality will be configured, because of its purpose, in a slightly different way than a creation or edition functionality. It will therefore include :

• An Operation type READ . In fact, in a search feature, in the same way as in a read feature, the elements can only be viewed and not modified.

• A Scope in order to limit the elements that can be searched on the type of internal. And a Search expression that will only display the active items, except for the logged-in user.

• The Screen for a search function will always include a Search Widget. It is the configuration of this widget that will define in the case of Acme :

  • The Columns (and therefore the Attributes) displayed on the returned results, namely the lastName, firstName, birthdate and the businessUnit to which the internal is attached.

  • The Button on each result line to allow quick access to the read feature (a link to another feature) to visualize the internal's information

  • And finally, the Search Criterion that can be used by the Subject (currently logged in user) to filter the search results, here the lastName and the businessUnit.

In most cases, this is the only widget present in a search feature. Redirection to other features can be configured for each result of the search through UI button actions displayed at the end of a row.

Implementation of identities lifecycle

To be able to manage the specifics of each type of Identity, Acme wishes to set up 2 different identity life cycles.
In this use case, we will present the life cycle dedicated to “providers”.

Provider Dedicated lifecycle

Acme Company wants to implement the following lifecycle for its providers (the “intern” lifecycle will be different):

• After an identity creation, it will become active only from its “start date” (a built-in attribute). Providers can be created in advance of their start date, but they will not be able to connect to the portal before their arrival date at Acme.

• Once their end date (also a built-in attribute) is reached, the providers will be automatically deactivated and will not be able to connect to the portal.

• After deactivation, if the provider returns for another assignment, he/she can be reactivated within 30 days.

• 30 days after his/her departure (if he/she has not been reactivated), the provider will switch to the deleted status (soft delete).

• 90 days after leaving, the provider will be deleted (hard delete) from Memority.

To implement this lifecycle we will have in Memority :

• Built-in jobs that will automatically change the enabled status when the start date is reached or when the end date is reach

• The possibility to reactivate an identity will be directly handled in features, to allow reactivation when the identity is at a certain state

• To handle the Soft Delete and Hard Deletion we will implement 2 object policies as follows :

Bellow you will find an example of groovy script for the 2 policies to meet the needs of the company Acme :

import com.memority.citadel.shared.api.im.ApiObject
import com.memority.citadel.shared.api.im.ObjectStatus
import com.memority.citadel.shared.api.services.manager.ObjectManager
import com.memority.toolkit.rule.api.ActionOutcome
import java.time.Instant
import java.time.ZoneId
import java.time.ZonedDateTime
import java.time.temporal.ChronoUnit

/*
This job will set the status value:
    - DELETED if status = RETIRED and time off
 */

// Settings
def archiveDelay = 30
def zoneIdSettings = SETTINGS.get("idm.tenant.timeZone") as String
def zoneId = ZoneId.of(zoneIdSettings)

// Attributes
def status = OBJECT.status as String
def enabledUntil = OBJECT.enabledUntil as Instant

def comparableArchiveDate=enabledUntil?.atZone(zoneId).plus(archiveDelay, ChronoUnit.DAYS) as ZonedDateTime
def comparableTodayDate=ZonedDateTime.now(zoneId).truncatedTo(ChronoUnit.DAYS) as ZonedDateTime

// Check if we are 30 days after endDate
if(comparableArchiveDate.isBefore(comparableTodayDate)){

    ApiObject patched = MANAGE.newPatch().set("status").value(ObjectStatus.DELETED).patch(OBJECT)
    return ActionOutcome.success()
}

return ActionOutcome.noop()

import com.memority.citadel.shared.api.im.ApiObject
import com.memority.citadel.shared.api.im.ObjectStatus
import com.memority.citadel.shared.api.services.manager.ObjectManager
import com.memority.toolkit.rule.api.ActionOutcome
import java.time.Instant
import java.time.ZoneId
import java.time.ZonedDateTime
import java.time.temporal.ChronoUnit

/*
This job will deleted users if status = DELETED and time off
 */

// Settings
def deletionDelay = 60
def zoneIdSettings = SETTINGS.get("idm.tenant.timeZone") as String
def zoneId = ZoneId.of(zoneIdSettings)

// Attributes
def status = OBJECT.status as String
def enabledUntil = OBJECT.enabledUntil as Instant

def comparableDeletionDate=enabledUntil?.atZone(zoneId).plus(deletionDelay, ChronoUnit.DAYS) as ZonedDateTime
def comparableTodayDate=ZonedDateTime.now(zoneId).truncatedTo(ChronoUnit.DAYS) as ZonedDateTime

// Check if we are 60 days after endDate
if(comparableDeletionDate.isBefore(comparableTodayDate)){

    MANAGE.delete(OBJECT);
    return ActionOutcome.success()
}

return ActionOutcome.noop()

Implementation of the validation process

We will end this use case by presenting the configuration of one of the validation processes required by the company Acme.

End Date Validation Process

As we have seen before, Acme wants to submit the modification of the end date of an internal employee to the validation of his Manager and then to the HR. So if an assistant modifies from the editing functionality of an intern his end date, this modification will be submitted to validation by the manager of the identity and of a HR (as long as the two validations have not taken place the modification will not be taken into account).
This validation workflow will be configured with 2 User Tasks.

First User Task - Manager Validation

The first one for the manager will be configured with :

• An Assignee Scope to define that only the identity that is assigned as manager of the identity can act on this task

For a validation task, different Identity Links can be named to meet all needs. The Identity Links allow you to define a scope for assignee, another for candidates and another for administrators. Identity Links available and their usage will be detailed in the Actors page.

• A Screen, composed of a Widget allowing the visualization directly in the validation task of the end date of the identity

In the context of a Workflow Screen by default for each widget the value submitted in the functionality will be displayed and the initial value will be visible on hover.

• A Notification that will be sent to the manager at the task initialization to inform him that he has an action waiting for validation.

Second User Task - HR Validation

The second task for the approval of the HR will be triggered only if the manager has approved the first task otherwise the workflow will be rejected.It will be configured as follows :

• A Candidate Scope to define that only internal identities that have the HR role (actively) can act on this task

• A Screen, composed of a Widget allowing the edition directly in the validation task of the end date of the identity

• Notifications:

  • One that will be sent to the requester of the modification and to all the candidates at the task validation to inform then that the workflow has been approved.

  • And another one that will be sent to the requester of the modification and to all the candidates at the task reject to inform then that the workflow has been rejected.

In this example the workflow is triggered by the submission of the feature but this is not always the case. Indeed, we could imagine a validation process for the end date of an identity that would be triggered in a programmed way 10 days before the end date in order to validate that the date is still correct. This type of process will be implemented through a Business Policy.