Just over six months after acquiring role management provider Bridgestream, Oracle announced at the RSA conference the first major release of the tool under its watch. And it’s issued a detailed white paper articulating its view of the lifecycle for managing role-based access.

The rebranded offering, now called Oracle Role Manager, applies a business context to the way that end user roles are defined. Offered as a module of Oracle Identity Management suite, Role Manager helps you specify business and IT roles and privileges and associated ownership and delegation models based on organization structure and what Oracle terms “application-specific” identity management. Roles and permissions are made dynamic through support of multi-dimensional hierarchies (e.g., hierarchies that crossed with matrixes), and event-based features that trigger changes to permissions.

While this all sounds rather complicated, the underlying business logic is rather straightforward. Making role-based permissions dynamic means that users gain access to specific information based, not only on rile, but circumstance (or business scenario). For instance, an insurance underwriting specialists gains one-time access to an prospective policyholder’s claim history only at the time that the customer is applying for a new or modified policy. Once the underwriting decision has been made, such access to that specific customer’s records would be out of bounds.

It represents a departure from the traditional way that roles are managed: with an identity management system that classifies groups of users listed in a directory. The difference is that absent a role management system, management of role-based permissions is pretty static. They won’t change based on the business scenario or process, and they don’t get as granular. Put another way, you could consider traditional role management to be passive, whereas what Oracle (and others like Sun) could be deemed more active.

In conjunction with release of Role Manager, Oracle mounted the soapbox to flesh out its vision for how you manage role-based security. Amit Jasuja, Oracle's vice president of Identity and Security Products, described to us a four-stage lifecycle for what Oracle terms “Service-Oriented Security.” Although the obvious inference is to SOA, Jasuja explained that it was meant to refer to the way businesses themselves operate: everybody performs services, and there are web services standards that enable you to automate baking security into your software stacks.

The lifecycle to some extent mirrors the SDLC, in that it involves development, deployment, and administration (with development as a composite for design, development, and testing). To that, Oracle adds a fourth stage: governance, risk management, and compliance (GRC).

Ideally, security should be baked in starting with development. Of course, that’s been a non-starter with developers because they are focused on coding functionality, theoretically to business requirements. They lack training and awareness to code in security.

But instead of having developers learn how to code for security, the idea is to have developers simply tag or “watermark” data elements that could be deemed sensitive. Security or identity services specialists would define a standard format by which developers tag the data. Towards that end, Oracle, along with Sun and Novell, are working with OpenLiberty.org on the Identity Governance Framework (IGF) project, which proposes a syntax for specifying privacy properties, consent data, and references to business agreements.  That way, developers don't have to make decisions best performed by security or audit specialists, but only have to flag what info should be looked for.

That format would then be readable by the middleware on which the apps are deployed, so as to preserve the identity management chain. And of course, the middle tier platform, whether it be a server or ESB, would then call specific identity services. Ergo, that’s where tools like Oracle’s Role Manager would make the tags actionable.

Administration would not look terribly different from the way it’s handled today: security administrators have authority to grant or revoke access by different users or roles to different pieces of data or access to specific applications or services; end users would have ability to reset passwords via self services; while auditors would review overall robustness of the organization’s access management strategy.

The final piece of the puzzle is governance, risk, and compliance, for which the primary mechanism is policy management. On a technical level, it means defining standard formats or syntax for representing security policies that are enforced at runtime, such as an application role being mapped to an LDAP group or business role in a role management system.

Clearly the driver for active role management is the need for segregation of duties, as called for by regulations such as SOX . Naturally, Oracle says it has an answer here as well. At RSA, it announced version 8.0 of Oracle Access Control Governor , which is used for separation of duties. The difference? Version 8.0 lets you extend the data model tuned for Oracle e-Business Suite to other applications.

---