My recent experience with openSSO entitlement services

Over the last ~5 years the (Application) Access Management (AM) space has gained a level of acceptance across the Fortune 500 by implementing:

1. Single Sign On (SSO) – thus reducing the number of logins and passwords
2. Coarse Gained Access control – enforcing policies which guard end-user entry into application(s)

To date, most enterprise deployments of AM have achieved the above through the use of proprietary policy languages and high-level roles or groups to enforce access control. Also (for many reasons), there has not been deep access control integration with these applications, thus not exposing application entitlements to the enterprise. See figure 1 - as a typical Access Management deployment.

Figure 1 - Coarse grained vs fine-gained entitlements

Enter XAMCL. The next level of Access Management. It should allow customers to:

1) reuse policies across applications 2) create policies using application entitlements 3) use a standards based policy language 4) author complex polices outside AM system

The following blog details a customer scenario where we used OpenSSO 8.1 to prototype a set of use cases. Oracle also has an entitlements product, but it’s separate from their Access Management implementation.

The customer mentioned they were currently investigating solutions to replace their home-grown application entitlement system(s) with an off the shelf product from a reliable vendor. They also mentioned they were having issues with slow response time from their web access management system.

Since the customer had not yet selected a solution I recommended Sun’s OpenSSO. I explained some of the OpenSSO 8.1’s product features such as a new policy engine, entitlement services and export/import of policies. The features were interesting to the customer and warranted a demo with 1 or 2 use cases. See figure 2 - as a different approach to expose application entitlements.

Figure 2 - Use Access Management system for all access controls

The demo with OpenSSO would entail the following:

Use case: A manager employee is authorized to pay the vendors a limit of $5,000 per transaction on Thursday and Friday and between 9:00 AM to 5:00 PM only.

A VMware demo was quickly created with the following components:

• OpenSolaris 2009.06
• OpenSSO Express 9 nightly build
• Java 1.6 U17
• MySQL 5.1.42
• Sun Web Server 7.1 U7
• Glassfish Application Server 2.1.1
• DSEE 7.0

This use case was executed without any major issues using OpenSSO’s new beta console (see screenshots below). The customer was very impressed with the quality and ease of use of the new beta console. The demo also highlighted how simple it is to export / import the XACML based policies using an easy-to-use admin interface (screens attached).

OpenSSO 8.1 introduces new entitlement services based on the XACML policy language. This language provides centralized policy management, rule based policy evaluation, policy delegation, policy versioning and auditing capabilities. The major components in the OpenSSO entitlements consists of Policy Administration Point (PAP), Policy Decision Point (PDP), Policy Information Point (PIP) and Policy Enforcement Point (PEP). You can read all about XACML by visiting Oasis website.

See figure 3 - as the high level topology used in this prototype

Figure 3 - Re-architected using entitlements capabilities of OpenSSO

From a deployment perspective, the customer was happy to see that the web access management and fine-grained authorization can be packaged together (single WAR file) with the application. They were also excited to see the use-case II (see figure 3) where the PDP and PEP can co-exist within the application (eg: Portal Server). This use-case improves overall portal access performance because 1) the PEP interacts with PDP locally thereby reducing the network calls. 2) The PDP can be configured to cache the policies or enable notifications in order to obtain the policy updates from the PAP. I will provide the steps about this use case in my next blog, going into more detail.

Screen Shots: Here are some of the screen shots from the POC.

Manage Applications

Manage Entitlements

Export Policy feature

Standard XACML policy language

Manage delegations

Conclusion: Using this new architecture the customer was able to combine the existing identities from the Access Management solution with the application entitlements. OpenSSO 8.1 was deployed seamlessly with data being fed from various application stores without actually being migrated into a single repository. The XACML policies that where created in OpenSSO used application specific entitlements and offered both coarse and fine-grained access controls to the applications.

Please feel free to contact us if you’re considering XACML or fine-grained entitlements for your enterprise.

I saw this a couple weeks back… Prototype This. Being a big fan of the Discovery Channel I plan to tune-in. But, it got me thinking about the values of software prototyping:

