Roles - What 'bout it?

Disclaimer - I have not worked on role-mining project and so most of the views expressed here are based on very limited understanding, a lot of arm chair thinking and some understanding of access management. I may be slightly biased against the role-management because I seem the end goal as Access Management and not role management and so far I have not had the "aha" moment for Role Management.

Coming from fine-grained access management background, I have always considered roles as a means to achieve the end goal of access management. Roles to me are an abstraction that we use to separate the policy modeling phase (roles being used to design policy model) and policy management phase (by managing user to role assignment).
But a lot of people do see the roles themselves as something important that need to be "mined" out of privileges. This could be, to some extent, a result of role-centric security model  pushed by J2EE specification in past (and now through SCA Policy Framework) and the developers being comfortable with such models which tried to build a simple security model built around the idea of Is User In Role. Even though this works for most of the simplistic use-cases, some of the security model are more complex and that may warrants the need for XACML profile for J2EE to express the security policy to be enforced. 

But there is another dimension to this whole discussion. There is a neat idea of  Business Role and IT Role (equivalent to Basic Roles in NIST RBAC?) that seems to be gaining ground. The business roles are typically something that are defined by the Business/Organization (like Vice President, Teller, Trader, Foreman, etc) and IT Roles are defined by the application (like admin, user, auditor, etc). Most of the time it is expected that mapping the business roles to IT Roles would simplify the policy modeling and management. This could be a good justification for finding business roles (probably using top-down approach) and "mining" IT Roles (probably using bottom-up approach), if not already present, and mapping the two. So the problem of managing all the user-role relationships can be reduced to controlling user assignment to Business Roles which is something that is already in place in form of HR systems in many enterprise (Again it is probably already showing why I should not talk about things I do not have experience with and so feel free to correct my understanding)
Even though this approach looks great on paper, I am not sure how effective it is. In the few domains that I have worked, most of the business roles are contextual (for example - trader on a desk, teller at a bank branch). I have always thought that some of domains like manufacturing and retailing were closer to a standard role based entitlement model because of very well defined processes and role. But thinking more about it, even those may have nuances like supervisor of a specific shop. Similarly most of the IT roles are also context based. For example an admin role in a account management application would probably be given on specific accounts.
At the same time there are definitely applications ( for example any vice president can approve expense report ; show the admin menu only to an administrator) that can be fulfilled by generic roles.
Ultimately the use of NIST RBAC in an application boils down to how complex the role context is within the domain. In case the context is simple enough, it can addressed by building it in to roles so that you may have na_sales_mgr, emea_sales_mgr and so on. But most of us already know that such hacks, if not controlled, can become a recipe for role explosion and would ensure that you need a role management product.
The complexity of the context itself can make the role almost a secondary concept. For example let's take a case of a consulting firm working on large project. Such a project may have separate teams of developers, architects, infra guys spread over multiple geographical locations. Now such a scenario may be uncommon in IT consulting but I think some thing similar would be case in a auditing or investment banking where some of the multi-national M&A deals and company auditing take place. In the example earlier let's say the employee John Doe is assigned role DBA for the developer teams in New york and Seattle for the project Big Bang and Backup DBA for the architect teams in Europe (located in London and Paris) for the project Solve World Hunger. In this example the role itself is such a tiny part of the possible complex context structure (Location hierarchy, teams, etc). Now there may not be that many examples out there with such complexity at the context but at the same time such examples help keeping things in perspective.

To summarize I think we need to be clear about what is the problem we are trying to solve before starting on the role management path. If the end goal is access management then NIST RBAC should be looked at just one of the ways of policy modeling. But if the goal is to get the organizational hierarchy in control, then using a role mining tool to get some roles that are meaningless to business may not be right way to proceed and instead appropriate process must be defined and implemented for organizational hierarchy leaving the IT Roles out of scope.

Roles - What 'bout it?

Disclaimer - I have not worked on role-mining project and so most of the views expressed here are based on very limited understanding, a lot of arm chair thinking and some understanding of access management. I may be slightly biased against the role-management because I seem the end goal as Access Management and not role management and so far I have not had the "aha" moment for Role Management.

