Federated Authorization and Relationship

The post from James McGovern[duckdown.blogspot.com] on federated authorization resulted in response from Pat Patterson[blogs.sun.com] and Paul Madsen[connectid.blogspot.com]. First of all I would like to really thank Paul for providing the link to one of the best docs on entitlements that is out there i.e. Conceptual Grid Authorization Framework and Classification[gridforum.org]. It should be a required reading for all the people who enter in to this domain.

But at the same time, I am disappointed that Paul missed another approach mentioned in the document ( or may be I am missing something). Pat rightly identified the 2 typical models that can be implemented and Paul extended it by coming up with all the permutation and combinations using various components. But all the model discussed look to be various permutation of just one model i.e. Authorization Pull Model where the resource is resposible to connect to the Decision Point to get the result. I think a hybrid of the "Authorization Push Model" and Local policy evaluation is more appropriate for the federation model where along with the identity the authorization of subject itself will flow to the other domain. This is approach is defined by SecPAL[research.microsoft.com] (I hope this will become more mainstream and discussed in near future). In addition to that I would like to see more discussion on other policy languages beside XACML including Cassandra and SecPAL.

Another good point raised by James is the concept of relationship and how that should be part of the identity domain. With the rise of social networking this is a good usecase for the internet identity solutions like openID to solve. I do not think that this is a tough problem and I think that it can be solved by mapping it to an attribute or contextual role problem (similar to who has approver role in the context of given user which everybody is trying to solve in provisioning). But it is important to bring in a standard process for trust establishment and standardize the way in which the relationship are shared between various platforms.

My thoughts on the integration scenarios in next few days.

Federated Authorization and Relationship

The post from James McGovern[duckdown.blogspot.com] on federated authorization resulted in response from Pat Patterson[blogs.sun.com] and Paul Madsen[connectid.blogspot.com]. First of all I would like to really thank Paul for providing the link to one of the best docs on entitlements that is out there i.e. Conceptual Grid Authorization Framework and Classification[gridforum.org]. It should be a required reading for all the people who enter in to this domain.

But at the same time, I am disappointed that Paul missed another approach mentioned in the document ( or may be I am missing something). Pat rightly identified the 2 typical models that can be implemented and Paul extended it by coming up with all the permutation and combinations using various components. But all the model discussed look to be various permutation of just one model i.e. Authorization Pull Model where the resource is resposible to connect to the Decision Point to get the result. I think a hybrid of the "Authorization Push Model" and Local policy evaluation is more appropriate for the federation model where along with the identity the authorization of subject itself will flow to the other domain. This is approach is defined by SecPAL[research.microsoft.com] (I hope this will become more mainstream and discussed in near future). In addition to that I would like to see more discussion on other policy languages beside XACML including Cassandra and SecPAL.

Another good point raised by James is the concept of relationship and how that should be part of the identity domain. With the rise of social networking this is a good usecase for the internet identity solutions like openID to solve. I do not think that this is a tough problem and I think that it can be solved by mapping it to an attribute or contextual role problem (similar to who has approver role in the context of given user which everybody is trying to solve in provisioning). But it is important to bring in a standard process for trust establishment and standardize the way in which the relationship are shared between various platforms.

My thoughts on the integration scenarios in next few days.

Entitlement Management - What are we trying to solve?

It has been 3 months since my last posting and this post has been triggered by a few events. First of all there was a great gathering of Financial Services on various topics including entitlements [senasystems.com] (sorry could not find any other reference to the meeting without the marketing fluff). In addition to that securent (a vendor in entitlement space along with CA, BEA and few others) was out of stealth[internetnews.com] mode which triggered some[zdnet digital id blog] discussion[Connexitor] in the blogosphere but nothing close to what I was have been expecting (most of the people seems to be discussing the "internet identity" way too much[James McGovern] and I guess that is because it is for the people, by the people and hence discussed a lot between the people) to happen in this space. I am guessing that most of the people who are trying to solve the entitlement problem are actually trying to solve it instead of discussing about it in public or discussing with other people who are working in this space without sharing with others. Please note that this does not include James McGovern and few other evangelists that I know of in financial services.

