Cisco Acquires Securent

Why? Many people [Burton group] who [Ian Glazer] are[Jackson Shaw] more[Dave Kearns] qualified[Forrester] than[Ian Yip] me have expressed their opinion on this subject.
The main reason for the acquisition proposed -

1. Cisco has finally seen the light and decided to enter the IAM space - I do not think this makes much sense given that they are not a software stack company, not even a software infrastructure company (like Symantec, Oracle, SAP, etc).
   
2. Cisco needed a product to build identity based authorization into network and hence all its products - I think it is a result of reading too much by us entitlement management guys in to it and the way we would like to see the world.
   

Externalization of Security
Reading in to the fact that product has been placed in Collaboration Service Group and created a separate policy group, it looks like Cisco sees the product as a quick way to externalize the policy management from the various collaborative products. Another important aspect of these product (esp SaaS) is that security for these product is managed by End-users.

Most of the web based application vendors (who do not sell security products) have been able to successfully externalize the authentication (support for sso, saml) and user repository (LDAP) but do not have a good model to replicate in the authorization space. If the result of this externalization of authorization across multiple application is successful, vendors will have a model to replicate. This will be a very big win for various enterprises that have been trying to drill this into vendor's head (James McGovern being one of them).
But I think this is a tougher problem to solve than externalization of authentication and user repository (which are mostly one time job). I see the following problems

1. If externalization is being performed at administration level, then how do you expose widely different access control model (a SaaS site's model would probably be very different from Web Conferencing / IP Phones access model) through same interface without sacrificing usability, flexibility and asking users to learn a new policy language.
2. If standardization/externalization is being performed at evaluation level, then how do you meet different performance requirements of different access control models through same generic engine. In addition to that keeping different implementations (on different platforms) for same policy evaluation algorithm with various performance tweaks can be tough.
   

Impressive Team and great execution
I am amazed by how everybody has seen it as a complete technology acquisition and has not given enough credit to Cisco for investing into the team (may be they know something that I do not know about how acquisitions work). The complete team starting from Rajiv Gupta to their pre-sales team members have time and again been giving pretty impressive performance during various meetings with their (potential) clients. In addition to that if any body has been tracking securent over past 1.5-2 years, it is amazing how their sales and marketing team (biz dev) have taken a "would-be" space of authorization to a happening space and recreated a whole domain of entitlement management so much so that this year can aptly be said to be year of entitlement management atleast in terms of hype that was generated (I have never seen so many people clamoring to jump on to third-party entitlement bandwagon in financial services). I would really love to see this team take on a bigger challenges like Salesforce :) To me that could be a great reason in itself to buy the company instead of OEMing the product (beside the obvious reason that there is always the issue of OEMing from a small vendor which may be gone or bought by a competitor).

What Next?
Well looks like Securent is getting ready to be subsumed by Cisco and hopefully, in a year or two, we would have somebody from their team coming to burton group conference (or some other entitlement confrence) to discuss how their attempt to externalize the security from their collaboration software went and we all will have a good use-case to learn from.

With the economy in US having a few hiccups and a possibility that SOX (one of the primary driver for various iam initiatives at this point) may be blamed for all economic problems, the info sec across the enterprises may be fighting a tough battle to get their company's entitlements in order (as soon as they get their user directory, authentication, provisioning in order). In addition to that the big vendors are expected to come out with new offerings in this domain which would make survival of new and existing company tougher. So, will we see a new startup in fine grain authorization space? I sincerely hope so and would love to see them grow and find a new niche in this space because as I see it the problems have just become tougher to solve.

Cisco Acquires Securent

Why? Many people [Burton group] who [Ian Glazer] are[Jackson Shaw] more[Dave Kearns] qualified[Forrester] than[Ian Yip] me have expressed their opinion on this subject.
The main reason for the acquisition proposed -

1. Cisco has finally seen the light and decided to enter the IAM space - I do not think this makes much sense given that they are not a software stack company, not even a software infrastructure company (like Symantec, Oracle, SAP, etc).
   
2. Cisco needed a product to build identity based authorization into network and hence all its products - I think it is a result of reading too much by us entitlement management guys in to it and the way we would like to see the world.
   

