The document provides an overview of the technical architecture of OpenIAM, an identity and access management solution. The architecture includes key components like an enterprise service bus, business process engine, messaging, scripting, presentation tier, security architecture, and more. OpenIAM takes a service-oriented approach and exposes over 30 services through the ESB for features like user management, authorization, provisioning, and reporting.

1. OpenIAM
Identity
and
Access
Manager
Technical
Architecture
Overview
www.openiam.com

2. Overview ............................................................................................................................ 3
Architecture ....................................................................................................................... 3
Common Use Case Description ..................................................................................... 3
Identity and Access Middleware .................................................................................... 5
Enterprise Service Bus (ESB) .................................................................................... 5
Business Process Engine ........................................................................................... 6
Messaging .................................................................................................................. 6
Scripting ..................................................................................................................... 7
Presentation Tier ............................................................................................................ 7
Template Engine ........................................................................................................ 7
Extension Module ....................................................................................................... 8
Security Architecture ...................................................................................................... 8
Key Management ....................................................................................................... 9
Encryption and Hashing ............................................................................................. 9
Session Management ................................................................................................. 9
Secure Communication .............................................................................................. 9
Authentication .............................................................................................................. 10
Authorization Engine with high performance Cache .................................................... 10
Access Gateway .......................................................................................................... 10
User Search Engine ..................................................................................................... 11
Provisioning Engine and Connectors ........................................................................... 11
Audit ............................................................................................................................. 11
Reporting ..................................................................................................................... 12
Scheduler ..................................................................................................................... 12
High Availability ............................................................................................................ 13
Conclusion ....................................................................................................................... 13
www.openiam.com

3. Overview
Identity services are a critical part of an enterprise’s infrastructure. While options from
the current market leaders offer good solutions, their complexity, high cost of
implementation, and large number of failed projects make them ill-suited for
organizations that are outside of the Global 2000.
Over the last several years, OpenIAM has developed a unified IAM solution stack that
has been successfully deployed at customers of varying sizes ranging from mid to large-sized
organizations as well as external facing service providers supporting millions of
users.
OpenIAM takes a unique architectural approach to address the identity and access
management challenge. Unlike most existing solutions which have been clubbed
together from acquisitions and marketed as "best of breed", OpenIAM has been built
from the ground up on a Service Oriented Architecture (SOA) using well accepted
software components to create a solution that is highly scalable and easy to maintain.
This results in the following benefits:
• Faster Time to Market – Allows companies to rapidly respond to changing
business and regulatory needs
• Scalability – Scales from hundreds to millions of users
• Portability – Allows integration across technologies such as Java, .NET, PHP,
Groovy as well as across operating systems and repositories
• Simplified integration resulting from adherence to standards and a service-based
www.openiam.com
architecture
• Lower implementation and total cost of ownership
This document will provide an overview of the architecture found in the OpenIAM Identity
and Access Manager solution.
Architecture
The diagram below provides a high level conceptual architecture of the OpenIAM
Identity and Access Management stack and how it can fit into the enterprise. The
following sections describe the components of the architecture and the role they play in
the overall solution.
At the heart of the OpenIAM architecture is an Enterprise Service Bus (ESB). Over 30
services are exposed through the ESB and they represent the full range of functionality
supported by the product ranging from User Management, Audit, Policy Management
and Provisioning.
Common
Use
Case
Description

4. The following section describes a common use case seen in enterprises to better
visualize how the architecture maps to common activities.
Users are usually created from an authoritative source. Common examples of
authoritative sources include:
• Human Resources system such as PeopleSoft or SAP HR
• Existing user repositories such as LDAP or Active Directory
• User Registration pages or Identity Administration tools such as those found in
the OpenIAM End User Portal
Once an employee has been created or modified in the Authoritative Data Source, they
can be synchronized by the Identity system and to a set of target systems, which are
involved in the synchronization. This process is usually subject to some rules where it’s
important to determine which systems a user should be provisioned to. For example, an
organization may leverage Job Codes to automatically provision the user into systems
that a person needs for their specific job.
Automating these routine tasks achieves a number of objectives. First it achieves the
concept of a zero-day start where employees can be productive on the day they join the
firm. Next, since these tasks are defined in a workflow, we can monitor their execution
and maintain an audit trail. The audit information can be used to monitor security as well
as compliance needs.
Once an employee or user has been granted access, the user can then access the
appropriate applications. These applications may be web-based and non-web-based
applications. These applications can be configured to make use of the other identity
services found in OpenIAM. This approach allows corporations to centrally enforce
security policies in a consistent manner across a heterogeneous set of systems and
devices.
www.openiam.com