Coming from fine-grained access management background, I have always considered roles as a means to achieve the end goal of access management. Roles to me are an abstraction that we use to separate the policy modeling phase (roles being used to design policy model) and policy management phase (by managing user to role assignment).
But a lot of people do see the roles themselves as something important that need to be "mined" out of privileges. This could be, to some extent, a result of role-centric security model  pushed by J2EE specification in past (and now through SCA Policy Framework) and the developers being comfortable with such models which tried to build a simple security model built around the idea of Is User In Role. Even though this works for most of the simplistic use-cases, some of the security model are more complex and that may warrants the need for XACML profile for J2EE to express the security policy to be enforced. 

But there is another dimension to this whole discussion. There is a neat idea of  Business Role and IT Role (equivalent to Basic Roles in NIST RBAC?) that seems to be gaining ground. The business roles are typically something that are defined by the Business/Organization (like Vice President, Teller, Trader, Foreman, etc) and IT Roles are defined by the application (like admin, user, auditor, etc). Most of the time it is expected that mapping the business roles to IT Roles would simplify the policy modeling and management. This could be a good justification for finding business roles (probably using top-down approach) and "mining" IT Roles (probably using bottom-up approach), if not already present, and mapping the two. So the problem of managing all the user-role relationships can be reduced to controlling user assignment to Business Roles which is something that is already in place in form of HR systems in many enterprise (Again it is probably already showing why I should not talk about things I do not have experience with and so feel free to correct my understanding)
Even though this approach looks great on paper, I am not sure how effective it is. In the few domains that I have worked, most of the business roles are contextual (for example - trader on a desk, teller at a bank branch). I have always thought that some of domains like manufacturing and retailing were closer to a standard role based entitlement model because of very well defined processes and role. But thinking more about it, even those may have nuances like supervisor of a specific shop. Similarly most of the IT roles are also context based. For example an admin role in a account management application would probably be given on specific accounts.
At the same time there are definitely applications ( for example any vice president can approve expense report ; show the admin menu only to an administrator) that can be fulfilled by generic roles.
Ultimately the use of NIST RBAC in an application boils down to how complex the role context is within the domain. In case the context is simple enough, it can addressed by building it in to roles so that you may have na_sales_mgr, emea_sales_mgr and so on. But most of us already know that such hacks, if not controlled, can become a recipe for role explosion and would ensure that you need a role management product.
The complexity of the context itself can make the role almost a secondary concept. For example let's take a case of a consulting firm working on large project. Such a project may have separate teams of developers, architects, infra guys spread over multiple geographical locations. Now such a scenario may be uncommon in IT consulting but I think some thing similar would be case in a auditing or investment banking where some of the multi-national M&A deals and company auditing take place. In the example earlier let's say the employee John Doe is assigned role DBA for the developer teams in New york and Seattle for the project Big Bang and Backup DBA for the architect teams in Europe (located in London and Paris) for the project Solve World Hunger. In this example the role itself is such a tiny part of the possible complex context structure (Location hierarchy, teams, etc). Now there may not be that many examples out there with such complexity at the context but at the same time such examples help keeping things in perspective.

To summarize I think we need to be clear about what is the problem we are trying to solve before starting on the role management path. If the end goal is access management then NIST RBAC should be looked at just one of the ways of policy modeling. But if the goal is to get the organizational hierarchy in control, then using a role mining tool to get some roles that are meaningless to business may not be right way to proceed and instead appropriate process must be defined and implemented for organizational hierarchy leaving the IT Roles out of scope.

Preferences and Entitlements

So far I have thought about the Preferences and Entitlements as two separate notions that are not connected to each other. But today while thinking about a few things from work and some blog posts, I realized that there is more to the it than that meets the eye.
Before we go any further let's summarize the definition of terms for the purpose of this discussion

Preference is information that user makes available to resource / application to allow the resource /application to present information in a "user-friendly" manner. (I understand that this is very limited version of preference and there might be other better terms like Persona to describe the same concepts).

