Directory Infrastructure Roadmap
Overcoming Fragmented Identities Roadmap to a Reliable Directory
Infrastructure
Thorsten Butschke & Dr. Martin Dehn
KOGIT Enterprise Identity Management GmbH
Agenda
History of Directory Services
From X.500 to LDAP
Meta-Directory Approach
Virtual-Directory Approach
Virtual Directory Use Cases
Application Integration
Simple Schema Mappings
Building a Virtual Tree
Virtualization of Multiple Identity Sources
Adding Intelligence Using Business Logic
Maximizing Directory Infrastructure Performance
Enhancing Reliability
Vendor Overview
From X.500 to LDAP
A short introduction to directory services
in IT infrastructures
Promises
&
Reality
Meta-Directory Approach
Administrator
User
Metadirectory Service
UNIX
NIS
SAP
/HR
Lotus
Notes
Microsoft
ADS
UNIX
Administrator
SAP/HR
Administrator
Notes
Administrator
W2K
Administrator
The Objectclass Issue
• there is no standard definition for at least
person/user objects in LDAP directories
• there are implementation-specific classes like
inetOrgPerson (Netscape, Sun, OpenLDAP)
ePerson (IBM), User (MS ActiveDirectory)
• how should LDAP clients be built to support
these variety?
• what if you deploy a new application which
needs a type of object class not defined in
your enterprise directory?
The Namespace Issue
• various namespaces are possible in directories
• there is no standard for the RDN (identifier) of
user objects
AGAIN
• how should LDAP clients be built to support
these variety?
• what if you deploy a new application which
needs a distinct RDN not defined in your
enterprise directory?
Overcome the Disadvantages of a
Meta Directory with a Virtual Directory
Meta Directory
• same data stored twice
• synchronizations need a lot of time
– could take longer than 24 hours in large environments
• e. g. a HR synchronization
– access to a snapshot of the past instead of live access to
the data
Virtual Directory
• data stored only once
• live (real time) access to the data
• Prepare the object class and RDN you need!
Virtual Directory Approach
Clients
Optional LDAP Directory
Virtual Directory
Connector
Connectors
JDBC / ODBC
JNDI / ADSI / OLEDB
J2EE CA
Applications
Databases
Virtual Directory
Workflow
Agenda
History of Directory Services
Meta-Directory Approach
Virtual-Directory Approach
Virtual Directory Use Cases
Application Integration
Simple Schema Mappings
Building a Virtual Tree
Virtualization of Multiple Identity Sources
Adding Intelligence Using Business Logic
Maximizing Directory Infrastructure Performance
Enhancing Reliability
Vendor Overview
Intranet Authentification (1)
Task Definition
• the Intranet is a web portal
• authentification is done via an access manager
• the access manager stores the users in its own
LDAP repository with its own LDAP schema
Intranet Authentification (2)
Request
Content
Content
Portal
Request
Authentification
Create
Create
Update
Update
Delete
Delete
User
VDS
Company
Directory
Decision
Accessmanager
Intranet Authentification (3)
Problems
• the class name of the user object is different in the
access manager and the company directory
• the access manager schema contains attributes, that
do not exist or have a different name in the
company directory
• typical problems if you would like to change the schema
of the company directory
– problems with existing installation and existing client
applications
– a lot of organizational discussions
Intranet Authentification (4)
Implementation (1)
• configure the access manager to use VDS as directory
• create static content inside the directory
• extract company directory schema
• map user objects from the company directory to the
user object of the access manager directory schema
• map attribute names
• add
– static attributes that do not exist in the company directory
– dynamic attributes and values via scripts
• link objectclass in the virtual tree
Intranet Authentification (5)
Implementation (2)
Intranet Authentification (6)
Benefits
• no changes of organizational processes in the
company directory
• no additional user management processes in
the access manager LDAP directory
• fast implementation and configuration
– only basic scripting skills necessary
• reuse of existing user data
– no synchronization
Intranet Authorization (1)
Task Definition
• the intranet is a web portal
• the authorization is done via group
memberships in a directory
• there are several user directories
– in different branches
– from different vendors
Intranet Authorization (2)
Problems
• the portal software could only be connected to
a single directory
• each directory uses its own schema
– objects
• user (AD)
• inetOrgPerson (eDirectory, OpenLDAP)
– attributes
• memberOf (AD)
• groupOfNames (eDirectory)
• posixGroup (OpenLDAP)
Intranet Authorization (3)
Implementation
• decide which schema you want to configure to the
portal software (AD in our case)
• map the objectnames of all directories to the AD
objectname
• map the attributes
• use scripts for complex mappings
– in OpenLDAP the group membership is a name, in AD its a
DN
• link all directories into the virtual tree
Intranet Authorization (4)
• OpenLDAP
– posixGroup=Marketing
• AD:
– group=cn=Marketing,ou=groups,dc=mycompany
• Script:
OpenLDAP->group=
„cn= “ + [Possixgroup] + „,ou=groups,dc=mycompany“
Intranet Authorization (5)
dc=extern,dc=mycompany
IS
Interception Script
Virtual
views
ou=de
- user
- group
IS
IS
ou=dk
- user
- group
Schema
mappings
IS
IS
ou=cz
- user
- group
IS
IS
ou=sk
- user
- group
IS
IS
inetOrgPerson
renamed in
user
inetOrgPerson
renamed in
user
groupOfNames
renamed in
group
possixGroup
renamed in
group
ou=uk
- user
- group
IS
IS
ou=nl
- user
- group
Backends
AD
AD
eDirectory
Open LDAP
AD
AD
DE
DK
CZ
SK
UK
NL
IS
IS
Intranet Authorization (5)
Benefits
• no changes of organizational processes in the
company directory
• fast implementation and configuration
– only basic scripting skills necessary
• reuse of existing user data
– no synchronization, no organizational changes
• products of different vendors can coexist
– no migration necessary
Global Directory (1)
Task Definition
• a global directory should be established
• data already available in various directories
– databases
– directories
• flat file is also a possible form of directory
– e. g. HR export
Global Directory (2)
LDAP
Oracle
MySql
Global Directory (3)
Problems
• access to the data via different technologies
(LDAP, CSV, SQL) using the LDAP protocol
• consolidation of user data in one object could
be done easily in the VDS if UID‘s are the
same in each source
• a synchronization tool is necessary if the UID‘s
have a different syntax in each source
Global Directory (4)
Implementation (1)
• virtualization of flat files and databases
• link objects based on one attribute
Global Directory (5)
Link Based on Attribute
LDAP View
VDS View
Oracle View
LDAP:mail = Oracle:mail
MySQL View
LDAP:mail = MySQL:mail
Linked based on attribute „mail“
Global Directory (6)
Identity View
Global Directory (7)
Implementation (2)
• virtualization of flat files and databases
• create a database with an entry for each user
– unique id
– links to each record of the person in the various
sources
• create an attribute or transform an existing
attribute to match the unique id from the
database in the virtual views of the sources
Global Directory (8)
Creating a Unique ID
Global Directory (9)
Links to Sources
Global Directory (10)
Synchronization
Global Directory (11)
Identity View
Global Directory (12)
Benefits
• access via one single protocol
• consolidation of user data in one object
• synchronization only needs to synchronize the
link, not the data
Agenda
History of Directory Services
Meta-Directory Approach
Virtual-Directory Approach
Virtual Directory Use Cases
Application Integration
Simple Schema Mappings
Building a Virtual Tree
Virtualization of Multiple Identity Sources
Adding Intelligence Using Business Logic
Maximizing Directory Infrastructure Performance
Enhancing Reliability
Vendor Overview
Maximizing Directory Infrastructure
Performance
• use connection pools
– connections to the sources (back-end)
– connections form the client to the server (front-end)
• use caches
– query & entry caches
– memory cache
– persistent cache (save data on the hard disk)
– cache refresh
• triggered by a scheduler
• triggered by a message bus
Enhancing Reliability
Through LDAP Routers
• provide failover functionality
• provide load balancing functionality
• available as
– software
– hardware
LDAP Routing and Caching
VDS VM Ware Image
Router
3
8
Router
Instance
Access Manager
Cache
4
AD1
2
5
3
1
6
9
8
Router
Instance
JMS
7
AD
3
User
VDS
8
Router
Instance
10
11
NDS
3
8
Poral
Router
Instance
OpenLDAP
AD2
Agenda
History of Directory Services
Meta-Directory Approach
Virtual-Directory Approach
Virtual Directory Use Cases
Application Integration
Simple Schema Mappings
Building a Virtual Tree
Virtualization of Multiple Identity Sources
Adding Intelligence Using Business Logic
Maximizing Directory Infrastructure Performance
Enhancing Reliability
Vendor Overview
MaXware Virtual Directory
supported protocols:
•
LDAP, DSMLv2, SPML, transformation API for inbound protocols
supported back-ends:
•
JNDI, JDBC, Java Adapter API
caches:
•
in memory cache
scripting languages:
•
Java (adapter), XML (configuration)
supported platforms:
•
Java application
other features
•
software load balancing
•
GUI oriented
Oracle Virtual Directory
(Former „Octet String“)
supported protocols:
•
LDAP, SQL, DSML, XSLT
supported back-ends:
•
LDAP, NT, database, local store, Java API for adapters
persistence:
•
local data store
caches:
•
in memory cache
scripting languages:
•
Python (transformations) and Java (adapter, routing)
supported platforms:
•
Java Application
Other features:
•
routing rules
•
load balancing
•
code oriented (embedded in ECLIPSE)
Symlabs
supported protocols:
•
LDAP, SOAP, Radius, SNMP, SIP
supported back-ends:
•
LDAP, SQL, Radius, SNMP, SIP, SOAP
persistent:
•
memory
•
database
scripting languages:
•
proprietary scripting language (DirectoryScript)
supported platforms:
•
AIX, HP/UX, Linux, Solaris >8 (Sparc & Intel x86), Windows
other features
•
written in C
Radiant Logic
supported protocols:
•
LDAP, DSML 2.0, HTTP/ SOAP, SAML 1.1, and SPML 1.1
supported back-ends:
•
LDAP, ADSI, and JDBC. Java API for custom connectors
persistent:
•
memory
•
local store
caches:
•
query & entry cache
•
persistence cache
•
memory cache
scripting languages:
•
Dynamic Java (scripts), Java (adapter)
supported platforms:
Java application
other features:
•
optional Synchronization Services
•
software LDAP router and load balancer
•
GUI oriented
Penrose (Open Source)
•
•
•
•
reuses the Apache Directory Server
worth a look
excellent use cases documentation
reuse of ECLIPSE
Questions ?