5. Users that have been provisioned may also use the End-User portal to carry out self-service
www.openiam.com
functions such as:
• Change password
• Forgot password
• Edit profile
• Directory lookup (white pages)
Authorized users may also need request approval functionality where users may ask for
access to additional applications or greater privileges in applications that they may
already have access to.
Through a user's life cycle, there will be changes in their access level. These changes
may be the result of a user changing jobs within the organization, going on leave, retiring
or leaving. Regardless of the event driving change, the IAM solution will need to respond
by changing the user's level of access based on the rules. For example, if the sales
person gets promoted to Sales Manager, they may need access to other systems. In this
case, the identity manager removes the user from the systems that they no longer need
and adds the user to systems that they do need access to. Similarly, if a user leaves the
company, all access would be promptly terminated. All of these changes are logged in
the audit sub-system.
The audit service may be configured to capture a broad set of events ranging from the
provisioning of an employee, accessing of corporate resources, authentication, and to
the changing of an object in a custom application through the use of API. The level of
detail that is captured in each event is configurable through tools in the centralized web
based administration console. Once audit events have been captured, the information
can be presented through a series of reports and graphs.
Identity
and
Access
Middleware
Enterprise
Service
Bus
(ESB)
The ESB is a central component in the OpenIAM SOA. An ESB works by acting as a
transit system for carrying data between applications. The ESB defines a series
"endpoints", through which applications can send or receive data. The ESB routes
messages between endpoints. Using this foundation, OpenIAM provides an exhaustive
service layer that which provides a rich integration layer for organizations that need this
type of capability.
The services provide features such as Authentication, Authorization, Password
Management, Provisioning, and Policy. These services have been designed for
scalability and extensibility. For example, the Authentication service has a pluggable
architecture that allows you to introduce new methods of authentication. Similarly, other
services allow you to use Groovy script, a java like scripting language, to extend the
functionality in the service.

6. Business
Process
Engine
The Business Process Engine consists of a standards-based business process engine
that executes processes that have been created using the graphical process-modeling
tool. The process-modeling tool runs within the Eclipse IDE.
Using a process engine, OpenIAM provides for a way to externalize business rules that
are organization specific. For example, if a user wants access to a particular system we
could have a workflow that first requires approval from the user’s manager and then the
resource owner. However, another organization may a very different workflow for the
same type of request. OpenIAM simplifies the overhead in customizing workflow by
allowing you to define the approval steps through the administrative interface. This
reduces the need to create new flows.
Messaging
The messaging engine is a high performance JMS compliant messaging engine. Within
the context of this architecture, it allows components to asynchronously communicate
with each other as well as provide guaranteed delivery of messages. For example, while
provisioning, a user may need to be provisioned into a number of systems. These
messages to connectors can be published onto the queue and be processed by the
connectors.
www.openiam.com

7. This allows the solution to scale and be more responsive then a purely synchronous
solution.
Scripting
Every customer is different and some business logic needs to be customized to meet an
organization's unique needs. In addition to the workflow engine, OpenIAM makes
extensive use of Groovy to script to allow for rapid customization of business rules. For
example, we may decide to add a new type of password policy. This can be done by
creating a new rule using groovy script and then registering it with the system.
Presentation
Tier
The presentation Tier consists of a web-based administration console and an end-user
portal, which is used for self-service, request approval, and SSO. This set of applications
may be deployed on the same JEE application server that hosts the core Identity
services or it may be deployed on separate nodes depending on an enterprise's security
and scalability needs.
Modifying the CSS files allows an organization to customize/brand the user interface to
personalize the look and feel of the UI. In cases where the OpenIAM solution is used by
service providers, the architecture allows for the selection of custom “themes” based on
attributes. For example, we may want to use one set of CSS files for one customer and
another for a different customer.
Template
Engine
Each customer’s user management needs will be different and this will dictate what
fields we show for screens such as Self Registration, Edit Profile, and Create New User.
To simplify this effort, OpenIAM provides a template engine that is configurable through
the admin interface. In this way, an authorized user can shape the look of these screens
in minutes.
www.openiam.com