1. Allows us to go beyond the theory and gather real metrics
2. Provides a powerful mechanism to collect end-user feedback
3. Allows us to Prove or Disprove a theory

In order to provide mature solutions to end-users we must provide a path for feedback and evolution. Unfortunately with many implementations time and budget constraints make it tough to allow users to factor in proper prototyping & feedback loop prior to the real deployment. As you can imagine this can lead to discontent and lack of productivity for end-users.

In this blog I’ll show how easy it is to setup an “Access Request” prototyping using icRARE™. One of the really awesome features of icRARE™ is how little time and effort it takes to model provisioning business logic for a given application. Please keep in mind we’re following the “Access Request” pattern I’ve described in my previous blogs.

So onto my prototype… I’m recalling a demo I did for a customer the other day. We were discussing how “Access Request” can apply to physical assets such as a phone. So I said let me show you how I can use icRARE™ and icLITE™ to prototype a “Mobile Phone Tracker“.

As you can see, tracking your physical assets requires little effort when using the combined power of Sun IdM, icRARE™ and icLITE™. Granted this is a simple usecase, but it took me minutes to build. Now THATS rapid prototyping! This is one example of how ICSynergy’s icIDENTITY™ Suite can evolve your identity management solution.

Stay tuned for more exciting examples and demonstrations on the ICSynergy YouTube Channel!

My previous BLOGs “Building A Better Mouse Trap Part I & Part II” laid the groundwork for evolving the “Application Access Request” IdM problem domain. In the spirit of socializing this problem domain, I’ll take a step back and BLOG the core “access request” specifications ICSynergy used for the creation of our commercial IdM enabling products icRARE™ and icLite™. 

Access Request 101

“Access Request” a standard set of request types (new, modify, delete, enable and disable) initiated by or on behalf of a subject that govern the lifecycle of a subject’s identity (including credentials and/or entitlements) to digital or physical assets.

Digital Asset: application access or system related resource e.g. CRM or ERP application

Physical Asset: a resource that has a physical embodiment e.g. ID card, work space, phone

Assets may be categorized using role, group or other means of aggregation

Request Types

It should be assumed that the following requests may consist of one or more steps executed in parallel or serial in order to perform the required routing, approval, escalation and provisioning logic.

New: provision a subject’s identity on a given asset

Modify:  modify a subject’s identity on a given asset

Delete: de-provision a subject’s identity on a given asset

Enable: enable a subject’s disabled or expired access to a given asset

Disable: disable a subject’s access to a given asset such that it can be enabled in the future

A real world example of a user initiated access request is user Jane Doe requesting “New” access to an enterprise application (digital asset) and cell phone (physical asset) as part of the new hire process.  In this example these two requests would likely be routed and approved as separate work items. 

Where as a system generated access request example would be triggered by an event that Jane Doe has been added to a HR system and a series of “New” requests are automatically generated by the provisioning system to request access to the required enterprise applications.

Services: are enablers that supply foundational capabilities that make the execution of the access request types possible.  The following services should be made available.

Request wizard: system must allow a requestor to find and select assets to generate requests.  The request wizard may use asset aggregation (groups or roles) and policy mechanisms.

Policy: system may provide controls to determine if a subject is allowed to invoke a given access request to a given asset or entitlement. E.g. Role or Separation of Duty (SOD) checks.

Request Routing: system must support a mechanism to route requests to one or more approval entities.

Request auditing: system must provide accountability that associates a subject with its actions (audit trails and logs).

Request tracking: system must provide a mechanism to track the status of any request.

Request Approval / Denial: system must provide controls to allow or deny requests.

Notification: system must allow for notification of pending work items, escalation status or other

Escalation: system must allow for a mechanism to raise awareness of unattended or uncompleted tasked based upon some criteria (e.g. time limit)

In my next blog I’ll review an implementation of “Access Request”, icRARE™, icLITE™ and the value-adds made available to this problem domain.

This blog is a continuation of the evolution thread I started in my previous blog ”Building a Better Mousetrap”. Taking those previously discussed concepts I will apply them to the Identity Management arena and discuss “Application Access Request”.