Entitlement Model (including model and data) is information that resource / application owner makes available to resource / application so that it can present information that user has access to.

Even though these definitions are not the standard, they are used here to drive the point of view that I am trying to explain. At some level we can view these two things as being about the same thing i.e. annotation of the user-resource mapping / relationship. There are a few implications that I could think of

• Entitlement Modeling as preference source and vise versa - One of the various source for the user preferences that an application can have is Entitlement Model. For example [James McGovern - Relationships and Authorization] - In case the Insurance application has  modeled user's preferences (including relationships and their access levels /roles) in to its entitlement model, his preferences should be taken into account while determining the access for the user's son.


• One way relationship (do we have a word for these things) - If we treat the relationships as preference (i.e. I prefer to call John Doe my friend even though he may prefer to consider me to be an acquaintance) and have a standard way to integrate preferences into entitlement model, relationships can be just another preference that is supported by the entitlement model. Please note that incase preferences are modeled as attributes, downgrading relationships to attributes is something that can come back to bite when there are specific requirements wrt relationships.


• Provisioning - As discussed as part of entitlement and provisioning integration topic earlier, user's attributes for a given application can be based on the entitlement model the application enforces. Now one of the aspect of this is that some of the attributes /relationships being exported by entitlement model to provisioning model can be part of the self-service workflow to be managed as user preference.


• Extending Social Graphs - The relationships and attributes that form part of the identity provider trove, can be further enriched by providing additional preferences or refine the scope of relationships based on resources. For example I can be friend of a person in the context of specific resource (say flickr) but an acquaintance in the context of other resource.
  

Thoughts?

Preferences and Entitlements

So far I have thought about the Preferences and Entitlements as two separate notions that are not connected to each other. But today while thinking about a few things from work and some blog posts, I realized that there is more to the it than that meets the eye.
Before we go any further let's summarize the definition of terms for the purpose of this discussion

Preference is information that user makes available to resource / application to allow the resource /application to present information in a "user-friendly" manner. (I understand that this is very limited version of preference and there might be other better terms like Persona to describe the same concepts).

Entitlement Model (including model and data) is information that resource / application owner makes available to resource / application so that it can present information that user has access to.

Even though these definitions are not the standard, they are used here to drive the point of view that I am trying to explain. At some level we can view these two things as being about the same thing i.e. annotation of the user-resource mapping / relationship. There are a few implications that I could think of

• Entitlement Modeling as preference source and vise versa - One of the various source for the user preferences that an application can have is Entitlement Model. For example [James McGovern - Relationships and Authorization] - In case the Insurance application has  modeled user's preferences (including relationships and their access levels /roles) in to its entitlement model, his preferences should be taken into account while determining the access for the user's son.


• One way relationship (do we have a word for these things) - If we treat the relationships as preference (i.e. I prefer to call John Doe my friend even though he may prefer to consider me to be an acquaintance) and have a standard way to integrate preferences into entitlement model, relationships can be just another preference that is supported by the entitlement model. Please note that incase preferences are modeled as attributes, downgrading relationships to attributes is something that can come back to bite when there are specific requirements wrt relationships.


• Provisioning - As discussed as part of entitlement and provisioning integration topic earlier, user's attributes for a given application can be based on the entitlement model the application enforces. Now one of the aspect of this is that some of the attributes /relationships being exported by entitlement model to provisioning model can be part of the self-service workflow to be managed as user preference.


• Extending Social Graphs - The relationships and attributes that form part of the identity provider trove, can be further enriched by providing additional preferences or refine the scope of relationships based on resources. For example I can be friend of a person in the context of specific resource (say flickr) but an acquaintance in the context of other resource.
  

Thoughts?

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?  

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?  

New kid on the authorization block

I just ran into a new company JResearch Software which is approaching the authorization from the application developer's angle. Their approach is closer to the acegi model but is better geared for an enterprise.  

The whole thing looks pretty promising and could be something that can become more interesting if they go for an opensource model (which should be a big market differentiator) for atleast the core components and start thinking about XACML :)