Upstream Provisioning For A Multi-Directory Identity Repository

Upstream provisioning for a
multi-directory identity
repository
A Bull Evidian white paper
Upstream provisioning
By Philippe Franois
Architect
Version 1.0
Contents
At the heart of identity and access

management
Examples of technical architectures
An example of use
An integrated upstream provisioning
solution
2006 Evidian
The information in this document reflects Evidian's opinion on the subjects under discussion at the time of publication.
Due to the constantly changing market conditions to which Evidian must adapt, they cannot be taken as a
commitment on Evidian's part and their accuracy is not guaranteed beyond the date of publication.
This document is supplied for information only. EVIDIAN MAKES NO EXPRESS OR IMPLIED GUARANTEE IN THIS
DOCUMENT.
We acknowledge the rights of the proprietors of the trademarks mentioned in this publication.
Table of contents
At the heart of identity and access management ......... 4
Building an identity repository .........................5
Main functions of upstream provisioning .................7
Synchronization functions .............................. 7
Activating downstream functions ........................ 7
Logging ................................................ 7
Synchronization policy ..................................7

Repositories ............................................8
A multi-level organization ..............................9
Updating target repositories ...........................10
Rules typology .........................................10
Other rules ........................................... 11
Examples of technical architectures ................... 12

An example of use ..................................... 16
Creating users .........................................16
Creating global groups .................................17
Creating local Active Directory groups in the Mainframe
repository .............................................17
Creating group membership relations ....................17
Defining and applying a group-based security policy ....17
Applications which use Active Directory ................18
No change of directory architecture ....................18
A solution which adapts to organizational constraints ..18
An integrated upstream provisioning solution .......... 19

Upstream provisioning ................................. 20
39 A2 72LT Rev00
At the heart of identity and access management

Building an identity repository is at the heart of identity and access management. In
fact, no matter the quality of an access security policy, no matter the effectiveness of
its implementation, and no matter how refined the reporting tools are, if the userdefining data is not reliable, the entire structure is bound to collapse.
A number of obstacles may be encountered while building such a repository, like using
a too complex model, a purely technical approach or even a mixture of user-defining
data and rights-defining data. Before embarking on such a project, it is important to
use an approach which will enable you to define simple, robust and effective models
and processes during its implementation.
Why a coherent repository is essential
1
Evidian recommends the use of a model which allows you to separate identity data
from access-rights-defining data and the procedure used to build them.
Figure 1. From authoritative data to assigned data

Identity-defining data is referred to as authoritative data, while access-rights-defining
data is part of assigned data.
Evidian recommends V.I.M. (Virtual Identity Manager). For more information, you
may download the white paper from http://www.evidian.com/fr/security/im/wpvim.php?c=wprefid
39 A2 72LT Rev00
Authoritative
data
Assigned
data
Definition
Data which defines
identity in the broad
sense of the user
Data which defines user
access rights on target
systems and applications
Examples
Surname, first name, company
identifier, organization, job, position
in the company, site, office, phone
number, etc.
Application logins and passwords,
privileges, timetable for use, LDAP
group membership, etc.
Table 2. Authoritative and assigned data

A users assigned data is generally obtained by applying security policy rules to the
authoritative data of the same user. For example, a sales engineer (authoritative data)
will have a login and a password (assigned data) to access the application meant for
salespersons (security policy).
Located at the beginning of the process, authoritative data is, therefore, at the heart of
identity and access management procedures. Any creation, modification or deletion of
authoritative data may have an immediate impact on assigned data.
Building an identity repository

