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.