I last saw the Microsoft Identity Integration Server (MIIS) product in my days at ICL, when it existed as a product called Zoomit Via. Since then, Microsoft has bought the rights to the metadirectory services technology and rewritten the product in various forms with MIIS 2003 being the latest incarnation, implemented as a Microsoft .NET application over SQL Server.

A couple of weeks back, I attended a one-day event, hosted by Microsoft, during which John Craddock and Sally Storey from Kimberry Associates presented on stretching directory boundaries: cross platform identity management, authentication and security(if the names sound familiar, then it’s probably from their Active Directory Forestry, Investigating and Managing Objects and Attributes for Windows 2000 and Windows Server 2003 book). A few months previously I had also attended an introduction to identity management with MIIS 2003 session at Microsoft’s IT Forum Highlights event and so here’s a synopsis of what I’ve learnt about MIIS.

A few years back, the goal for many organisations was a single directory for the entire organisation. Nowadays it is appreciated that there will generally be a number of applications/directories in a heterogeneous infrastructure and that the answer is not to replace them all with a single directory, but to aggregate information via a metadirectory, brokering identity data, facilitating convergence and enforcing data integrity based on business rules.

Whilst identity management is often sold as a security solution it actually offers much more, enhancing user experience, business efficiency and business agility. A badly-implemented identity management solution can actually weaken security, but most of all, poor identity management costs money.

Identity management encompasses:

• Directory services – repositories for storing and managing accounts, identity information and security credentials.
• Access management – the process of authenticating credentials and controlling access to networked resources based on trust and identity.
• Lifecycle management – the processes used to create and delete accounts, manage account and entitlement changes, and to track policy compliance.

On its own, MIIS is simply a data engine. It imports data, creates a consolidated view of that data, and exports data. But what it also does is to facilitate application of business rules to create an identity management solution with typical scenarios for an MIIS implementation being:

• Provisioning/deprovisioning accounts (also known as “hire and fire”) – enabling new users to immediately become productive with access to all relevant applications and services.
• Identity joining – facilitating attribute flow between connected directories, integrating data to provide a single view of a user’s identity, whilst respecting authority.

It’s important to stress that if an IT department goes out and implements a metadirectory on its own, the project is extremely likely to fail. Business logic needs to be applied. Decisions need to be made about who which systems are authoritative for which data. It seems logical that the human resources department will need to be involved in a hire/fire scenario, but that the facilities management function would be best placed to update telephone numbers. Meanwhile, IT need to be involved in providing access to corporate applications such as e-mail and intranet access, but a local department (e.g. finance) might administer local line of business applications. There may be a requirement to consider precedence – e.g. human resources may enter initial contact details for a user and these may be authoritative until the facilities management group have set up a phone extension and updated the contact details, at which time the as facilities management system becomes authoritative. On top of this, change control is required to close the loop between technology and process. Whatever the organisation, and however small, a metadirectory implementation should start out as a pen and paper exercise.

MIIS consists of a number of management agents which connect directory-enabled applications to an area known as connector space, which is effectively a series of database tables, to which filters are applied to specify rules for data translation. Connector space is synchronised with the metaverse – a logical, consolidated representation of all resources within the organisation.

The term management agent is actually a throwback to Zoomit Via – in fact, one of the advantages of MIIS is that no agents are deployed to connected directories. Instead, the management agents reside on the MIIS server, making native calls into a connected directory (actually, connected directory is a misnomer – connected directories do not have to be directories and there are many management agents for a variety of products). At the time of writing, management agents are available for:

• Network operating systems and directory services:
• Microsoft Windows NT.
• Active Directory.
• Active Directory Application Mode (ADAM).
• IBM Directory Server.
• Novell eDirectory.
• SunONE/iPlanet Directory.
• X.500 systems.
• Other metadirectory products.
• E-mail:
• Lotus Notes and Domino.
• Microsoft Exchange Server 5.5.
• Application:
• Telephone switches.XML- and DSML-based systems.
• Application (via flat file import/export, or connection to the underlying database):
• PeopleSoft.
• SAP.
• ERP.
• Database:
• Microsoft SQL Server.
• Oracle.
• Informix.
• dBase.
• IBM DB2.
• File-based:
• DSML v2.
• LDIF.
• CSV (delimited, fixed width, attribute value pairs).

In addition, MIIS 2003 service pack 1 provides an MIIS software development kit (SDK) which allows the creation of custom management agents.

MIIS represents all data as objects with a named set of attributes storing the data values. Each object is analogous to a row in a database with the attributes representing the columns. Values within one or a combination of objects (which have to be unique and immutable) are defined as an anchor, assigned a GUID and used to track the object.

Projection refers to the process of importing an object from a connected directory and creating an equivalent object in the metaverse. Where an object already exists in the metaverse, the transaction is a join. Provision is the reverse transaction – exporting from the metaverse to an connected directory via a management agent; however, management agents do not map data sources directly in and out of the metaverse and each object is staged within the connector space. The connector space object is then synchronised with its associated metaverse object.

MIIS is configured using the Identity Manager tool, which has five views:

• Operations – for defining and performing run profile operations.
• Management agents – for configuring management agents.
• Metaverse designer – used to define the metaverse schema.
• Metaverse search – a search function for the metaverse.
• Joiner – used for resolving issues when mapping objects to one another.

With the exception of time and date information, object attributes are only updated in the connector space, with rules being used to define precedence and also any conversion on the data (e.g. generating a display name from a given name, initials and a family name). Rules placement needs to be considered, with inbound being a good location if the altered attributes are to be exported to many systems (known as import attribute flow) whereas outbound may be more appropriate if data is merged and only pushed out to one connected directory (known as export attribute flow).

The connector space model provides two main advantages:

