Policies

Password policies

Memority provides extended capabilities to determine how passwords should be composed, and which rules apply to their lifecycle, depending on the identity type. Indeed, it’s possible to create one Password policy per Identity Type to ensure that the proper security level is enforced accordingly to their sensitivity. A frequently encountered use case is administrator identities and accounts which need to have a stronger password than regular ones.

Constraints

A Password Policy declares a set of constraints that an identity password must respect:

• Contents type:  letter, number

• Maximum, minimum length

• Percentage of different character

• Dictionary: to avoid special value ….

With this advanced set of constraints, Memority can adapt to any business password policy, whether it is simple or complex.

In this example, password must (or will be generated for user):

• be composed of 10 characters, with a least 1 digit, 1 letter and 1 letter in uppercase

• not contain the user's first name, last name or date of birth

• And not contain twice the same character

Lifecycle & Notifications

Password policies are triggered automatically during the lifecycle of an identity’s password:

• Activation strategy: which is used to configure what actions should be triggered when the password authentication method is activated for an identity

o   Example: When an identity is granted the password authentication method, a password will be automatically generated and sent to the identity. At the first connection, the identity will have to change its password.

• Deactivation strategy: which is used to configure what actions should be triggered when the password authentication method is revoked for an identity

• Grace period strategy

• Expiration strategy: which is executed before the password of an identity expires

In addition, Memority functional administrator or Helpdesk can directly manage the password of end-users in their scope using the Memority User Portal. By doing so, they can activate, revoke, or reset the password of an end-user.

As for any other actions performed in Memority, password initialization and updates are automatically synchronized with target application that must be provisioned with this attribute.

During each stage of the password lifecycle, Memority allows to trigger actions like sending a notification. Therefore, we could have:

• At creation, a password automatically generated for an identity and a notification sent to a manager or an Operational responsible.

• At expiration, a notification sent 4 days before password expiration and another one at 1 day before expiration.

Memority can also be configured to send an activation link through email or SMS to the end-user requesting him to set up his initial password, avoiding any manipulation by a third-party.

Deduplication policies

A Deduplication Policy describes how duplicates should be searched for when creating (whether performed manually, in bulk or through an API call) or updating (if needed) a managed object. The first objective is to avoid the duplication of an object.

A deduplication policy allows to define:

• A scope of population where the policy will apply

  • All Identities?

  • Internal only?

• A deduplication scope:

  • The scope can be configured directly by GUI by configure a mapping between attributes

    • Example: An Identity with the same first Name, last Name, Organization would be considered as a duplicates

  • Or through a programmatic rule coded in Groovy if needed

    • Example: Execute transformation on attribute before comparison, …

  • A priority: if more than one deduplication policy for an identity type exists priority will be use to prioritize these rules against each other

In this example, when creating or updating identities (of type internal) we will check that there is no other identity already existing with the same last name and the same first name and the same birth date.

Depending on configuration (in feature) it will be possible to adapt the behavior when a duplicate is found:

• Block and forbid the creation with an explicit error message with duplicates account finds

• Allows to directly update duplicate identity that has been found

• Authorize and force the creation if the duplicate is legitimate

The second objective is to manage the correlation between an existing identity and a new one. This process is used during the synchronization process as explained in the Identity creation chapter.

For a given import, it is done by configuring a correlation rule aiming to define how mapped the new identity to an existing identity. This correlation will be executed during each import occurrence, and for all identities (or objects) managed by the import.

Correlation can be configured:

• By a simple attribute mapping (same last name, first name or same HR identifier, …)

• By using a groovy rule to configure a complex mapping if it’s needed (orchestrate different search to find the duplicate account)

Other policies

Memority can be configured with Policies triggering the execution of custom actions following the occurring of an event on identities.

Policies are configured through code snippets in Groovy languages.

if (OPERATION.operation == ObjectOperation.PATCH && OPERATION.originalAttributes?.subContractType && OPERATION.originalAttributes?.subContractType != OBJECT?.subContractType){  
  if(OPERATION.originalAttributes?.subContractType == "Regie" && OBJECT?.subContractType =="Forfait"){  
    ApiObject patched = MANAGE.newPatch().add("flags").values(Flag.F01).atEnd().patch(OBJECT)  
    return ActionOutcome.success()  
  }  
}  
return ActionOutcome.noop()  

In this example, the objective is to flag an identity (of a certain type) when the value of the attribute changes from “Regie” to “Forfait” to be able to trigger other actions afterward.

Uses cases for which policies are used are multiple allowing to answer to very diverse business needs:

• Send notification

• Trigger a specific workflow

  • When Identity reaches an End date

  • When Identity is X days before this end date

• Compute an attribute depending on other attributes

• Remove access rights upon transfer

• …

To go further