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.

Sun’s Ryan Bearden and ICSynergy’s Martin Gee discuss the evolution of the security and identity market, why icRARE was created and the difference between the icRARE and non-icRARE way to do implementations.

Listen Now