8. www.openiam.com
Extension
Module
OpenIAM realizes that the template engine may not serve the needs of every customer.
For this reason, the OpenIAM solution includes a “Self-Service Extension” module. The
Self-Service Extension module is a GRAILS application that has been integrated into the
OpenIAM stack such that customers only have to implement their screen and desired
functionality and not have to worry about how this solution will be integrated.
Security
Architecture
The OpenIAM IAM stack is a secure enterprise application that utilizes the following
architecture to secure data within the system as well ensure that communication to and
from the solution are secure.

9. www.openiam.com
Key
Management
OpenIAM utilizes a comprehensive key management strategy. When the OpenIAM
solution is deployed, a "Master Key" or "Master Salt" is generated. This key is safely
stored in the Java KeyStore. Next, when a user is generated, two user-specific salts are
generated. One salt is used to encrypt PUBLIC information such as cookies, session
management tokens, etc. A second PRIVATE salt is used to encrypt data such as
password, challenge questions, etc. These user-specific salts are maintained in a
relational database and are stored in an encrypted form using the master key. Using
this design, we gain the following benefits:
• The user specific keys are protected by database security and by the master key
• In the event that a key has been compromised the exposure is limited to only one
of the keys that are used by a user.
Tools are also provided to regenerate or change keys.
Encryption
and
Hashing
OpenIAM supports AES (256 bit encryption). Sensitive data such as password and
challenge response questions are encrypted using AES. Where appropriate, SHA-2 is
used for hashing. This provides 256-bit protection.
Session
Management
When a user logs into either the webconsole or the self-service application, OpenIAM
generates a session management token. This token is a string that has been encrypted
using the user PUBLIC salt. A copy of the generated token is stored in the OpenIAM
database. When the user makes a request, the access gateway does the following:
• Validates the token with the stored token to ensure that a token has not been
hijacked.
• Ensures that the token is still valid. Decrypting the token using the user’s SALT
to ensure that this token belongs only to this user does this.
• Generates a new token.
With the token being regenerated on each request, the time in which a hacker can grab
and steal this token is relatively small.
Secure
Communication
Communication between the end-user and the client-facing applications can be
over http or https. Communication between components such as the UI layer and the
service layer can also be over http or https. Similarly communication between the
connectors and the target system should be carried out over a secure protocol.

10. Authentication
Authentication functionality with OpenIAM is provided through the:
www.openiam.com
• Authentication Service
• Identity Provider (IdP)
The authentication service is a pluggable service, which allows new providers to be
added. In this way, a client can use a common interface regardless of whether we are
using password-authentication, certificate-based authentication or some other means.
The IdP uses the authentication service in the background and provides the end-user
with a common authentication user-interface regardless of which OpenIAM application is
being used. The IdP is also an essential part of OpenIAM’s federation solution where
service providers such as Google, Salesforce.com and Box.net can use the OpenIAM
IdP to enable SSO using SAML.
Authorization
Engine
with
high
performance
Cache
The OpenIAM authorization engine architecture is based on a multi-tier, multi-hierarchical
"graph" between Users, Groups, Roles, and Resources. A User can be a
direct, or indirect member of a Group or Role, and can be either directly or indirectly
entitled to a Resource.
Although the hereditary principle applies to all of the above entities, it is only necessary
to check if a User is a member of a Group or Role, or is entitled to a Resource. The
system makes no distinction between direct and indirect membership. An indirect
relationship is just as valid as a direct relationship
As there can be millions of Users, Groups, Roles, and Resources, a non-traditional,
high-performance cache is required. The Cache works via the following principles:
• Only recent Users are pre-cached (people who have recently logged in). Users
who are not pre-cached are fetched via an optimized database query and are
then cached
• For objects are too large to store the cache uses a BitSet to identify Groups,
Roles, and Resources. Each Group is associated with a distinct bit. The same is
true for Roles and Resources. This ensures minimal memory usage, and no
chance of memory leaks
Access
Gateway
The Access Gateway is a high performance Apache Web Server module that
complements the Apache mod-proxy module. The access gateway leverages both the
authentication service and the authorization service to enable the following:
• Session management

