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.

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.