Externalization of Security
Reading in to the fact that product has been placed in Collaboration Service Group and created a separate policy group, it looks like Cisco sees the product as a quick way to externalize the policy management from the various collaborative products. Another important aspect of these product (esp SaaS) is that security for these product is managed by End-users.

Most of the web based application vendors (who do not sell security products) have been able to successfully externalize the authentication (support for sso, saml) and user repository (LDAP) but do not have a good model to replicate in the authorization space. If the result of this externalization of authorization across multiple application is successful, vendors will have a model to replicate. This will be a very big win for various enterprises that have been trying to drill this into vendor's head (James McGovern being one of them).
But I think this is a tougher problem to solve than externalization of authentication and user repository (which are mostly one time job). I see the following problems

1. If externalization is being performed at administration level, then how do you expose widely different access control model (a SaaS site's model would probably be very different from Web Conferencing / IP Phones access model) through same interface without sacrificing usability, flexibility and asking users to learn a new policy language.
2. If standardization/externalization is being performed at evaluation level, then how do you meet different performance requirements of different access control models through same generic engine. In addition to that keeping different implementations (on different platforms) for same policy evaluation algorithm with various performance tweaks can be tough.
   

Impressive Team and great execution
I am amazed by how everybody has seen it as a complete technology acquisition and has not given enough credit to Cisco for investing into the team (may be they know something that I do not know about how acquisitions work). The complete team starting from Rajiv Gupta to their pre-sales team members have time and again been giving pretty impressive performance during various meetings with their (potential) clients. In addition to that if any body has been tracking securent over past 1.5-2 years, it is amazing how their sales and marketing team (biz dev) have taken a "would-be" space of authorization to a happening space and recreated a whole domain of entitlement management so much so that this year can aptly be said to be year of entitlement management atleast in terms of hype that was generated (I have never seen so many people clamoring to jump on to third-party entitlement bandwagon in financial services). I would really love to see this team take on a bigger challenges like Salesforce :) To me that could be a great reason in itself to buy the company instead of OEMing the product (beside the obvious reason that there is always the issue of OEMing from a small vendor which may be gone or bought by a competitor).

What Next?
Well looks like Securent is getting ready to be subsumed by Cisco and hopefully, in a year or two, we would have somebody from their team coming to burton group conference (or some other entitlement confrence) to discuss how their attempt to externalize the security from their collaboration software went and we all will have a good use-case to learn from.

With the economy in US having a few hiccups and a possibility that SOX (one of the primary driver for various iam initiatives at this point) may be blamed for all economic problems, the info sec across the enterprises may be fighting a tough battle to get their company's entitlements in order (as soon as they get their user directory, authentication, provisioning in order). In addition to that the big vendors are expected to come out with new offerings in this domain which would make survival of new and existing company tougher. So, will we see a new startup in fine grain authorization space? I sincerely hope so and would love to see them grow and find a new niche in this space because as I see it the problems have just become tougher to solve.

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 :)

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 :)

Food for thought

