OpenIAM Identity and Access Manager Technical Architecture Overview

OpenIAM Identity and Access Manager Technical Architecture Overview

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

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 largesized 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 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

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.

Users that have been provisioned may also use the End-User portal to carry out selfservice 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.

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.

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.

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.

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.

Authentication Authentication functionality with OpenIAM is provided through the: 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, multihierarchical "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

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 provide up-to-date data. Provisioning Engine and Connectors The provisioning engine is responsible for all activities related to provisioning, deprovisioning 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

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 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.

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.