The application request problem has been around in some incarnation for ages. You may have seen this implemented as a trouble ticketing system, custom back office application or a paper-driven process that are used to manage user entitlements to N number of enterprise applications. Basically think of it as a collection of related business processes per application.

The Application Access Request  problem can become complex with:

1. a large number of managed applications
2. sophisticated user entitlements (mainframes)
3. advanced routing and approval logic
4. integrated compliance policies

These request applications are typically highly customized and man power intensive.

In this compliance era the initial problem has change a bit but there has been an evolution towards Identity Provisioning (e.g. Sun Identity Manager, Oracle Identity Manager) tools to augment or replace these custom access request tools. This makes a lot of sense as these provisioning products have workflow capabilities, compliance features and prebuilt integrations with most popular enterprise applications that help solve the above complexities.

I have found that after fully implementing all associative request workflows for at least a half a dozen core SOX applications with these provisioning tools it becomes apparent that it is not easy or cost effective to continue down this path. In many situations companies are left with some ratio of automation and manual provisioning / compliance. There are many factors and causes for this complexity that we’ll discuss at another time but needless to say another specialization and evolution is needed inside the Application Access Request area.

Enter ICSynergy’s Rapid Application Request Engine (icRARE™) which was created to evolve the Application Access Request problem. (see Figure 1).

Through numerous Identity deployments, best practices and specialization, we have defined a standard set of request (new, modify, enable, disable, delete) types, which govern the full life cycle of a user’s entitlements within a given application. Along with other value-add services, this basic pattern of request types defines the “Application Access Request” problem space.

These request types are the basis for our evolution and have allowed us to build a value add framework, methodology and development tools that provide measurable advancement in time to value.

Just as Struts evolved (see figure 2 ”Building a Better Mousetrap”) the J2EE display tier by adding a macro layer which simplified and accelerated the web development problem area. ICSynergy has evolved the typical hand crafted access request systems to a new macro layer with the creation of icRARE™. In cooperation with the Sun Identity Manager product, we have created a definition of a full “Application Access Request” solution.

icRARE™ is the perfect alignment of a great provisioning product and “Access Request” framework / methodology that can provide an order of magnitude in time and effort savings over the traditional hand crafted methods of developing access request workflows.

In a future blog I’ll drill into the icRARE™ “Application Access Request” development tool and services as well as the value propositions that icLITE™ offers to enable rapid integration of applications into Sun Identity Manager. Visit our website to find our more information about both of these products.

Exciting times here at ICSynergy… I’ve been wearing developer, product and marketing hats implementing some innovative new products (icLITE™ and icRARE™). I feel we’ve truly evolved the “Application Access Request” problem area within Identity Management. It’s been a multi-year journey to evolve to a level of best practices that positioned us to build a framework and methodology needed to properly address this problem area.

In this blog I’ll chat about how we in the Information Technology (IT) world have built our own evolution models, which for the most part have resulted in the creation of a better mouse trap.

First off, I’ll describe this evolution model in simplified steps (as depicted in Figure 1)

1. Start with The Problem
2. The Framework or processes emerge - typically very generic
3. As the problem area gets better understood, best practices and specialization emerge
4. New macro-layers (frameworks) are created that incorporate best practices, giving a quicker time to value.
5. The cycle repeats

To better illustrate this lets take a simplistic look at the evolution of Java on the server side (as depicted in Figure 2)

Problem: The industry has a need for cross platform server side applications
Solution: Developers hand craft server side Java frameworks and applications
Evolution: J2EE standards and components

Next Problem: Display and persistence components require too much custom code
Solution: handcrafted web tier and persistence frameworks
Evolution: Struts and Hibernate emerge as common frameworks to simplify server side Java development

… the cycle continues

The net/net here is we are still dealing with the same complexities of developing applications using Java on the server side. Yet through this evolution, macro layers (frameworks and component models) have been established that mask the complexities developers once had to address. By solving these complexities with higher-level frameworks which allow for better tools and methodologies a quicker time to value is produced. As expected, this cycle will continue as long as the initial problem is still of interest to the IT world.

I’ll follow up on this thread in my next blog with how all this ties back to the “Application Access Request” identity management arena.