Anyway getting back to the panel discussion, after a good discussion on the topic one of the very good question was what are trying to solve within the entitlement management space. Most of the panelist agreed that taking up centralized and standardized entitlement Administration with centralized and distributed Policy Decision Point was a good start but that it is not an end in itself. There are still use-cases that can break that model (for example applications with very large number of resources that are individually protected or complex User based ACL for users in millions) and would probably be out of scope from such systems. So, what is the solution?

The way I see it, the solution or solutions will depend upon what are the drivers for an enterprise.

For most of the financial services firms, due to the compliance being a very important, visibility is most important driver and then the next in line is control. The visibility means that there should be a way to make the entitlements within a particular system made visible to the auditors, et al. Now this can be achieved by either using the batch mode using standardized policy model (XACML is good start but does not cover everything that is needed) that I described earlier or by making the application provide a standard interface to answer the queries the auditors may have in realtime(each approach has it's own pros and cons and I need to think more about them).

On the other hand if it is the control of the entitlement model which is more important then a centralized and standardized entitlement Administration would be a good way to proceed. Now that in itself means that for each new system, you will have to translate the Admin policy model to application policy model. This policy translation can vary from being very easy for policy model which are very simplistic (for example in case of User ACL  you can just evaluate the policy model for each user and push the result to application entitlement repository) or models that are very close to standardized administration model(which hopefully is a broad model). In case of rest of the applications, the model translation may not be possible since some of the components used for modeling the policy in the administration system may be missing and there may not be any way to translate them to something that the application may understand (this can be mitigated by ensuring that the administration system model does not contain policy constructs which can not be consumed by the application).

In case the driver is getting the security model implementation out of developers hand, then the centralized/distributed Standard Decision Point (and associated policy model administration) may be the way to go or incase of standard container managed systems a Standard Enforcement Point can do the trick.

At the same time in most of the cases there are multiple drivers and so people may have multiple solutions in place to solve the problem.

Anyway what ever are the drivers and corresponding solution set that an enterprise needs or implements, the next step is to integrate with existing Identity Management infrastructure(that's for the next blog entry).

Another good obvious question was how to choose the applications for the new entitlement management platform/solution that people are building and there were some good answers esp. with regards to using the following criteria

1. New Applications are good candidate for the new platform (SOA anyone?)
2. Application that have hit wall w.r.t. entitlements and are themselves looking out at vendors to solve their problems
3. Applications with new audit requirements may be another good candidate for the platform.
4. Evolution vs. Revolution - May be I did not choose the right words but guess the discussion was around the idea of whether you should choose the most difficult/visible application (revolution) and prove the platform or make small gains with well selected non-critical applications. In addition to that most panelist agreed that a good choice could be an apps of low criticality but highly complex policy model which validates the platform and at the same time the setbacks due to initial platform gliches will not become a big mess). One of the participant suggested the idea of using usage footprint with frequency of use to identify the new application.

After you have a platform in place the next step is to evangalize the platform within the enterprise (and even outside). There was a good  discussion on how to go about doing that

• Internal Developers - Even though there was a skeptism about whether Application Developers would accept the new platform as an integral part of application development without "shoving it down their throat", it seems that many enterprise have had a good experience on that side in terms of letting the word about the platform spread through "word of mouth" based on initial success of a few applications.
• Outsourced Development - This is something that can be tackled through standard development process or letting the application architects buy into this platform. But at the same time I think some standardized APIs for Java (no JAAS is not the answer) and .NET may be a good starting point.
• Product Vendors - This is a very important field of people with whom this process needs to be repeated right now so that just like the Web SSO support has become an integral part of the development process, the vendors should have a good understanding of this domain and a well formulated strategy on externalization of policy enforcement/evaluation/administration. 
• Service Providers - This new breed of SAS is something that most people are not thinking about at the moment but may be something that becomes important (may be pushed by federation) going forward.

The session overall provided a good insight into the lack of good understanding of this space not interms of what needs to be done but what is the best way of doing things.

Please note that this post is not a news piece and contains the various concepts from different people as I understood and have been tarnished by my thoughts on the subject (which may be totally wrong).

Hope this helped.

Entitlement Management - What are we trying to solve?

It has been 3 months since my last posting and this post has been triggered by a few events. First of all there was a great gathering of Financial Services on various topics including entitlements [senasystems.com] (sorry could not find any other reference to the meeting without the marketing fluff). In addition to that securent (a vendor in entitlement space along with CA, BEA and few others) was out of stealth[internetnews.com] mode which triggered some[zdnet digital id blog] discussion[Connexitor] in the blogosphere but nothing close to what I was have been expecting (most of the people seems to be discussing the "internet identity" way too much[James McGovern] and I guess that is because it is for the people, by the people and hence discussed a lot between the people) to happen in this space. I am guessing that most of the people who are trying to solve the entitlement problem are actually trying to solve it instead of discussing about it in public or discussing with other people who are working in this space without sharing with others. Please note that this does not include James McGovern and few other evangelists that I know of in financial services.

Anyway getting back to the panel discussion, after a good discussion on the topic one of the very good question was what are trying to solve within the entitlement management space. Most of the panelist agreed that taking up centralized and standardized entitlement Administration with centralized and distributed Policy Decision Point was a good start but that it is not an end in itself. There are still use-cases that can break that model (for example applications with very large number of resources that are individually protected or complex User based ACL for users in millions) and would probably be out of scope from such systems. So, what is the solution?

The way I see it, the solution or solutions will depend upon what are the drivers for an enterprise.

For most of the financial services firms, due to the compliance being a very important, visibility is most important driver and then the next in line is control. The visibility means that there should be a way to make the entitlements within a particular system made visible to the auditors, et al. Now this can be achieved by either using the batch mode using standardized policy model (XACML is good start but does not cover everything that is needed) that I described earlier or by making the application provide a standard interface to answer the queries the auditors may have in realtime(each approach has it's own pros and cons and I need to think more about them).

On the other hand if it is the control of the entitlement model which is more important then a centralized and standardized entitlement Administration would be a good way to proceed. Now that in itself means that for each new system, you will have to translate the Admin policy model to application policy model. This policy translation can vary from being very easy for policy model which are very simplistic (for example in case of User ACL  you can just evaluate the policy model for each user and push the result to application entitlement repository) or models that are very close to standardized administration model(which hopefully is a broad model). In case of rest of the applications, the model translation may not be possible since some of the components used for modeling the policy in the administration system may be missing and there may not be any way to translate them to something that the application may understand (this can be mitigated by ensuring that the administration system model does not contain policy constructs which can not be consumed by the application).

In case the driver is getting the security model implementation out of developers hand, then the centralized/distributed Standard Decision Point (and associated policy model administration) may be the way to go or incase of standard container managed systems a Standard Enforcement Point can do the trick.

At the same time in most of the cases there are multiple drivers and so people may have multiple solutions in place to solve the problem.

Anyway what ever are the drivers and corresponding solution set that an enterprise needs or implements, the next step is to integrate with existing Identity Management infrastructure(that's for the next blog entry).

Another good obvious question was how to choose the applications for the new entitlement management platform/solution that people are building and there were some good answers esp. with regards to using the following criteria

1. New Applications are good candidate for the new platform (SOA anyone?)
2. Application that have hit wall w.r.t. entitlements and are themselves looking out at vendors to solve their problems
3. Applications with new audit requirements may be another good candidate for the platform.
4. Evolution vs. Revolution - May be I did not choose the right words but guess the discussion was around the idea of whether you should choose the most difficult/visible application (revolution) and prove the platform or make small gains with well selected non-critical applications. In addition to that most panelist agreed that a good choice could be an apps of low criticality but highly complex policy model which validates the platform and at the same time the setbacks due to initial platform gliches will not become a big mess). One of the participant suggested the idea of using usage footprint with frequency of use to identify the new application.

After you have a platform in place the next step is to evangalize the platform within the enterprise (and even outside). There was a good  discussion on how to go about doing that

• Internal Developers - Even though there was a skeptism about whether Application Developers would accept the new platform as an integral part of application development without "shoving it down their throat", it seems that many enterprise have had a good experience on that side in terms of letting the word about the platform spread through "word of mouth" based on initial success of a few applications.
• Outsourced Development - This is something that can be tackled through standard development process or letting the application architects buy into this platform. But at the same time I think some standardized APIs for Java (no JAAS is not the answer) and .NET may be a good starting point.
• Product Vendors - This is a very important field of people with whom this process needs to be repeated right now so that just like the Web SSO support has become an integral part of the development process, the vendors should have a good understanding of this domain and a well formulated strategy on externalization of policy enforcement/evaluation/administration. 
• Service Providers - This new breed of SAS is something that most people are not thinking about at the moment but may be something that becomes important (may be pushed by federation) going forward.

The session overall provided a good insight into the lack of good understanding of this space not interms of what needs to be done but what is the best way of doing things.

Please note that this post is not a news piece and contains the various concepts from different people as I understood and have been tarnished by my thoughts on the subject (which may be totally wrong).

Hope this helped.

Representing Authorization Model

I read xacml [James McGovern] entry around representing the authorization model. He has raised a great point on how to translate the authorization use-case narratives in to a simple representations. So far based on the various conversations around the authorization models, I have not been able to find a way to represent the complete authorization model as a diagram. The simple reason being that at the core of the authorization model are business rule and it is tough to represent them as diagram. Let me elaborate on that.

Basically, when you start looking at the authorization use-cases, at a very high level the following components typically form the part of the authorization data model

1. Users and their organization into groups, roles, client organization, etc
2. Resources and their organization into hierarchy, groups, etc
3. Actions and probably some form of their organization
4. Attributes of the user, resources (and may be actions), environment that help perform fine grained evaluation
5. Policies which are the business rules (i.e. a combination of corporate, LOB, application security rules) that bring together the user, resource, actions, their organizations and attributes.

The items 1-4 can probably be represented as diagram (but I still have reservations about representing the business logic for complex organization memberships). Incase of 5, some of the simple like ACLs may be represented using the diagrams. But when it comes to complex rule-based access control, the basic question is how do you represent business rules in diagram? Most of the places that I have seen, the business rules are represented using language and not as diagram (but I am not an expert in business rule representation and would love some pointers in this direction).

Can we use XACML for this purpose? The way I see it, XACML as it stands right now is way too simplistic. It is not appropriate to represent complex authorization patterns satisfactorily. I may get beaten up on this, but I think XACML at this time is more like SOAP of old days without any of the WS-* specifications to standardize the basic cross-cutting requirements. I think over time, through the various profiles (hopefully which are pretty intuitive), we would be able to standardize on more complex patterns which will help us represent the complex authorization models as diagram.

Besides that a very good point raised is around the requirement of mapping the existing authorization model to vendor data model (referred to as reverse engineering if I understood correctly). Now this is a very tricky subject since there is no right way to perform the mapping. Most of the time the application authorization data model  is not built around the simple user, role, resource, action system (unless the architects were really building under the constraints of following that model and the business requirements were simple enough) that automatically translates to the model provided by most of the vendors. The actual translation of the application model to vendor specific model (which vary in their richness and complexity a lot) is dependent on various constraints like

1. Manageability requirements
2. Data location and synchronization
3. Authorization Queries that need to be fulfilled now and in future
4. flexibility required in the future
5. performance of vendor functionality being used
6. and so on....

So, to reiterate there is no single way to transform Application authorization model to a Vendor specific data model and so coming up with a methodology which takes into consideration the various possible issues (like some specified above) is the best way to do it. 

My thought process at this point may look very pessimistic but would love to hear thoughts on this and would like to be part of any initiative that tries to solve this issue.

Thoughts and Next Steps?