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.