Tags: Entitlement Management, Gartner IAM Summit, Oracle Identity Management

The webinar is today, Monday Sep 21st, 11 am EST (yeah, I know, short notice. But hey, if you were following me on Twitter…). You can register for the webinar (it’s free!) here.

And if you miss it, it will be available as a podcast later.

Tags: Cloud Computing, Identity Services

As an abstract identity construct, entitlements model whatever it is in an actual system that allows a user to do some well defined thing. As such, it is a fine-grained access management construct, so Ian isn’t wrong about that. But I think Ian’s post misses the power of the entitlement construct, which is what entitlement management products aim to surface.

An entitlement could simply be the permission to access a URL (typical web access management scenario). It could be the permission to click on a menu item in an application (typical application functional security scenario). It could be the permission to access a particular data record in the database (typical data security scenario). Each of these taken individually is a pretty big deal in of itself, but can be handled by products or features that are already available today.

But in a service-oriented world, where multiple applications get chained together to perform the functions behind a single action a user can perform, the entitlement becomes a hugely important construct. Currently, this would require ensuring that the permissions within every single component are properly coordinated to allow this flow to go off without a hitch. It becomes a very complicated permission engineering problem to figure out how the ensure that the function will work in all cases necessary.

Entitlements provides an abstraction and layer of indirection that eases the problem, unifying the access control equation. In an entitlement management based architecture each service, every tier within the service, every layer within the application, can refer back to the same entitlement and entitlement policy to determine whether or not to allow the function to proceed.

And to provide this kind of cross-service access control, an Entitlement Management product like Oracle Entitlements Server provides the ability to define powerful entitlement policies based on identity, role and contextual data. And while XACML is a necessary part of the architecture that enables a complex deployment to occur, it is just an enabling tool, not what defines the feature itself. In fact, XACML does bring its own limitations to a run-time environment.

Entitlement Management is a powerful tool that can simplify the mess of permissions and privileges that are strewn all over the enterprise landscape. When applications were silos, it was sufficient to deploy a provisioning system that could handle the provisioning of access into these black boxes. But with applications transforming into services and becoming increasingly interconnected and interdependent, role and entitlement management become critical pieces of enterprise architecture that help provide critical control, predictability and uniformity to the enterprise.

Tags: Entitlement Management, Identity Services, Oracle_IDM, Service-Oriented Security

The new feed URL is: http://feeds.feedburner.com/TalkingIdentity

Seems like some feed readers don’t provide a way to simply update a feed url. You have to unsubscribe from the old and re-subscribe to the new url, unless you want to keep getting duplicate feeds

Thanks again for reading. I’ll try to keep it interesting.

• Brand new Graphical Workflow Designer
• Major enhancements to the Generic Technology Connector (first introduced in OIM 9.0.3, and discussed here)
• Enhancements to the Attestation Framework
• Enhanced support for Multiple Authorities of Identity Information
• Support for inbound SPML v2.0 provisioning requests (via web services)
• Richer constraints in Password Policies
• New Connector Installation Wizard

The release also includes a number of fixes, enhancements aimed at improving usability and manageability of the product, and greater platform support.

One of the impressions that seem to exist out there is that after acquiring products, Oracle focuses more on integration projects and less on feature development and innovation. That couldn’t be farther from the truth, and hopefully this release will prove that. While there usually is a post-acquisition lull in terms of releases, it is usually to accommodate the cost of assimilating into the machinery of a big company, and the expansion into a global marketplace. This involves improving platform and language coverage, and porting over to the new release processes and standards. And priorities also tend to shift dramatically when you go from being a startup product to one from an established software vendor.

But one thing that the Oracle Identity Management team has been very good at is listening to our customers and the marketplace. Most of the work in release 9.1 has been driven out of recommendations from our Customer Advisory Board and feedback from the marketplace.

In the coming weeks, I will write in greater detail about some of the major additions to the product in release 9.1. If there are specific topics that you would like to know about, send those in to me and I will see what I can do.

Tags: Oracle Identity Management, Oracle Identity Manager, Provisioning

• Oracle Identity Manager 10gR3 Datasheet (PDF)
• Generic Technology Connector Administration Guide (HTML)

