0

Identity Management – Putting it all together. It’s all about the Rules.

Share this content:
LinkedIn
Facebook
RSS

This is the sixth post in my series:

The basic principles of Identity Management and Cloud adoption

With all the components now in place (Authoritative Source, Identity Store, Identity Platform and Target systems), we can focus our attention on the configuration of the Identity Management solution and delivering what we set out to achieve. The automated provisioning, de-provisioning and synchronisation of accounts across the systems in an organisation.

An Identity Management system translates specific company policies regarding the provisioning, de-provisioning and account synchronisation, to logical rules that are configured to ensure the Identity Management system behaves in a way to support those policies. No matter what mode of operation the Identity platform uses, event based sync, scheduled sync or something in between. The Identity Platform will require configuring to synchronise the right attributes from the source to the vault and from the vault to the targets.

iam-typical-basic

This article focus’ on the configuration of the Identity Management platform that brings the real world company policies into a digital domain. Understanding what the policies should be is the critical component in this instance. The organisational policies should remain independent of the platform decision unless an Identity Management system is already in place.

Setting the Organisational Policies

Provisioning

The policies should be defined as the first step in establishing the Identity Management system and should be completed and released before any decision is made on what platform will best support therulesm. The policies will describe the requirements from the organisation with respect to what account data will be provisioned to what application, whether this includes group membership, location information etc so that the application or directory can use this data to deliver further capability or access for the user.

The organisation needs to first determine what the authoritative sources are for specific attributes, and where those attributes need to be provisioned.  Not every user requires an account in every target application and often times, those users provisioned may require certain levels of access. This can be determined based on location, role or other attribute data. Group membership may be determined by using similar data and provide the membership to access other applications.

Other policies around the login format, and logon times may be set by the Identity Management platform as well.  Firstname dot lastname,  email address or something else such as employee number can be set as the user id for logging in.

Account Sync

Synchronisation policies require an understanding of wreload-97640_960_720hat data is synchronised from what sources and sent to what targets and the frequency of the synchronisation. Synchronising a nightly text dump of identity information from the HR system may not be sufficient to keep the authentication Active Directory data up to date in time.

De-Provisioning

An often overlooked area of Identity Management is the automated de-provisioning which can be roughly translated to what policies take effect when an identity is terminated or no longer employed in the organisation.

In many cases, simply removing the account is not enough. Data associated with a de-provisioned  account may need to be transferred to a new owner or stored in an archive to support any longer term data retention policy.

Integrating with Existing Target Data

Data matching

Challenges exist in connecting existing manually managed target systems with the
Identity Management system. The identities in each system need to be matched to ensure they aridentity-matche all managed without duplicate or orphan accounts existing. This is a difficult process as often times a firstname, lastname and date of birth represent the only data that can be used to identify each individual identity.

Documentation

All policies need to be documented carefully to ensure a clear understanding of what the the identity management system needs to deliver with respect to the management of Identities between systems before any steps are taken to deploy the new system. Adding a n
ew target system will require an update to the policies and documentation with updates to the design and then the rules to provision,  de-provision and synchronise accounts in the new system.

The company policies,  once completed will be translated into the configuration of the identity management system, and the true benefits associated with the identity management system can start to be realised through improved security,  faster on boarding,  and lower costs associated with account management. The added benefits associated with synchronising the account information within minutes of the change in the source can not be understated.  Whereas a single name change may have required a manual change by the service desk across multiple systems and directories in the past,  the identity management system will now synchronise the change to each target triggered by the staff member making a change on the source data themselves through a self service module.

Early Start and Exceptions

Once configured, the Identity Management system will operate without a great deal of manual intervention. There are always exceptions to this of course. In one case we found we required a policy to handle hyphenated names. In some cases we establish an early start system that provides an interface to the identity management system to create an account in AD and some applications quickly to allow new staff to be productive within minutes of starting. This allows the HR team to focus on creating new accounts in line with the payroll policies. This means that a new temporary account will have the early start system as the source of truth until the new account is added to the HR system at which time a precedence is set to make the HR system become the authoritative source for the identity. Any early start system will need to engage workflows to ensure approvals are given before a new account is created. By the same token the temporary account needs to have an automatic delete associated with it to ensure it is cleaned up if the HR data is not created within a set period of time.

Rules can be changed to reflect an organisational policy change. New targets, new attributes and new sources can be added. In each case policies are updated and the configuration modified to reflect this update.

Martin Klein

Leave a Reply

Your email address will not be published. Required fields are marked *