• Connector space provides a unified method of viewing data from disparate data sources, but it is not necessary for all of the attributes associated with each object in each of the connected directories to be mirrored in connector space (it is possible to view the connector space data using SQL Server Enterprise Manager – the MicrosoftIdentityIntegrationServer database has a table called MMS_Connector_Space).
• Synchronisation can be previewed before it is implemented.

Run profiles are actions to move replicated objects to/from connected directories or the metaverse via the connector space, with import/export run profiles referring to transactions between connector space and a connected directory and synchronisation run profiles referring to the synchronisation of objects between connector space and the metaverse. These run profiles are part of the management agent configuration, specifying which object types and attributes are to be imported, exported or synchronised. It is important to note that the work of the management agent is triggered by a run profile and that MIIS is not event-driven. This is because not all directories can generate events; however run profiles can be scheduled, or code could be provided which would trap an event and trigger a run profile.

A management agent’s schema reflects the objects and attributes in the connected directory’s schema and if the source schema is changed, the management agent’s schema may be refreshed. The configuration of a management agent can be saved as XML). After a management agent has been created and an import taken place, the objects in connector space are referred to as disconnector objects (i.e. they are not yet connected to objects in the metaverse). The metaverse schema is completely isolated from the schema of a management agent.

A projection rule maps a connector space object type to a metaverse object type and only one rule may be configured per connector space object type. During the configuration of the management agent, attribute flow must be declared – i.e. which attributes are mapped, in which direction, and any name transformations that are required.

If join rules are defined, they are always run before any projection rules. Join rules can specify multiple conditions (based on connector space and metaverse attributes) and if these are met, the connector space and metaverse objects are joined and attribute flow initiated. If there is more than one import flow, then the metaverse designer can be used to set attribute flow precedence. If the rules do not result in a unique join, then the object remains a disconnector and the joiner must be used to resolve the issue (or the design revisited as it is possible that the rules are not appropriate). Note that joining to a non-indexed attribute can result in performance issues but these are easily resolved by setting the appropriate attributes to indexed within the metaverse designer.

For complex rules, rules extension functionality allows scripting in any .NET language, to provide advanced mappings as a method of manipulating data as the management agent synchronises objects between connector space and the metaverse. Implemented as a .NET framework assembly in the form of a dynamic link library (.DLL) file, this contains routines that are called as the management agent processes its rules.

Outbound data flow is similar to inbound, except that there is one golden rule to remember – MIIS cannot confirm an exported change until it has been imported again from the connected directory. Therefore an import should always be performed directly after an export to confirm the status of the connected directory.

Object deletion rules are specified for each object class to define what happens to the metaverse object when it is deleted from a connected directory, using either a rules extension, or options to remove the object when it is deleted from either the last connected directory or through a specified management agent. Deprovisioning is supported within the management agent configuration, with options for:

• Making the object a disconnector.
• Making the object an explicit disconnector (i.e. do not reconnect).
• Delete the object at the time of the next export.
• Rules extension.

Unfortunately, provisioning using MIIS still requires coding – although the product is maturing and codeless provisioning is expected to be included in the next release. One method of automating directory updates is to save rules after creation (e.g. as VBScript) and to schedule execution of the script.

Password synchronisation is supported for any connected directory with a password application programming interface (API). Many management agents have this functionality built in and support real-time password synchronisation, via the password change notification service. This requires an agent to trap plain-text password entry before encryption (unless reversible encryption is supported – which it generally won’t be), but MIIS can detect changes in Active Directory. Changes are queued in case MIIS is offline at the time of the change, with the management agent encrypting the password details using a key that is only known by MIIS. There is also a web-based self-service password management application within MIIS, which will take password changes and replicate them out to all connected systems.

MIIS is available in two product editions – MIIS 2003 Enterprise Edition (with the complete set of management agents and features), and the cut-down Identity Integration Feature Pack for Active Directory (AD), which includes AD and Active Directory Application Mode (ADAM) management agents, supports Exchange GAL synchronisation and is a free download from the Microsoft website, although it does require the use of Windows Server 2003 Enterprise Edition.

MIIS 2003 service pack 1 extended the reach of MIIS, bringing extra functionality in the shape of additional management agents, password synchronisation with the Windows desktop and improved provisioning capabilities. It also allows the use of SQL Server 2000 Standard Edition (reducing cost as there is no longer a dependency on SQL Server 2000 Enterprise Edition). More management agents will be released over time (SAP and PeopleSoft management agents are expected next) and future enhancements will be aimed at lowering the cost and risks of directory management.

There is also an MIIS resource toolkit 2.0, which adds functionality and flexibility for remote administration and configuration of MIIS.

So what about the future for MIIS? One former colleague, who knows more about identity management than I do, suggested that the product is already pretty capable, and that it is only its Microsoft “badge” which is preventing it from being taken seriously. Meanwhile Microsoft is busy preparing the next version of MIIS (codenamed Gemini and due for a 2006 release), aiming to catch up with the competition (rumour has it that the following version will be Apollo, just as in the Russian and American space race of the 1950s, ’60s and ’70s).

MIIS Gemini is intended to lower the costs and risks associated with identity management and is currently addressing:

• Codeless provisioning.
• Richer logging/auditing.
• Workflow for provisioning and self-service (using the Windows Orchestration Engine from Windows Server 2003 Release 2).
• Improved support for clustering (failover is supported now, but the workload stops – e.g. an in-progress import operation will not complete).
• Computed attributes (dynamic groups).
• Cross-forest group management.
• Entitlement reporting.
• Capacity planning documentation.
• Scalability improvements.
• Additional management agents for UNIX systems, OpenLDAP and generic LDAP (whilst most vendors support LDAP, some have their own extensions and a generic LDAP management agent will be provided).