Tags: Generic Technology Connector, Oracle Identity Manager, Provisioning

However, for applications that are not supported out of the box, or custom applications that customers have built themselves, building a connector can be an arduous task. It takes planning and resources (both in time and manpower). Quite often, APIs are simply not available for build a good connector. And the number of applications in an enterprise that need to be managed can prove overwhelming to a small IdM team.

Introducing the Generic Technology Connector
This is where the Generic Technology Connector steps in. Introduced in OIM 9.0.3, the name is actually a misnomer. The GTC is really a wizard that provides an alternative connector development environment to rapidly create all the necessary functional components that make up a target system connector in OIM. It’s power comes from the way it leverages standardized mechanisms and tools instead of application specific APIs. The GTC framework also eschews the more powerful, but complex, process-based connector approach for a far simpler dataflow-based connector approach.

The GTC is one part of a three pronged comprehensive integration offering (see diagram above). The GTC allows customers to easily build connectors for target systems that support standard integration mechanisms like flat-file imports via FTP, or SPML-based provisioning over Web Services. Target systems that do not need complicated provisioning process flows can be quickly brought under management in OIM, dramatically reducing the deployment timelines. While a GTC-based connector does not have all the rich capabilities an API-based application-specific connector has, the fact is that for most applications the deeper integration capabilities are not needed.

Architecture of a GTC-based Connector
The following diagram shows the component level architecture of a connector (supporting both provisioning and reconciliation) built using the GTC (click on the image for a larger view).

The GTC framework provides basic building blocks that are used to rapidly assemble a custom connector. The architecture shows the dependence of the GTC framework on the data migration aspect of the connector. The building blocks are:

• Reconciliation
  • Reconciliation Transport Provider: This provider is responsible to moving the reconciled data from the target system into OIM.
  • Reconciliation Format Provider: This provider parses the message received from the target system (that contains the reconciled data) into a data structure that can be understood by OIM’s reconciliation engine.
  • Validation Provider: This provider validates any data received before passing it on to OIM’s reconciliation engine.
• Provisioning
  • Provisioning Format Provider: This provider converts OIM provisioning data into a format that is supported by the target system.
  • Provisioning Transport Provider: This provider carries the provisioning message received from the Provisioning Format Provider to the target system.

The term Provider is pretty ubiquitous in the above architecture, and represents one of the fundamental features of the GTC framework. OIM administrators can add to the building blocks that make up the GTC framework simply by defining and dropping in new providers supporting additional technologies/mechanisms. The Transport Providers support standard communication protocols like HTTP, SMTP, FTP and Web Services. Format Providers support generic message formats such as CSV, SPML and LDIF.

The GTC Framework builds on top of the existing connector framework in OIM, leveraging all of it’s existing capabilities (like auditing, security, export/import capability etc).

Developer Experience
A major feature of the GTC is the improved developer experience. The GTC employs a web-based point-and-click graphical wizard that clearly shows to the user the data flows that they are defining within the connector. It stores in metadata all the configuration information regarding the connector, so that it can reload the GTC view of the connector and enable ongoing maintenence of the connector in the same graphical environment. Since the GTC builds the connector using the standard connector framework behind the scenes, the developer is actually free to go into the standard OIM development environment and make further modifications to the generated connector. However, once the GTC-based connector has been “customized” in this manner, it can no longer be maintained using the GTC.

For more information, visit the page for Oracle Identity Manager at oracle.com/identity.

Tags: Generic Technology Connector, Oracle Identity Manager, Provisioning

A global customer is implementing a “single forest, single domain” directory (MS AD), supporting among other things SAP and Windows – about 30,000 users. They have asked us to summarise the business case for additional IdM solutions given the single directory approach.

Dr. K says:
With all the material available today on identity management, it continues to amaze me how many people still ask their variations on the question “I have AD deployed, why do I need IdM?”.

The case for IdM is that of a business solution, not a technology solution. It is the business and security benefits it brings to the table – workflow, audit, attestation, separation of duties, provisioning policies – that drive its deployment in the enterprise. These are above and beyond any technical benefits that you get by introducing automated provisioning and password synchronization.

