IAM as an HR driven Identity Access Management process

The management of staff in most organisations is done by the HR department, so why not use HR for Identity Management? Other identities such as contractors, temps and business partners are sometimes managed by other departments such as Procurement or Finance. AMX, an Access Management system can extract the identities from all these authoritative sources to find the joiners, movers and leavers, and transform them to a suitable format such that they can be used to load accounts into target resources such as the Active Directory, Exchange, LDAP, databases, Unix Systems, the Cloud etc. In its simplest form identity management is not an IT function and access management, which is, is a synchronisation process.

AMX can be used to manage accounts in multiple target resources leaving identity management to those with responsibility for it, the data owners.

AMX as a configurable Synchronizer

AMX is a low impact integrator that does not require databases, web or application servers to synchronize large often incompatible enterprise systems provided by multiple vendors. No database because it does not maintain a shadow copy of identities and accounts, it loads a fresh copy from the authoritative sources every time it runs. No application server because it does not need a User Interface, HR has one. It provides any or all of Create, Update, Deactivate and Delete CRUDD synchronisation modes of operation for staff joining, moving and leaving the organisation. For example records found in the source but not the target can be created. Records found in both the source and target can be updated so that the target matches the source. Records that are de-activated in the source can be de-activated in the target. Finally, records that have been removed from the source can be moved to a recycle bin in the target. AMX never deletes records in target resources.

AMX as a sceptical Synchronizer

Using an authoritative source of identities such as HR does not absolve IT from the responsibility for propagating HR’s unexpected changes or mistakes.

AMX was designed as a fully reversible Extract Transform and Load process with adapters to Extract records from identity sources and managed resources, Transform attributes and create the metaverse. The difference engine uses the metaverse to create a transaction file of the updates to managed resources and manual update batch files to both make and undo the changes. The transaction files allow full reversibility to any level.

The difference engine has sanity checking trip-wires for the CRUDD during the Load phase. The trip wire parameters define the maximum number of automatic load operations on a managed resource. They can be defined globally or individually for each managed resource and are checked before the Load phase starts.

IAM as an Automated Process

When an authoritative source of managed identities is used, account management can be automated and Identity and Access Management (IAM) is reduced to an auditing task for the IT department. Joiners movers and leavers are maintained by the departments involved in staff management rather than IT, and audit trails show these changes being propagated through the managed resources.

Auditors will never again find accounts that should have been deactivated when the owner left the organisation, because the auditors are using the same identity source as the IAM process.

AMX as an Automated Process

AMX operates as a scheduled task, reporting its activity by email. Once AMX is released to production, checking email is the only administration task required of the AMX administrator. AMX maintains an audit log, keeps all transaction files and uses the email messages as a non-repudiative audit trail.

AMX can be used by an administrator who is:

• Cautious. AMX reports all updates by email but is configured to make no changes. The administrator uses the manual update files created by AMX to make the actual changes on the managed resources.
• Careful. The maximum change tripwires are configured to a very low level. When a tripwire is activated, the Load phase does not run, and the administrator checks the changes before committing any. if the problem is with the identities the data owners are asked to correct or confirm it before re-running the synchronizer.
• Confident. The tripwires are configured to a realistic level, AMX makes all the changes. The administrator responds to the occasional service desk ticket. The AMX undo feature isn’t used, the Authoritative Source of Identities is used to correct any errors.

Implement in Live

Implementation of AMX is quick and efficient because no development environment is required, AMX has been designed to be implemented straight into live. The features that allow this to be done are:

• The AMX toolset includes identity source and managed resource surveys. The surveys allow an in-depth review of the systems that AMX will manage.
• Other AMX tools check for unused accounts, the matching between accounts and their owners, separation of duties and key responsibilities for roles to setup Role Based Access Control.
• A global setting configures email, so that the live email system can be used during development, all mail is sent to the AMX implementers and nothing is sent to the wider audience until the system is released to production.
• During implementation the AMX synchronizer is configured to run in simulation mode so that all changes to the managed resources can be reviewed but the managed resources themselves are never updated. The synchronizer creates batch update files for most systems and these can be used to help cleanup the managed resources.

The benefits of implementing in live are:

• No test environment is necessary. Even with Virtual Machines test environments are expensive to run and maintain.
• The coverage of test data is a non issue.
• Issues with firewalls and network connectivity are found early in the implementation process. These issues often have the longest times to resolve and are a major source of delays to a conventional IAM project.
• There are no surprises when the system is released to production. The first run should be a no-op. More complete details of implementing AMX are described in the document AMX Implementation.

Next Page