Integration of Authorization/Entitlement Management products with Provisioning Products

As part of the various discussions that I keep having in the fine-grained authorization domain (or is it entitlement management now?), this is one of the topics that we visit. The above requirement stems from the fact that Provisioning Products were never built to support the entitlement/authorization concepts and authorization policy lifecycle management.

So, the entitlement management products' management interface (for policy lifecycle management) can not be replaced by provisioning product. In light of this realization, the next step is to find the best way to bring together the two technologies. There are various ways in which the two products can be integrated and some of the approaches are discussed below. Please note that this list is in no way complete and would look forward to your comments on other possible approach in this area.

  • User Provisioning - The entitlement management product itself may be seen as another repository of user data that must be updated OR the product may be seen as something that must be updated as part of user provisioning for a specific application (which is protected by entitlement management product). This idea is valid only if the entitlement management product can not integrate with standard identity repositories OR due to implementation requirements which forces the product to store the user information instead of pulling it at management and runtime from external repositories.
    Incase the product is being treated as another repository of user identity, the User Identity with its standard attributes and roles may be provisioned to the product as part of standard user setup or when the user is assigned an application that depends on the entitlement management product for entitlement management. If the setting up of user information in entitlement product is being treated as one of the steps of application provisioning, then an application specific profile (with application specific identity, attributes and roles) can be provisioned to the entitlement product as part of application provisioning process. This profile would need to be generated manually based on application policy model (see fine-grained authorization provisioning below).
  • Resource Provisioning - The concept of resource in most of the user provisioning system is limited to the idea of application, i.e. these product do not understand that the application itself consists of additional resources like accounts, documents, trades to which the entitlement provisioning need to happen. Due to this deficiency the user provisioning products are not great for managing and provisioning resources (which most people still think is in the domain of application unless there is a drive to start building a standardized resource lifecycle management infrastructure which may makes some sense for some type of data like Personal Identifiable Information, Intellectual property, etc). But some product may provide the capability to provision the application to the entitlement management product when the application is created in the provisioning product.
  • Fine grained Authorization Provisioning - The provisioning systems so far have supported the idea of provisioning of user data (id, roles/groups, attributes) into the application repository. People have extended this idea and implemented ad-hoc models of provisioning entitlements into their applications by mapping the user specific entitlement data to standard concepts like application specific attributes (some of the products do not support the concept of role/group as a separate concept). But such an approach means that the model hard coded into provisioning products is completely dissociated from model embedded into the application or the entitlement management product.

    As far as I can see, there is no standard way to communicate this information to the provisioning product at runtime. What we need is a way to ask the entitlement management product, what is the model that it wants to expose to the requestor and what is the information corresponding to the model that should be provided to requestor so that they can choose the entilement that needs to be provisioned for OR this information can be communicated to the provisioning system by the entitlement management system as and when the policy model is updated. For example if the authorization model implemented for application X is User based ACL, then the provisioning system would need to display to the requestor the resources (provided by application or entitlement management product) that provisioned user may be granted access to OR incase the authorization model is a role based access control model, the requestor would be provided with a list of application specific roles (provided by entitlement management product) that user can be provisioned for OR if the entitlement model is attribute and role based, the application specific  attribute and role list can be provided to the requestor to allow them to define the user's entitlement for the application.
    The approach described above is more of a thought and I do not have answers for all the question this may raise. But from lifecycle perspective, unless there is a change in the authorization model for the application(i.e. from User ACL to RBAC), only the attributes and roles (or resource values incase of User based ACL) would change for an application over time and that can be addressed by adding validation and associated remediation to the provisioning system's identity data synchronization/auditing process for the application.  

Thoughts?  

Comments

Post a Comment

Popular posts from this blog

Vendor List

Updated: November 12 2006 I am trying to come up with the list of vendors and associated products in the Identity and Access Management arena. Please note that this list is based on marketing/public information and my understanding of the terms which may not comply with any specific groups' definitions and/or requirements. This is by no means a complete list and will keep growing as I get more time to add them and find more companies (any help on that front will be really appreciated). Before we go further along, lets try to define what each of these product typically do so that my mode of classification may make sense or any flaw in my classfication will become apparant. Identity Management/User Provisioning These products typically provide the facility of Workflow-based Identity provisioning, password reset, identity reconciliation/discovery, delegated identity administration and self-service features on wide variety of identity platforms (like LDAP, Unix, Windows, Mainfra...
Read more

Understanding IAM Technology: Web Single Sign On (Web SSO) Part I - Introduction and Use Case Definition

Image
Update September 6, 2015: Part II in the series is now available . Update August 19,2006: I am rewriting this entry based on the methodology I am using for some of other domains. Hopefully, the new methodology would make it more useful to some of you. I talk to a lot of people from developer background who still do not have a good background in the IAM technology. Eventhough there is a lot of information on the web, I have felt a lack of good technological discussion on the various component that  actually form the IAM domain. Some of the good sources for the information on IAM are Microsoft Identity and Access Management Series Archie Reed Oracle Federated Identity Buyers guide Oracle Identity Management Buyer's Guide Identity Management Dissected Most of these document discuss the basic concepts but do not extend it to existing technologies and how it applies to them. This series is an attempt to look at the technology behind the Identity and access m...
Read more

Reclaiming your account: Password Reset/Forgot Password

Image
This is probably one of the oldest functionality that is part of any password based system and by now I was hoping that people will have figured out most of the ways of doing it. But while reading answers on stackoverflow on this topic, I was impressed by new ways being developed and implemented by developers in wild. While reading the discussion I felt that there is lack of a structure to look and study this functionality and this post is an attempt to define a structure. Before I go there, I wanted to capture my understanding of the password reset functionality. Why - Well if we are not noting down all the accounts we have created in life (either electronically or manually), it is possible that we are going to forget passwords for some accounts as we age. Even if you follow some techniques like having standard passwords across all your accounts, due to site limitations, change in word preferences, etc, you may not remember the applicable password for a site and so the lifesaver Why...
Read more