• Rise of centralized password management and dispension system - With the rise of centralized password management and dispension systems (like Cyber-ark Enterprise Password Vault, Symark Powerkeeper do we need to rethink how the applications handle password storage and operations (like saving password as clear or some reading password from a file for the SSL keys). Obviously the idea is that after people have taken care of standard passwords for their systems, they would like to integrate the applications to leaverage password storage and dispension.
•  Enterprise Rights Management on Fine grained authorization management and XACML - I have not heard anybody talking about it (may be I am not looking in right place) but isn't it odd that two systems that seem to do the same thing (except the ERM seems to be more of an PEP implementation which also has PDP aspect to it). So, it would be interesting to see how ERM can play well with Fine-grained authorization and XACML.

Food for thought

• Rise of centralized password management and dispension system - With the rise of centralized password management and dispension systems (like Cyber-ark Enterprise Password Vault, Symark Powerkeeper do we need to rethink how the applications handle password storage and operations (like saving password as clear or some reading password from a file for the SSL keys). Obviously the idea is that after people have taken care of standard passwords for their systems, they would like to integrate the applications to leaverage password storage and dispension.
•  Enterprise Rights Management on Fine grained authorization management and XACML - I have not heard anybody talking about it (may be I am not looking in right place) but isn't it odd that two systems that seem to do the same thing (except the ERM seems to be more of an PEP implementation which also has PDP aspect to it). So, it would be interesting to see how ERM can play well with Fine-grained authorization and XACML.

AAAA and A in Service World

There are two aspects of Authentication, Authorization, Auditing in the services world. The first aspect (and probably the more difficult from implementation perspective) is integration of the AAA as a cross cutting pattern in to the container, middleware (ESB, MOM, etc), etc to take it out of the service functionality itself and the other being development of AAA &A as service. The first half at this point is an integration nightmare due to no standards available or inadequate standards (like JAAS) or lack of vendors initiatives (like XACML, WS-Trust, Liberty ID-WSF Authentication service) due to either ignorance or no push from clients. I know it is a generalization of the current state but that is not what I would like to cover.

On the service side, the Authentication, Authorization, Auditing, Attribute (and role) and Administrative capabilities have been built into the infrastructure but very few have been deploying it as a service. I think that deploying authentication (RADIUS, TACACS+, etc) and auditing(SNMP, syslog, etc) as a service is pretty well understood. But I do not know of such implementations in case of authorization or attribute. The post [James McGovern] seems to point to fact that AAAA&A in the "SOA" world may need to be better defined and there may be possibility to define their capabilities in a more general way than currently available in the literature.

This post is a dump of my thoughts based on what I have seen others do and how I think people could build services out of their infrastructure components. This attempt to put down my understanding is by no means complete and does not delve into implementation issues. It is a very high level overview which I would like to build on as I gather better understanding of such implementations. The basic approach that I have used to understand the requirements in service world  is that a service will consists of

1. protocols (and middleware) it supports to allow clients to access the
2. functionality it provides

Authentication

The basic functionality of the authentication is well discussed and is about identifying user (person, organization, entity, process) and validating that it and the authenticating entity know about  the same secret (credential, shared secret, key pair, ...).

Functionality

The following functionality would probably be provided by these authenticated service.

• Single and Multi-factor Authentication using multiple protocols and repositories (Database, LDAP, SecurID, Kerberos, RADIUS) - In a way the authentication service is a "virtual directory" like interface for authentication into many repositories that support multiple access protocols.
• Identity/Credential/Token Mapping - This seems to be a good functionality to have with so many products out there that support different types of tokens.
• Token Validation - The basic idea being that once the token has been created, it needs to be validated by each service container and then appropriate subject information can be made available to the service functionality.
• Auditing - This is an obvious one. You would probably want to know who authenticated when for what service using which authentication mode and what was the result. Now all the information may not be available for each of the supported authentication modes due to limitation of protocol itself and would need to be dealt with. In addition to that incase authentication process triggered any other events (like account lockouts, session establishment, etc), it would be good to have that information also captured. 
• Session Management - This is something I am not sure about. The session as a separate service may be something that may be interesting from many perspective (like tracking information about state of user across multiple services and share information between them) but I do not know of any initiative in the industry to standardize that (which may be the case of my ignorance more than anything else). In addition to that most of the standards (like federation) typically build some level of session management into their protocols.

Protocol (& Middleware) Supported

Now based on the most of the common protocols in use today, the following would probably have to be supported by such an authentication service.

• Browser Profiles (Cookie based) - This is a good way to simplify authentication for anybody who would like to connect to various browser based interfaces (including AJAX services). But one of the issue that I see is that most of the web sso implementations in past were not implemented with this architecture in mind. They were mostly based on idea of authentication service being embedded in the enforcement point and so it may be tough for some of these implementations to leverage the authentication service in this mode. This would typically involve the typical ID/Password, URL based Ids, SPNEGO, PKI based, biometric and new Risk based strong authentication techniques.
• Browser and Web-service Profiles for Federated authentication - This is important for support of the various federated authentications like SAML, WS-Federation.
• LDAP based authentication - Given that this is probably one of the most widely supported authentication protocol by third-party software, it may be good to have the service support it.
• Kerberos based authentication - There are a lot of third party products and organizations that built SSO infrastructure over Kerberos which was probably the first SSO technology.
• WS - Trust - Since this is the most widely accepted Token mapping protocol, it would be good to have this. Now one of the things that I am not clear is whether this protocol can support identity mapping itself (even though I remember some of the federation products leveraging this protocol to do that) as part of standard itself.
• Liberty Identity Mapping Service - I am not sure how widely used this one is but may be worth having from the point of view that many telecom providers (esp in wireless market) are building services based on Liberty alliance.

With regards to many of the new  protocol standards, the level of interoperability is still questionable but hopefully this will get better time.

Authorization/Access Control

Building the authorization functionality as a service is something I am not sure about. Even though I have seen people build really successful services (for example Disney), it is always questionable how well such a service will work under high performance requirements. In addition to that I do not see access control as a loosely coupled service which seems to be one of the guiding principles of "SOA" world. Anyway, having this functionality as service allows multiple applications (oops I mean services) to share same infrastructure, gives management and auditors(?) some peace of mind with regards to controllability (but that is not completely possible unless the PEP itself is centrally controlled).

Functionality

The following functionality would probably be good to have in such a service

• Basic Authorization - Basically the service must be able to answer the question
  • Can the user U perform the action A on the given resource R in the environment/context E(location, time, transaction data)?
  • What are the resources on which the user U can perform the action A in the environment/context E?
  • What are the actions that the user U can perform on the resource R in the environment/context E?
  • Who can perform the action A on the resource R in the environment/context E?
• Relationship-based Authorization - This covers the queries where the authorization itself is dependent upon an existing relationship between the various entities. For example
  • Can two Users perform the action A on the resource  R in the environment/context E. For example in case of financial industry where the Chinese wall policy dictates that an investment banking employee can not talk to equities or research analyst, it is required that before two persons can join a chat room the system must evaluate whether the User X can perform join the chat room Z given there are other users A,B,C?
• Auditing - Another obvious one to capture. It would involve auditing who tried to perform what action on which resource at what time and under what context and what was the result.
• Business Policy translation - The service must be able to consume business policy and convert it in to the runtime policy for enforcement. Most of the current product are not able to fulfill this functionality and can only consume a policy based on pre-configured data model. This implies that policy lifecycle management is not user friendly and is prone to errors (due to the user interpretation involved).
• Delegation - The service must ensure that it can support delegation as a first hand concept and use it.

Protocol Supported

• XACML - right now this protocol seems to be the only game in the town. It does not provide any thing beyond basic request/response and policy definition model. For example most of the authorization queries specified above are currently not supported. The supported policy constructs is also very limited (for example AFAIK separation of duty concept is not defined by the policy) and hopefully that will improve as we go further.
• Others - Given that academia has moved to XACML (and is extending it as needed) as the default policy language, there is not many new policy language in works. There are a few interesting ones like SecPAL and Cassandra (which seems to be predecessor of SecPAL) which are in labs and with a uncertain future.

Auditing

The auditing service is basically an attempt to provide a central service to allow the various services to send their audit events so that a separate infrastructure is not needed to collect the audit information from each service which may be writing to a local file system. Even though the audit systems are mostly designed as passive acceptor of data, it may be possible to develop more active auditing systems which may perform event correlation in real-time against the usage policy and use the auditing channel itself to flag an alert back to the service (along with other people) and thus manage the quality of service. This is not a traditional role of auditing channel and it may be better to let other service provide this capability.

Functionality

The basic functionality that needs to be provided by auditing service

• Audit Data Storage - This is the basic functionality that auditing needs to be provided.
• Data integrity and availability - This is probably an important aspect of auditing system which is important from reporting perspective.
• Reporting - Though not a required functionality (given that there are existing reporting products out there), it is a nice to have.
• Analytics & Monitoring - This may be an important functionality to built into auditing service or as separate service which can be used by auditing service if being used in active mode.
• User Session Event Flow - Auditing service may provide a way to trace an event or user session flow in real time and get the appropriate people involved as needed.

Protocols

Only standard protocols that I know of in this space are Syslog, SNMP and WS -Management. But other aspect of the protocol which seems to be missing is the standardization of the event data format. I do not know of any standards or initiative to standardize the format/content of the security events generated by various components for easy correlation in terms of event and session flow.

Attribute, Role and Relationship (Identity Data Service)

This service is typically not part of standard AAA&A model but with growing interest in controling and managing the identity data in a more formal way, this could be a good service to have to provide interface for the various types of identity data for employees, clients (persons and organization) and their roles, relationships which are of interest. At some places I have seen this being developed more for business of CRM and HR but hopefully these services would be built in a manner which will allow people to leaverage them across the firm in an identity centric way.

Functionality

 As of now I do not complete understand the scope and functionality this service may provide but these are a few thoughts.

• User Data - This basically means that for the given identity give me the specified attributes.
• Data Assertions - This service ensure that instead of providing the raw data about an identity, the system must provide response to the specific queries that service has to fulfill its functionality. For example instead of providing the age of the user, the Identity data service would respond to the query "Is the user over age of 18?" with yes or no. In order to do so, the service may need to be able to consume CARML properties and correlate it to appropriate user data and rules for evaluation.  
• Personal Identifiable Information Access Check - This is an obvious one in terms of making sure that services get access to only the specific information that they need so that the unix login service does not have access to the SSN unless there is a specific need for that. This woudl require that the service be able to consume AAPML documents and use it to perform access check. But it may be better to perform the access check in the authorization service and then enforce the decision so as not to duplicate the functionality.
• Roles - So far I have not seen much discussion on developing a role service. Most of the role management product do help in creating roles and managing the users assignment to these roles. But the basic problem of delivering this information to the application for runtime consumption is either left up to the web SSO, authorization product, shared repository (like directory or database) or even provisioned to the application itself.
• Contextual/Parameterized Roles (relationship) - The contextual/parameterized roles are the role that a user has in a specific context. For example a user D can have "doctor" role in the context of User X while have "patient" role in the context of User DR. Relationships are contextual roles in which the context is one or more user(s).

Protocols

I do not know of any standard which supports the roles (basic and contextual) as first hand entities. The following protocols could be supported by such a service

• SAML
• Liberty ID-WSF Interaction Service
• CARML

Administration

The administration service is a cross cutting concern that affects all the above service inthe sense that each of these have an administration component. The administration service is big enough to be dealt separately in next post.

AAAA and A in Service World

There are two aspects of Authentication, Authorization, Auditing in the services world. The first aspect (and probably the more difficult from implementation perspective) is integration of the AAA as a cross cutting pattern in to the container, middleware (ESB, MOM, etc(, etc to take it out of the service functionality itself and the other being development of AAA &A as service. The first half at this point is an integration nightmare due to no standards available or inadequate standards (like JAAS) or lack of vendors initiatives (like XACML, WS-Trust, Liberty ID-WSF Authentication service) due to either ignorance or no push from clients. I know it is a generalization of the current state but that is not what I would like to cover.

On the service side, the Authentication, Authorization, Auditing, Attribute (and role) and Administrative capabilities have been built into the infrastructure but very few have been deploying it as a service. I think that deploying authentication (RADIUS, TACACS+, etc) and auditing(SNMP, syslog, etc) as a service is pretty well understood. But I do not know of such implementations in case of authorization or attribute. The post [James McGovern] seems to point to fact that AAAA&A in the "SOA" world may need to be better defined and there may be possibility to define their capabilities in a more general way than currently available in the literature.

This post is a dump of my thoughts based on what I have seen others do and how I think people could build services out of their infrastructure components. This attempt to put down my understanding is by no means complete and does not delve into implementation issues. It is a very high level overview which I would like to build on as I gather better understanding of such implementations. The basic approach that I have used to understand the requirements in service world  is that a service will consists of

1. protocols (and middleware) it supports to allow clients to access the
2. functionality it provides

Authentication

The basic functionality of the authentication is well discussed and is about identifying user (person, organization, entity, process) and validating that it and the authenticating entity know about  the same secret (credential, shared secret, key pair, ...).

Functionality

The following functionality would probably be provided by these authenticated service.

• Single and Multi-factor Authentication using multiple protocols and repositories (Database, LDAP, SecurID, Kerberos, RADIUS) - In a way the authentication service is a "virtual directory" like interface for authentication into many repositories that support multiple access protocols.
• Identity/Credential/Token Mapping - This seems to be a good functionality to have with so many products out there that support different types of tokens.
• Token Validation - The basic idea being that once the token has been created, it needs to be validated by each service container and then appropriate subject information can be made available to the service functionality.
• Auditing - This is an obvious one. You would probably want to know who authenticated when for what service using which authentication mode and what was the result. Now all the information may not be available for each of the supported authentication modes due to limitation of protocol itself and would need to be dealt with. In addition to that incase authentication process triggered any other events (like account lockouts, session establishment, etc), it would be good to have that information also captured. 
• Session Management - This is something I am not sure about. The session as a separate service may be something that may be interesting from many perspective (like tracking information about state of user across multiple services and share information between them) but I do not know of any initiative in the industry to standardize that (which may be the case of my ignorance more than anything else). In addition to that most of the standards (like federation) typically build some level of session management into their protocols.

Protocol (& Middleware) Supported

Now based on the most of the common protocols in use today, the following would probably have to be supported by such an authentication service.

• Browser Profiles (Cookie based) - This is a good way to simplify authentication for anybody who would like to connect to various browser based interfaces (including AJAX services). But one of the issue that I see is that most of the web sso implementations in past were not implemented with this architecture in mind. They were mostly based on idea of authentication service being embedded in the enforcement point and so it may be tough for some of these implementations to leverage the authentication service in this mode. This would typically involve the typical ID/Password, URL based Ids, SPNEGO, PKI based, biometric and new Risk based strong authentication techniques.
• Browser and Web-service Profiles for Federated authentication - This is important for support of the various federated authentications like SAML, WS-Federation.
• LDAP based authentication - Given that this is probably one of the most widely supported authentication protocol by third-party software, it may be good to have the service support it.
• Kerberos based authentication - There are a lot of third party products and organizations that built SSO infrastructure over Kerberos which was probably the first SSO technology.
• WS - Trust - Since this is the most widely accepted Token mapping protocol, it would be good to have this. Now one of the things that I am not clear is whether this protocol can support identity mapping itself (even though I remember some of the federation products leveraging this protocol to do that) as part of standard itself.
• Liberty Identity Mapping Service - I am not sure how widely used this one is but may be worth having from the point of view that many telecom providers (esp in wireless market) are building services based on Liberty alliance.

With regards to many of the new  protocol standards, the level of interoperability is still questionable but hopefully this will get better time.

Authorization/Access Control

Building the authorization functionality as a service is something I am not sure about. Even though I have seen people build really successful services (for example Disney), it is always questionable how well such a service will work under high performance requirements. In addition to that I do not see access control as a loosely coupled service which seems to be one of the guiding principles of "SOA" world. Anyway, having this functionality as service allows multiple applications (oops I mean services) to share same infrastructure, gives management and auditors(?) some peace of mind with regards to controllability (but that is not completely possible unless the PEP itself is centrally controlled).

Functionality

The following functionality would probably be good to have in such a service

• Basic Authorization - Basically the service must be able to answer the question
  • Can the user U perform the action A on the given resource R in the environment/context E(location, time, transaction data)?
  • What are the resources on which the user U can perform the action A in the environment/context E?
  • What are the actions that the user U can perform on the resource R in the environment/context E?
  • Who can perform the action A on the resource R in the environment/context E?
• Relationship-based Authorization - This covers the queries where the authorization itself is dependent upon an existing relationship between the various entities. For example
  • Can two Users perform the action A on the resource  R in the environment/context E. For example in case of financial industry where the Chinese wall policy dictates that an investment banking employee can not talk to equities or research analyst, it is required that before two persons can join a chat room the system must evaluate whether the User X can perform join the chat room Z given there are other users A,B,C?
• Auditing - Another obvious one to capture. It would involve auditing who tried to perform what action on which resource at what time and under what context and what was the result.
• Business Policy translation - The service must be able to consume business policy and convert it in to the runtime policy for enforcement. Most of the current product are not able to fulfill this functionality and can only consume a policy based on pre-configured data model. This implies that policy lifecycle management is not user friendly and is prone to errors (due to the user interpretation involved).
• Delegation - The service must ensure that it can support delegation as a first hand concept and use it.

Protocol Supported

• XACML - right now this protocol seems to be the only game in the town. It does not provide any thing beyond basic request/response and policy definition model. For example most of the authorization queries specified above are currently not supported. The supported policy constructs is also very limited (for example AFAIK separation of duty concept is not defined by the policy) and hopefully that will improve as we go further.
• Others - Given that academia has moved to XACML (and is extending it as needed) as the default policy language, there is not many new policy language in works. There are a few interesting ones like SecPAL and Cassandra (which seems to be predecessor of SecPAL) which are in labs and with a uncertain future.

Auditing

The auditing service is basically an attempt to provide a central service to allow the various services to send their audit events so that a separate infrastructure is not needed to collect the audit information from each service which may be writing to a local file system. Even though the audit systems are mostly designed as passive acceptor of data, it may be possible to develop more active auditing systems which may perform event correlation in real-time against the usage policy and use the auditing channel itself to flag an alert back to the service (along with other people) and thus manage the quality of service. This is not a traditional role of auditing channel and it may be better to let other service provide this capability.

Functionality

The basic functionality that needs to be provided by auditing service

• Audit Data Storage - This is the basic functionality that auditing needs to be provided.
• Data integrity and availability - This is probably an important aspect of auditing system which is important from reporting perspective.
• Reporting - Though not a required functionality (given that there are existing reporting products out there), it is a nice to have.
• Analytics & Monitoring - This may be an important functionality to built into auditing service or as separate service which can be used by auditing service if being used in active mode.
• User Session Event Flow - Auditing service may provide a way to trace an event or user session flow in real time and get the appropriate people involved as needed.

Protocols

Only standard protocols that I know of in this space are Syslog, SNMP and WS -Management. But other aspect of the protocol which seems to be missing is the standardization of the event data format. I do not know of any standards or initiative to standardize the format/content of the security events generated by various components for easy correlation in terms of event and session flow.

Attribute, Role and Relationship (Identity Data Service)

This service is typically not part of standard AAA&A model but with growing interest in controling and managing the identity data in a more formal way, this could be a good service to have to provide interface for the various types of identity data for employees, clients (persons and organization) and their roles, relationships which are of interest. At some places I have seen this being developed more for business of CRM and HR but hopefully these services would be built in a manner which will allow people to leaverage them across the firm in an identity centric way.

Functionality

 As of now I do not complete understand the scope and functionality this service may provide but these are a few thoughts.

• User Data - This basically means that for the given identity give me the specified attributes.
• Data Assertions - This service ensure that instead of providing the raw data about an identity, the system must provide response to the specific queries that service has to fulfill its functionality. For example instead of providing the age of the user, the Identity data service would respond to the query "Is the user over age of 18?" with yes or no. In order to do so, the service may need to be able to consume CARML properties and correlate it to appropriate user data and rules for evaluation.  
• Personal Identifiable Information Access Check - This is an obvious one in terms of making sure that services get access to only the specific information that they need so that the unix login service does not have access to the SSN unless there is a specific need for that. This woudl require that the service be able to consume AAPML documents and use it to perform access check. But it may be better to perform the access check in the authorization service and then enforce the decision so as not to duplicate the functionality.
• Roles - So far I have not seen much discussion on developing a role service. Most of the role management product do help in creating roles and managing the users assignment to these roles. But the basic problem of delivering this information to the application for runtime consumption is either left up to the web SSO, authorization product, shared repository (like directory or database) or even provisioned to the application itself.
• Contextual/Parameterized Roles (relationship) - The contextual/parameterized roles are the role that a user has in a specific context. For example a user D can have "doctor" role in the context of User X while have "patient" role in the context of User DR. Relationships are contextual roles in which the context is one or more user(s).

Protocols

I do not know of any standard which supports the roles (basic and contextual) as first hand entities. The following protocols could be supported by such a service

• SAML
• Liberty ID-WSF Interaction Service
• CARML

Administration

The administration service is a cross cutting concern that affects all the above service inthe sense that each of these have an administration component. The administration service is big enough to be dealt separately in next post.