11. • URL based authorization
• Step-up authentication
• SSO to web applications that do not support federation
User
Search
Engine
The user search engine, which is integrated into the UserManagement service, has been
developed to enhance user search performance. It uses a search engine, in order to
avoid complex database queries that contain many join clauses between different tables
such as USER, GROUP, ORGANIZATION, LOGIN, ROLE, etc. It also helps to avoid
complex indices in the database.
User search consists of two parts: the Search module and the Index module. These
modules work with each other when the caller triggers a user search request.
The Search module builds the necessary query based on incoming search parameters
and sends this query to the Index module. The Index module has the following
functions:
• It processes the search query from the Search module, and returns a List of user
identities. This list is used to find user objects by primary key index in OpenIAM
DB.
• Every N minutes (N is configurable), all search indices are refreshed in order to
www.openiam.com
provide up-to-date data.
Provisioning
Engine
and
Connectors
The provisioning engine is responsible for all activities related to provisioning, de-provisioning
and password synch. The provisioning service determines the systems that
a user should be provisioned into and then calls the appropriate connectors. Prior to
calling each connector, the service determines which attributes to pass to that
connector. This again is done through the user groovy scripts, which are used to define
field level rules. For example, when provisioning into AD, we need to populate the
samAccountName. However, the logic used for this will vary from company to company.
One company may use the employeeId as the samAccountName. Another company
may use firstName.lastName. By defining this logic in groovy scripts, the OpenIAM
solution can be customized to meet the varied needs of different customers.
For added flexibility the Provisioning service has a pre-processor and a post-processor.
These are scripts that can be executed before or after an operation in the provisioning
service run.
Audit

12. Auditing is an essential part of an IAM platform and the OpenIAM audit functionality
allows for the logging of virtually all types of events such as:
• Object creation or change
• Viewing an object
• Linked events where a large transaction such as provisioning may trigger other
www.openiam.com
events
The audit service consists of the following components:
• Event collectors capture audit events across different parts of the solution
• Queue – where audit events are published
• Audit Service – which takes care of logging the events
Also, audit events are signed so that any tampering of events can be detected.
Reporting
The reporting architecture in OpenIAM consists of the components described below.
Today they provide a flexible solution for reporting from multiple types of data sources
and formats.
• Report Viewer – Which allows us to select which format a report should be
viewed in
• Report Designer – BIRT report designer that allows us to create report templates
• Report Data service – Service that allows us to define, using Groovy script, what
data to obtain and from which source. This allows us to query data from
disparate data source such as RDBMS, LDAP, AD, CSV files, etc.
• Subscription engine – Allows users to subscribe to a report and have it delivered
to them at regular intervals.
Scheduler
The IAM platform allows for the creation of scheduled tasks. Examples of commonly
used scheduled tasks are:
• Password expiration notifications
• Detecting accounts that have been inactive and then changing their status to
inactive.
Scheduled tasks can be created using Groovy scripts, which allows for great flexibility in
the type of functionality that can be implemented in these tasks. The frequency of
scheduled tasks is controlled through a CRON expression. The OpenIAM scheduler
framework allows for an authorized user to cancel a scheduled task while it’s still
executing.

13. High
Availability
Identity and Access Management systems need to be operational 24 x 7 and cannot
afford down time. To achieve high availability, the OpenIAM deployment architecture
allows you to select from either:
• Application server-based clustering
• Hardware load balancer in front of the UI layer and/or the Service layer.
Both models will allow the load to be balanced across nodes and to failover in case a
node in a cluster goes down.
Conclusion
The OpenIAM Identity and Access Management platform provides a
lightweight, feature rich solution that can scale to meet the needs of
complex environments. Future version will build on this platform to
offer greater ease of use and additional functionality to better address
business needs.
www.openiam.com