By Eric Renaud-Oracle on Oct 15, 2014
Infosys Limited (NYSE:INFY) is a global leader in technology, consulting and services and an Oracle Diamond Partner that has graciously agreed to present on best practices garnered from experience working on Large Enterprise Identity Management deployments in a four part series hosted here in the Oracle Identity Management Blog.
Large Enterprises: Large Challenges
During the course of deploying Oracle Identity Management suite for various large enterprises, the Infosys Enterprise Security & Risk Management (ESRM) technology team has identified a few typical organizational scenarios:
- Oracle Identity Manager (OIM) version upgrades
- OIM deployments for Organizations with existing custom user request Interfaces
- Migration from other Identity Management products to OIM
- Coexistence of OIM with another Identity Management product
- Upgrades to request interface of OIM
While some organizations implement the end-to-end product suite of OIM, others replace specific parts of the Identity Management solution of the enterprise with matching modules of OIM suite.
Provided by security engineers from the Infosys ESRM team, this four part blog series will serve as an overview on design consideration on following topics:
- The importance of an abstraction layer
- Disconnected application framework
- Implementing SSL within layers of Oracle Identity Manager
- Introducing Roles in an Enterprise
In this first of the four part series, we will discuss the need to build an intermediate or abstraction layer to allow for consolidation of identity, account and access information from OIM and other enterprise sources.
The importance of an abstraction layer
Infosys follows its proven “Accelerated Integration Methodology” (AIM) for rolling out Identity Management components. It consists of four phases –
- “Envision” phase: Strategy of deploying the Identity Management capabilities are finalized
- “Enable” phase: Core Identity Management components are deployed
- “Empower” phase: Additional capabilities like Single Sign On, Fine Grained Authorization and Role Based Access are enabled
- “Extend” phase: Extending the identities across organizational barriers using federation
The “envision” state of an Identity and Access Management program is the initial phase where the Enterprise Security team finalizes the approach to consolidate the identities and accounts across the enterprise and provide the lifecycle flow of identities to various target platforms and applications. The detailed analysis of the existing Identity Management practices sometimes reveals patterns of applications and interfaces accessing the enterprise identity sources directly and business validations and decisions embedded in the applications. This leads to duplication of logic and usage of outdated identity and account information across enterprise systems.
After introducing OIM to consolidate the identities and accounts, the process to update the existing applications to use the identity and account data provided by OIM is time consuming. To ease the situation, the organization can plan for a “co-existence phase” during which the older IDM processes exists side by side with the new IDM infrastructure. But the co-existence phase leads to some interesting challenges. Viz. in some cases organizations maintain multiple request and provisioning systems due to legacy issues, thus triggering a need to track the status of one access request across multiple provisioning engines beyond the migration project. After reaching steady state, the organization will have only OIM as the one identity management tool.
These scenarios require an abstraction layer to be created on top of OIM for both provisioning and data services. This layer can then expose the OIM identity and account data and even data from outside OIM (which doesn’t need to be consolidated in OIM) in a consistent and faster way to all interfacing applications. This can also provide an interface where any new access can be added or modified on the connected targets using OIM.
An “Abstraction Layer” by definition hides the details of implementation while exposing secure and simple interface for identity and account data to outside systems or even to OIM forms. It also provides an interface to manage request submission and status retrieval use cases across multiple request and provisioning system. It provides a platform to consolidate the business decisions and a common interface that can be consumed by many applications. Even if there are standards and specifications available in market, we suggest analyzing the possibility of building a service that is consistent with the long term strategy of the enterprise.
So, how this can be achieved and how does this help?
Creating an additional layer can be a challenging process. We have to build an “Enterprise Identity and Account Services" layer that can receive requests from multiple systems and query OIM data and other system data for applications and platforms.
It should be simple and scalable to service requests in a faster and secure way. It should also provide different types of interfaces (Web services, database tables etc.) for a wide variety of systems that needs to be serviced. It needs careful analysis of what data is available in OIM and what needs to be fetched from outside OIM and how frequent these updates should be made. And, it should also pave the way for creating a single source of Identity, Account and Governance Data.
There can be multiple methods and interfaces created as part of this exercise. Drawing from the Infosys ESRM team's experience, we recommended having these services grouped under the following four categories.
- User and Account data services: Services to expose the user, account and attribute information
- Provisioning Services: Services to create/update/delete/enable/disable the accounts and users
- Audit Services: Account and User Request / Entitlement history services
- Governance Services: Access certification data services
Although provisioning systems like OIM and user repositories like LDAP provide native APIs to access all the information, the key in large enterprise Identity Management implementations is to provide usage-agnostic consolidated data services without compromising the security aspects of such data access and usage. Simple but critical requests like “get all service accounts owned by a user” or “get all access which were not assigned through a role” etc. can be easily exposed by building the right interfaces.
In addition to the above use cases, we have also come across enterprises that use OIM along with other IDM tools. In such cases, the user access requests have to be split across multiple provisioning systems but the status has to be tracked by a single request key in OIM. We’ve implemented such requirements by consolidating the provisioning services provided by underlying provisioning engines in the abstraction layer. The request system remains completely agnostic to the provisioning process and the systems involved in granting the access.
Reference Architecture: Abstraction Layer Implementation for Enterprise IDM
There are also access certification use cases where the closed loop compliance can be achieved using the services provided by abstraction layer. It can be used to submit access request, manage the access provisioning, track the request lifecycle, retrieve certification data and revoke unwanted access. The layer can service audit needs by exposing access history information to disparate enterprise audit tools.
While embarking on an ambitious Identity & Access Management strategy, enterprises have to continue using the investments made in the past. A well-built abstraction layer allows the organization to build on top of the existing infrastructure and processes. The simplicity of the solution also hides the complexities involved in marching large enterprises forward on the journey of unified identity & access management processes. The layer allows applications and provisioning engines to reuse business logic while keeping them agnostic to the implementation. The investments made in ‘Abstraction Layer’ also open up opportunities for new applications to reuse business logic and processes that would otherwise have to be written again.
Coming Up Next …
Automated application access provisioning/de-provisioning is one way to secure the benefits of IDM solution. But the time and effort it takes to achieve this level of automation is prohibitive. Another approach to win a quick ROI on IDM solution is to enable manual application provisioning. ‘Disconnected Application Framework’ in OIM 11g R2 provides a fast and easy way of integrating applications for manual provisioning.
In the next blog, we will share the recent Infosys experience with integrating 150+ applications in OIM 11g R2 using ‘Disconnected Application Framework’ along with the challenges we faced and the steps to avoid common pitfalls.
About the Author
||Abhishek Nair is a Senior Technology Architect with the Enterprise Security & Risk Management (ESRM) practice at Infosys Limited. He has over 13 years of experience in Identity and Access Management domain. He has played key role in designing and architecting large IAM solution for Infosys customers with a prime focus on Oracle IAM products.|
|Abhishek may be reach via LinkedIn|