There are several ways of building an identity repository for an organization.
For example, the already existing identity data management system may be simple
enough for an identity management workflow to supply data to a single directory
shared by all the organizations (see the white paper on
http://www.evidian.com/fr/security/im/wp-workflow.php?c=wprefid).
But in most cases, the organizations have deployed several directories, which collect
identity data in formats that are often incompatible and difficult to share. Moreover,
they are managed by groups of dedicated administrators, who apply their own data
model. For example, within the human resources management systems,
administrators are tasked with managing users names, jobs and the attributes relating
to their organizations; in the PBX database, administrators are in charge of managing
telephone numbers; in LDAP directories, administrators must manage users' e-mail
addresses, etc.
39 A2 72LT Rev00
This incoherent situation results in high non-quality costs:
A loss of productivity for the IT teams, which must manage the same data in
several places and in several formats
Uncontrolled and attack-prone identities

Proliferation of unreliable identities which complicates authorization management
and control
To solve these problems, Evidian has introduced an upstream provisioning function
making it possible to build a source of identity in a single repository.
Unlike standard provisioning (or even downstream provisioning), upstream
provisioning allows you to create a reliable and coherent identity repository. This
module interacts with other functions of an identity and access management solution:
Policy Manager uses the repository

thus created to initialize access
rights creation operations based on
the security policy.
Workflow completes the

consolidation mechanisms by
implementing validation procedures
for the most critical applications.
Figure 2.
Provisioning (or even downstream provisioning) uses identity data to create,

modify or delete access rights in target systems and applications.
Enterprise SSO uses the data to validate a users identity.
39 A2 72LT Rev00
Main functions of upstream provisioning

Upstream provisioning applies the principles of synchronization, coupled with the
interface functions of the identity and access management modules.
Synchronization functions
Defining and applying a multi-repository synchronization policy.
Activating downstream functions

Activating rights update operations through professional rule mechanisms within the
policy server. These operations may lead to the activation of downstream provisioning
processes on the target applications in the information system.
Logging
Logging identity management operations for analysis and reporting.
Synchronization policy
Generally, the synchronization policys application range must be restricted to userdefining authoritative data.
This policy will allow the application of the following rules:
Rules for consolidating an identity from several recordings; identity-related data

may be located in different repositories.
Rules for reconciliation in case of data inconsistency

Rules for creating or deleting a users data
Synchronization may take place in batches or continuously; in any case, it is only
based on the latest modifications.
Separating authoritative
identity data from
assigned data
For the existing solution to be permanently maintainable, it is very important to

separate authoritative identity data from assigned data, and to apply synchronization
to authoritative data only. For instance, although the reconciliation mechanisms are
the same for both data families, they are not subject to the same rules:
The reconciliation rules for authoritative data depend on the level of trust or
reliability associated with each set of data. If a users telephone number is different
in two directories, you only need to define a rule for determining the reference
data.
39 A2 72LT Rev00
The reconciliation rules for assigned data (data generally provisioned on target
systems) compare the reality of data on a target system with the value that it
should have according to the access security policy. They must, therefore,
interface with the policy engine. The result of a reconciliation in favor of the actual
data may be a change in the access security policy.
Repositories
Upstream provisioning works on different types of repositories and data.
The most common technologies are LDAP directories, relational databases or even
flat files (csv, ldif, etc.).
Furthermore, it is possible to
find interfaces to the Human
Resources (HR) application
databases. In fact, the HR
databases may contain
information required to
define users, or may even
initiate user-identity creation
or deletion events within the
information system.
Figure 3.
The repositories to be taken

into account
If the global identity and access management solution has its own identity base,
upstream provisioning must naturally integrate this base into the synchronization
mechanisms.
A special case: target application and system repositories
In some cases, the internal repository of the application itself may contain some
identity data. Upstream provisioning may then use the technical mechanisms, such as
agents and connectors, generally used by downstream provisioning to integrate the
target data into the identity repository.
In fact, these connectors and agents use public and regular interfaces (API) supplied
by the application provider. Instead of giving direct access to the application's internal
repository, the use of these public APIs enhances the stability of the installed solution.
39 A2 72LT Rev00
A multi-level organization
To create consistent sets of source data, it is possible to associate a set of
associated source repositories with master source repositories (through joint
mechanisms). A master source contains the record to which the associated source
data may be assigned. Deleting a master record will completely erase the record,
whereas deleting an associated record will be considered as absence of data to be
processed, if necessary, using the synchronization rules.
This first aggregation level is used to organize the data so as to have the same view
of data from different sources. In this case, the synchronization rules may be top-level
rules and may be applied to all the accessible data.
Figure 4. Joining operations
39 A2 72LT Rev00
Updating target repositories

You can use synchronization rules to create a single, centralized repository, which is
actually the main objective of the operation.
You can also use them
to update a group of
target repositories and
thus create a coherent
identity on a distributed
set of repositories.
This distribution of
identity enables you to
simply solve problems
of directory architecture,
network flow
optimization or even
data homogenization in
different and/or
incompatible
repositories.
Figure 5. Target repositories
Rules typology
Quite paradoxically, you can implement upstream provisioning just using four basic
rules:
Join
This rule allows you to base the recording of an associated source on one or more
master sources.
Attribute Mapping
You can use this rule to define a correspondence relation between attributes from
different sources. This relation is well-ordered and leads to an attribute update. This
update can also result from the application of an intermediate transformation function.
Finally, this correspondence relation enables you to update multi-value attributes from
several sources. A simple example of multi-value attribute is the e-mail address
attribute: in fact, an employee can have several e-mail addresses within an
organization: [email protected], [email protected],
[email protected], [email protected], First name/
Name/Org/Country.... Each e-mail address is available in a specific directory. They
can be consolidated within a single e-mail address repository through a multi-value
attribute.
39 A2 72LT Rev00
10
Creation
If a user exists in a master repository but not in an associated repository, you can
use this rule to create all the attributes associated with this user, in the associated
repository.
Deletion
This rule automatically deletes a user's attributes from an associated repository if
this user has been deleted from the master repository.
Other rules
You can work out other rules for creating attributes in repositories. These other rules
generally concern the creation of assigned data. Therefore, they are naturally
integrated into the policy manager, from which you can create and provision the user
access rights on the target applications and systems, using the identity data and in
keeping with the policy.
39 A2 72LT Rev00
11
Examples of technical architectures

Case 1: creating a reference LDAP directory
In this case, you can create and consistently maintain the reference identity LDAP
directory from different upstream source categories (SQL database, CSV files, other
LDAP sources, etc.). These upstream sources are generally under the responsibility of
a partner company official, or are part of an ERP.
The data inside the directory results from the aggregation of upstream data
consolidated during joining operations.
Figure 6.
Creating a reference LDAP directory
You can thus create a repository which will enable you, for instance, to define an
LDAP directory for Enterprise SSO.
39 A2 72LT Rev00
12
Case 2: creating an identity repository using an identity and access management
solutions database
In this case, upstream provisioning allows you to fill and consistently maintain the
identity base with an identity and access management tool. In general, this base is
managed by an identity management module and is used by the downstream
provisioning modules. This base can be called a security repository. It can contain all
or only a subset of user data (cf. the 3 cases below).
Figure 7.
39 A2 72LT Rev00
Using an identity and access management solutions

database as a single identity repository
13
Case 3: using the LDAP directory as identity repository
This is an extension of the previous case. This is the case where the identity and
access management solution is using an external LDAP directory as identity
repository. The security repository may then contain, for instance, the downstream
provisioning data or even additional identity data.
Figure 8.
39 A2 72LT Rev00
Using the LDAP directory as single identity

repository
14
Case 4: synchronizing with target application data
This is the most comprehensive case for which some user data in the target
applications internal repositories may be used as authoritative data sources.
It is then possible to use agents and connectors to synchronize the target applications
data with the other different authoritative sources.
Figure 9.
39 A2 72LT Rev00
Synchronizing with target-application data
15
An example of use
The following example of use is a real case of implementation with Evidians
AccessMaster. It uses upstream-provisioning possibilities as well LDAP / securityrepository coupling.
Based on the technical characteristics of upstream provisioning, it is possible to
describe the following case of use:
Users are defined in 3 source databases:
The Mainframe repository, which contains an employees surname, first name and
login
The HR repository, which contains additional data such as e-mail address, location,
telephone number, and fax number
The exception CSV files, which contain the list of a users e-mail addresses. This
list contains the log of a users e-mail addresses following different acquisitions,
consolidations and domain changes.
2
The main target database is Active Directory, which contains the list of local Active
Directory groups.
The master repository is the mainframe repository. The presence or absence of a user
in this repository determines the presence or absence of said user in Active Directory.
Data update rules are based on 4 types of flows.
Creating users
Users are created in Active Directory with all their attributes. The first name, surname
and login come from the mainframe repository, and additional data such as e-mail
addresses, the location or telephone number come from the HR database. If a user
has several e-mail addresses, the multi-value field e-mail address in Active Directory
retrieves all the addresses.
Mainframe
HR DB
Exceptions
ActiveDirectory
Figure 10. Synchronizing with target-application data
In this case of use, the notions of local groups and global groups must simply be
understood as follows:
- A local group is a group defined in Active Directory.
- A global group is a group defined in the mainframe.
39 A2 72LT Rev00
16
Creating global groups

The organizations groups, which exist in the Mainframe repository, are created in
Active Directory. These groups are used to define a set of associated application
resources.
Creating local Active Directory groups in the Mainframe

repository
To associate a global group with a local Active Directory group, the mainframe
administrator needs to retrieve the local Active Directory groups on the mainframe.
These Active Directory groups must, therefore, be copied to the mainframe.
Mainframe
HR DB
Exceptions
ActiveDirectory
Figure 11. Synchronizing with target-application data
Creating group membership relations

Relations of users' membership of local Active Directory groups and global groups, as
well as of global groups membership of local Active Directory groups, are defined in
the mainframe repository by administrators. These relations are copied to
Active Directory to allow the control of accesses to the corporate resources at the
Windows level.
Defining and applying a group-based security policy

Although the most comprehensive user definition is located in Active Directory, the
management of global groups is defined in the mainframe. Membership relations are
defined by the mainframe administrator. This policy is then copied" to Active
Directory.
The mainframe repository contains a subset of attributes used to perform this group
management.
39 A2 72LT Rev00
17
Applications which use Active Directory

Some infrastructure applications may natively use the data available in Active
Directory.
Active Directory is, thus, used to manage access to shared disk and printer resources.
Moreover, the White Page application uses the data defined in this directory to publish
users public information.
An Enterprise SSO solution may also use this user database to control access to
target applications.
No change of directory architecture

In this case of use, the organization did not wish to change the Active Directory
architecture. The security repository of the identity and access management solution
was used to extend the architecture outside Active Directory (cf. case 3 of technical
examples).
A solution which adapts to organizational constraints

An upstream provisioning solution adapts to technical and organizational constraints.
For example, a group-based security policy can be applied to any repository in the
company. It only needs to contain the authoritative information required to define and
apply this policy.
Update flows are multi-directional; therefore, each repository may be both client and
information-provider-based, depending on the authoritative character of the data it
contains.
39 A2 72LT Rev00
18
An integrated upstream provisioning solution

There are two ways of using an identity-repository-creation solution: either
independently and desynchronized from other identity and access management
functions, or by integrating it into a complete solution. This second option allows you
to immediately take account of the general problems.
Validation workflow
For example, the authorization validation process applies both to identity creation, to
validate the information, and data creation on target applications, for instance, in order
to validate the creation of accounts on sensitive applications. It is a transversal
process which handles upstream provisioning data, which is the creation of the identity
repository, and downstream provisioning.
Managing access-right policies
Updating access rights by activating professional rules in the policy server is one of
the key elements of the identity repository. In fact, beyond providing white pages, one
of the main objectives of an identity repository is to serve as support for all the access
and authentication control mechanisms.
Thanks to the ability to initiate provisioning operations in line with the security policy,
the close collaboration with the authorization management workflow mechanisms, the
provisioning of secure SSO modules (E-SSO, Web SSO, SAML,), you can obtain
immediate cost-and-quality-of-service related return on investment.
Reports
The laws and regulations on identity management are getting increasingly stringent.
For some companies listed on the stock market, it is now a major obligation to provide
auditable reports on access-management policy and its implementation.
Identity and user rights management reports are part of this obligation.
This problem of reporting is also a transversal problem which cuts across all the layers
of an identity and access management solution. To be valid, the trace of the
operations which led to the creation of an account must include at least the creation of
the user and his or her identity attributes (upstream provisioning), the different
validations, (workflow) and, finally, the creation of accounts (downstream
provisioning).
39 A2 72LT Rev00
19
Upstream provisioning is one of the key elements of an identity and access
management solution. It can be simply understood as the use of synchronization
mechanisms to create an identity repository into which items have been integrated
that are natively used to interface the modules of an identity and access management
solution.
Upstream
provisioning
Synchronization
Integration
It is this integration that will enable a complex organization to define and apply a
global identity and access management policy.
39 A2 72LT Rev00
20
For more information, please visit our site: www.evidian.com/

E-mail: [email protected]

Upstream Provisioning For A Multi-Directory Identity Repository

Uploaded by

Copyright:

Available Formats

Upstream Provisioning For A Multi-Directory Identity Repository

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Upstream Provisioning For A Multi-Directory Identity Repository

Uploaded by

Copyright:

Available Formats

Upstream provisioning for a

At the heart of identity and access

Examples of technical architectures

Synchronization policy ..................................7

Examples of technical architectures ................... 12

An integrated upstream provisioning solution .......... 19

At the heart of identity and access management

Figure 1. From authoritative data to assigned data

Table 2. Authoritative and assigned data

Building an identity repository

Uncontrolled and attack-prone identities

Policy Manager uses the repository

Workflow completes the

Provisioning (or even downstream provisioning) uses identity data to create,

Enterprise SSO uses the data to validate a users identity.

Main functions of upstream provisioning

Activating downstream functions

Rules for consolidating an identity from several recordings; identity-related data

Rules for reconciliation in case of data inconsistency

For the existing solution to be permanently maintainable, it is very important to

The repositories to be taken

Figure 4. Joining operations

Updating target repositories

Examples of technical architectures

Creating a reference LDAP directory

Using an identity and access management solutions

Using the LDAP directory as single identity

Synchronizing with target-application data

Figure 10. Synchronizing with target-application data

Creating global groups

Creating local Active Directory groups in the Mainframe

Figure 11. Synchronizing with target-application data

Creating group membership relations

Defining and applying a group-based security policy

Applications which use Active Directory

No change of directory architecture

A solution which adapts to organizational constraints

An integrated upstream provisioning solution

For more information, please visit our site: www.evidian.com/

You might also like