It should not matter if the enterprise environment is relatively simple from a technology deployment perspective. The business, security and regulatory challenges overlaid on that simple environment may still be complex enough to justify an IdM investment. As the cost of deploying IdM drops over the next few years, we will see a larger adoption of IdM in the SMB market. In fact, at OpenWorld recently, we had some customers talk about their experience successfully deploying Oracle Identity Manager within their  environments in the span of 4-5 months (from buy decision to production). Again, these deployments do not compare to our much touted deployments at Lehman Brothers and other large enterprises. Yet the business benefits they are deriving from their investment are just as important to them (if not more).

Being able to rationalize your environment enough to standardize on a single identity store is extremely important in making sure that your identity challenges are manageable. But that is a one time challenge that, though painful to go through, only gets you started on the path to identity health. IdM brings in the ongoing lifecycle management that is needed to make sure that it stays manageable, compliant, and able to continue to stay in a single identity store.

Tags: Active Directory

In this series, I will posting answers to some of the more interesting questions that are coming my way, both from within Oracle and externally. If you would like to ask a question, send it my way by emailing me.

The first question in the series is an interesting one posed by one of our guys on an internal mailing list, trying to make sense of the myriad of IdM products we have here at Oracle.

It seems like there is a fine line between how one defines directory synch. and provisioning.  Provisioning seems more rules and mapping based while plain synch. (i.e. DIP or other metadirectory engines) appears to be more of a one to one activity with less intelligence and no workflow. I’d like to hear everyone’s thoughts on this.

Dr. K says:
On the surface, there seems to be quite a bit of overlap between the two. After all, the primary function of both systems is to move around data. The main difference that I see is that directory synchronization is an IT solution, while provisioning is a business solution.

Directory synchronization can be viewed as a loose way to link directories. It exchanges data between directories, providing various levels of integration and control. It can enable two directories to stay in sync by sharing information between them, or it can maintain data synchronization between a directory and some external data source (e.g. an HR System database). The focus is on the data, and it is usually practical only where the data and schemas of the two directories are similar, and data can be mastered in both. The rules and filters governing synchronization are usually technical in nature

Provisioning approaches this same problem from a business solution perspective. It provides human interface tools for requesting access, workflow capabilities, role-based decisions, and business and security policy management. It deals with ad-hoc situations, and supports a myriad of business capabilities like reporting, attestation and SoD management – capabilities that directory synchronization tools are not geared towards.

So, when trying to solve the business problems of identity management, go for a provisioning tool. When trying to solve a technical problem around data management, go for a directory synchronization tool.

Tags: Directory Synchronization, Provisioning

Another thought here – how does an organization engineer out laziness? In a
former position I was doing implementations of (unnamed) product and
inevitably when the topic of roles came up I saw just about everything from a
10,000 user account with 30,000 roles (literally) to so many authoratative
sources, I recommended that they just start over. In any case, what drives a lof
the dirty data is laziness, in my opinion. It is far easier (in labor and
political capital) to just create a new role than to map to an existing role or
worse take it to committee to get set up.

Mark’s experience points to one of the top reasons why role management projects fail – role proliferation. And what he attributes to laziness, I attribute to the lack of a well defined role management process. This is where the role definition process I brought up in my last post, and the role lifecycle tools become critical.

The role definition process adds discipline to the act of creating roles by making sure that roles are being defined correctly and are being kept up to date. It does this by using the right mix of tools, data and procedure.

A good role mining tool will not only suggest new roles, but also suggest enhancements to existing roles as new business needs are added into the mix. And elements of role lifecycle management bring in additional discipline. Role attestation ensures that appropriate individuals are tasked with making sure that the roles in existence are still relevant and valid. Role re-factoring analysis looks for possible convergence points and synergies across different roles. Good role mappings between enterprise, departmental and application roles allows for the creation of a scalable model that does not push the problem (and numbers) up to a higher level than necessary.

One thing that Mark also points out is the politics involved in roles (an d identity management in general). While a good role architecture that takes the various strata of roles – enterprise, department and application – does help a little, it is ultimately a problem that can only be solved through a combination of teamwork, business rules and corporate standards. And an understanding of the benefits that good role management will bring to all.

Tags: Role Management