Identity and Access Management - Part III Access Management

In past few days a lot of discussions and past memories have resurfaced that has helped me bring together my ideas on the Access management piece of the Identity Access Management. So this is an attempt at putting together all those thoughts and ideas that I have heard from other people and some that I understood. See these locations for more details

1. Tutorial of American National Standard on Role Back Access Control
2. Types of Access Control
3. SACMAT
4. TISSEC(search for access control)

What is Access Control

Access Control is the mechanism by which a resource / object manager restricts the actions / operations that an identified user or Subject (including anonymous users) can perform on a resource or object based on predefined policy. Based on this simple definition we can see that following are the basic components of Access Control

1. Subject The person, process, any physical or logical entity or group of entity who can be identified uniquely in a Access Control system / domain.
2. Object / Resource The resource that the Subject wants to perform some activity on!
3. Action / Operation The activity (verb) that can be performed. These activity are typically valid for particular type of object i.e. you can "read"(action) a "file"(resource) or a "book" but to "read"(action) a "car"(resource) is meaningless in day to day conversation(somebody can always find a deeper meaning in to this type of reading).
4. Policy The policies are basically a system with a set of rules or axioms which have to be followed while making any decisions in a way similar to Riddles

What is Policy, Constraints and Context?

The Policy is a set of rules which are in following format "what actions the subject(s) can or can not perform on various objects under specific constraints" The constraints take into consideration the context in which access control decision is taking place. The policy allows the access control system to answer the following question as a yes, no or indeterminate "Can X(Subject) perform Y(Action) on the Z(Object) in the Context?" The context is additional information about the environment, subject, object and / or action that may be used to make the access decision. Let us take an example to better understand this concept. Lets assume we have access control system which has the following policy John(Subject) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint) Looking at the constraint of the policy we can see how the attribute of ball(color) and environment(time to play) is used to provide the context in which this policy would be valid and thus provides constraint on the policy. So while taking the decision on whether to allow John to play with ball, access control system has to have the idea about what is the time when this decision is being made and what is color of the ball. Now given that we have a policy the we can ask the following questions to access control system "Can Adam(Subject) play(Action) with the ball(Object) given that color of ball is black and it is morning(Context)?" "Can John(Subject) play(Action) with the ball(Object) given that color of ball is blue and it is evening(Context)?" "Can John(Subject) play(Action) with the ball(Object) given that color of ball is black and it is night(Context)?" "Can John(Subject) play(Action) with the ball(Object) given that color of ball is blue(Context)?" "Can John(Subject) keep(Action) the ball(Object) given that color of ball is blue and it is evening(Context)?" "Can John(Subject) play(Action) with the bat(Object) given that color of bat is blue and it is evening(Context)?" This example should give an idea as to why the answers can be yes, no or indeterminate depending on the question asked and policy definition. Some time policy design tries to combine constraints with object or subject or action to achieve a similar policy. For example we can express the policy in the example above so that the policy does not have an explicit constraint and it looks like John(Subject) can play in the evening (Action) with the blue ball(Object) John(Subject) can not play in the evening (Action) with the black ball(Object) John(Subject) can not play in the night (Action) with the red ball(Object) John(Subject) can not play in the night (Action) with the blue ball(Object) Even though it is not a great example but we can see how the same policy can be expressed in variety of ways by choosing granularity of subjects, actions or objects and expression of constraints. This is a very important idea to keep in mind when designing an extensible policy.

Access Control Models

Over time a variety of access control models have evolved and a basic definition of the model can be found here. Over last decade the idea of Role Based Access Control has grown and to some extend reached a mythical status. We should concentrate on this model since this is what is mostly used for implementing access control.

Rule-based Role based Access Control

The RBAC is basically a brilliant idea of inserting another level of abstraction between user and policy so that users are assigned to roles and privilege (combination of action and objects) are assigned to roles. So instead of saying John(Subject) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint) the role Child can be introduced so that A Child(Role) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint) John(Subject) is a A Child(Role) This level of abstraction breaks the security policy into two parts i.e. defining the access control using roles without knowledge of all the users and defining the user - role relationship as the new users are added to the domains without changing the basic access policy. This helps a lot in evaluating the policy to find security holes and potential conflicts in access control. Besides that over time researchers have found that the idea of roles allows to build some additional rules into policy which may not be that simple to express in policies without roles. These additional concepts associated with RBAC are as follows

• Hierarchical Roles[NIST] This basically is the idea of inheritance of roles so that
  • Senior Role acquire privilege of their juniors
  • Junior Role acquires user membership of seniors
  So continuing our example if we define that Child role has 3 senior roles age(0-7), age(8-13), age(14-18) then
  • A Child(Role) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint)
  • John belongs to age(0-7) implies
    1. John(Subject) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint)
    2. John belongs to Child
  The hierarchy can be as complex as required and roles can multiple senior and junior roles or it can follow simpler hierarchy like a role tree(where a role is allowed to have only one senior). Only important thing to remember is that there should not be any cyclic assignment so that a role is a senior and junior of itself due to role hierarchy. Another comment that I would like to make is getting hierarchy of roles correct is typically tough and thus people while designing the role hierarchy should either keep the role structure very flat or use the definition of senior and junior role to evaluate each role so that you do not make basic mistakes (like equating job hierarchy with role hierarchy).
• Separation of Duty(SOD)/ Mutually exclusive roles / Policy Constraints[NIST & TISSEC] This is a very important idea especially in current environment where compliance, conflict of interest and chinese walls are the buzz words. The basic idea with regards to SOD is that some of the actions on the object can not be completed by same person; for example same person can not be accountant and auditor for the same company. The policy constraint is a super set of SOD in the sense that it refers to other constraints that policy must follow. For example a policy may have constraint that a particular role can not have more than 2 users and the access control system should be able to ensure that such rule is considered during role assignment. These policy constraint can be at the following levels
  • User i.e. two person can not belong to same role or have same privilege or a role can not have more than X person / subjects(cardinal constraints). For example two persons can not check-in the same file from the version control system(after being checked out)
  • Role i.e. same person can not belong to two separate roles. For example John can not belong to both age(0-7) and age(8-13)
  • Privilege(Action & Objects) i.e. same person can not have two different privilege. For example John can not belong to both create and approve the same request but he may be able to approve requests created by other user.
  • Constraints i.e. same person can not have two different privilege due to constraints. For example if John can not create requests which will cost less than 500 then he should be able to approve only the requests that are below 500.
  NOTE:The constraint in research papers typically refer to Policy Constraints which are basically set of rules that may be applied at the time of assigning the users to roles or when establishing session(see implementation of SOD). This is different from the constraint that we discussed being part of the rule which are invoked during runtime to evaluate access permission. Even though I have specified the various possibilities above, some of them like constraint level policy constraints is something, I have not seen being discussed in either products or in papers on RBAC or access control for that matter(May be I am missing something). For that matter I have not seen a lot of discussions on constraints, as I have described here, in research papers. The implementation of separation of duty can be done in the following ways
  • Static i.e. policy constraints validation is done at the point of assigning the user to role (a administrative function)
  • Dynamic i.e. policy constraints validation is done at the point of activating the roles for the user. This function is an advance version of Weblogic Role Mapper. So the roles can be selectively "activated" and "deactivated" based on access requirements of the user or additional policy constraints(like both auditor and accountant role can not be activated at the same time or trader role can be active only between 9:30 to 4:30). NOTE: Discussions in literature tie Dynamic activation to User's Session making it similar to Weblogic RoleMapper (or may be I am interpreting it wrong). I think this is a under utilization of this concept (for example trader role where user can continue to have a session with the resource manager in same session but will have his trader role deactivated)

In the end I would just like to put down that RBAC is not solution to all the problems. Not all the policy requirement can be designed using Roles. For example take the case of a trader that is going on vacation and wants to delegates his responsibility to specific user. It would be easier to write a rule using user instead of developing role based access control. So even though the RBAC fits into most of the scenario, lets keep in mind that it does have some limitations.

Group vs. Role

This is a good old debate that keeps coming up given the similarities in the two. See here for a good explanation.

Policy Design

This is really a very large topic and I have not seen any best practice or even an introduction to this field. So this is mostly my understanding based on some experience I have. So basically most of the time the policy design is restricted by the rule design interface provided by the Access Control interface. For example if interface does not allow to use IP of the client in the defining rules then there is not much you can do about it :( So let us see what are the various interfaces that products provide for policy design and implementation.

Access Control List

This is one of the most common access control interface available in wide variety of products. It defines which users have access to what resources in a system. The complexity of the access definition varies a lot. The simpler models allow to define which user has access to what resource. At the same time the complex model may allow to allow or Deny particular action on specific resource for a user or a group. An important point to note is that typically ACL based systems do not allow you to write rule-based constraints. Due to the prevalence of this model, most people start thinking about Access Control using this model, which can be problem if you are designing access control for a rule-based access control engine.

Object Access Policy

This is an access control policy without the identity i.e. the access control applies to all the users. So for example anybody who is accessing a sensitive HR application should be required to sign-in using token authentication. The firewall rules to open specific ports can also be classified as Object Access Policy given that it applies to all the users that are trying to access particular ports of the systems. The implementation of this policy model may allow to write rule-based constraints, but at the same time the complexity of the rule that can be written or the attributes/environment variables that can be used in these rules varies a lot.

Rule-based Role Based Access Control

This seems to be the best combination of all the features of access control and at the same time one of the toughest to get right. A lot of SSO products are moving in this direction with different level of success. At the same time with increasing support for concept of identity in network, the network access control product like firewalls will also grow in this direction. The laws in recent years has made Privacy support in the products very important. The access control is a very important aspect of privacy management (though it has other aspects to it like data anonymity, data encryption and so on) and these privacy management product should also be a very good place to see how access control field evolves. Another evolving field in this area is the Digital Right Management which deals with the idea of how resource interacts with the resource manager to provide access control information which is then enforced by the resource manager. This field should be a good place to see how the things evolve.

Policy Constraints

Most of the policy design is done by using policy language provided by access control system to describe the business rules for accessing the application/resource. But most of the times these access control system comes with a default set of policy constraints(may allow to create these constraints) which must be followed by all the access rules. These constraints could be added to optimize the rules engine, reduce the number of indeterminate results(which may require manual intervention for correction) or to provide better security out-of-box. I will like to briefly put down some of these constraints that I have seen in wild.

• Default Deny/Allow This is the basic policy that defines that if the access for a particular user can not be determined, deny/allow access to that resource automatically. Based on the security or manageability requirements, policy may provide capability to allow or deny by default. So for example if you are at home and some stranger requests your permission comes in, you are most probably going to deny the entry while if you are a casino owner in Las Vegas you are going to allow anybody to enter your premises unless that person does not figure on the Nevada's black book
• Policy Override vs. Policy Inheritance The idea being that if some body has access to your house using a key it may automatically mean that the person has access to your bedroom (the bedroom being the resource that inherits the access control policy from the house), but typically will not have access to your safe which uses a different key( the access control policy of the safe over rides the access control policy of the house). This is not exactly a good example because the identity(i.e. the key to house) is different at each level, but it should give you the basic idea. A slightly better example can be a portal which provides access to a variety of application with each having its own access policy(but application trust portal to provide the identity) which require that you be granted specific permission for access. This means that the access policy of particular application overrides the access policy of the portal. But once you are into that application, the application may allow you to access any resource (policy inheritance by the application resource). This idea is based on the existence of a hierarchy. Even though this hierarchy is mostly used in the context of resources, it can as well be applied to group or roles (role hierarchy is basically the case of policy inheritance).
• Deny overrides Allow This is a basic security constraint (and solves indeterminate cases) that is typically applied by the access control systems. This ensures that if the user has both allow and deny permission based on the policy, the access system will deny the access to the user.
• Insufficient information implies DENY/Allow Some times the policy may require additional information to make a access control decision. For example if a stranger wants to get into your house for some discussion, but is unable to produce an appropriate badge, you may deny him the access. On the other hand, if you are owner of a hotel which is not required by law to verify the identity you may allow customers to stay even though they can not show a valid photo identity like car license(this is very much possible in parts of world, including newyork, where the public transport system is developed to a level that people do not need to have a car license to survive).

I will add more to this as I come across these constraints. Besides these policy level constraints, these are set of constraints that are applicable to resource(s) or role(s). For example a role can have cardinality limit so that a role can not have more than X numbers of subjects assigned or a resource has only specific set of actions that are valid (going back to the example that reading a car does not make sense). This(Section 4) has some good constrainsts as examples. This should give a basic idea about what the access control is all about!! Lets us try to look deeper into what Access Control Systems typically do in terms of implementation of these concepts.

Runtime

Most of the literature talks about two components of the Access Control Runtime i.e.

• Acess Enforcement Point(AEP) which basically is the component of the resource manager that takes the appropriate actions to allows or denies the access to the resource. So for example in case of a Web Server, it could be a plugin that is invoked for every request being made and this plugin takes appropriate actions incase the resource can be accessed(like invoking another component to fetch and return the web page to requestor) or can not be accessed(returns the access denied page). Typically the AEP can be devided into two types
  • Adapters - These are implementation modules that are specifically built to integrate with third party products which have published interfaces.
  • API - The inhouse applications can use this inteface to utilize the ADP functionality without bothering to have to implement it in their product.
• Access Decision Point(ADP) the component of the Resource Manager(or outside the perview of resource manager) which evaluates the policy based on the input from AEP, policy database and additional runtime sources and return whether the Subject should be allowed particular action on the specific resource i.e. it answers the question "Can Subject X perform action Y on Resource Z?"

These two components can communicate with each other using proprietary(like function call, IPC, binary protocols) or standard(XACML). I do not feel that XML is the best mode of communication because most of the time access control systems have to work in high performance environment where XML can be a big drag. At the same time it can be a component of a slower workflow based system which does not have high performance requirements. Another variation of using XACML could be by using its schema to develop a binary schema for query and response. Another important point to remember is the idea that AEP is separate from ADP and thus ADP should authenticate the AEP before it provides the decision or any additional information as the part of the answer. This is an important step to avoid the situation where a rogue AEP can access the ADP to understand the policy model or may even be able to extract information from ADP which can then be used to attack the access control system or the authentication system for specific identity (the idea being that if you know janitor has access to more rooms than CEO then you will try to get access to janitor's identity instead of CEO's identity). Anyway let us try to define a typical use case for the access control system

1. User tries to access a resource through its resource manager.
2. The resource manager's AEP verifies with ADP whether resource can be provided to anonymous user (this step does not take place all the time).
3. If the resource can not be provided, the User is required to identify and authenticated himself through the authentication module
4. After the authentication is completed, user is assigned a credential or a token (valid for the duration of session or specific time) which user can then provide to any access control module familiar with the token. The token allows us to design systems where the authentication and access control systems can exist separately and you are not required to authenticate every time you want to access a resource. This token typically contains all the information associated with the user that should be required to make access control decision (this may require the token generator to access a variety of repository, perform identity and attributemapping to generate a token that has all the relevant information) . This token can be a kerberos ticket on the network or a badge at the convention which allows you to access the premium seminars that you have paid for. Important thing to remember is that a token generated for specific domain is valid only in that domain. So you can not use your blockbluster pass to get access to pentagon. The security of token is a very important thing to be considered while designing them to ensure that token can not be counterfeited. It may also be important to validate the issuer of the token for trust purpose.
5. After it has been provided, the user can provide this token to resource manager for validation and resource manager's AEP, with help of ADP, can decide whether continue with the requested action / operation on the resource. In order to make this decision, besides the user information(typically part of the token) and policy data, the ADP may require additional information about resource and environment (the context of the decision) to make the decision. All the required information may not be available with the ADP and it may need to contact other repositories at runtime to gather all the information and then make the decision. At the sametime the AEP may also provide the information which are more contextual in nature (like client IP address, HTTP Request headers and so on) to ADP to complete the decision making process. This idea of separation of access policy and data required for evaluation is very important and can be exploited to build simpler systems.
6. The decision made by ADP is returned to AEP which will take appropriate action as determined. Some times the ADP may return additional information to AEP along with the decision so that AEP can use the information to provide appropriate resources to requestor. For example, in case of Portal Application, instead of asking "does user have access to Application A?" 100 times for 100 applications, AEP can ask the question "What application does user have access to?" and the ADP can return the information to AEP which can then use this information to paint the portal for the user.

Management

The management of the Access Control deals with

• User Management This deals with management (Creation, Updation and deletion) of User (and associated information), roles and user's assignment to roles. The user information can be managed by the access control system itself or it can be managed in a separate repository and imported in to access control systems via push or pull model. The roles are typically are managed by the access control system and it typically allows to manage roles, their hierarchy and any additional constraints that may be applicable(like separation of duty). The User's assignment to roles can typically either managed by the access control or it can be provided at runtime (as part of the token for example). The static assignments are typically handled by the Access control systems and it may also provide ability to write assignment rules which are evaluated at runtime to get the list of roles that user belongs to (This is not very common so far).
• Resource and action Management This deals with the managing the resource and associated actions. Even though there a variety of ways of modelling resources hierarchy, tree based representation is most common method with each resource with one and only one resource as parent and 0 or more child resources. Action is something which gets tied to the resources and product may provide capability to define the action set that is possible for a type of resource with resource belonging to a resource type.
• Policy Design, storage and replication This is the core of the access control system. This provides the facility to create policies i.e. develop rules which allow or deny user or roles to perform certain actions on the resources under the given constraints. This management function also has to deal with how to store the policy thus developed and the procedure to use for making them available to ADP via push, pull or other model.
• Policy Provisioning In the world of centralized policy management with hetrogenious ADP, the concept of provisioning the policy to these ADP become very important. So the idea is that policies are developed using a single policy model and then these policies are translated to the policy language understood by particular access decision point for enforcement. This can be very tough to achieve especially if features offered by the policy design system are advance than the legacy resource manager which may provide very basic support for Access Control modelling. Such constraints may require remodelling the policy or otherwise may result in partial implementation of access control .
• Data integration even though this has been referred to in user and resource management, it is a very important piece of access control. This defines how the policy engine (ADP) gets the information that it needs during runtime to make the access decision. The data can come from
  1. Requestor - in form of token or any additonal information
  2. Policy Database - most of the policy database have provision to store and manage the information about user, roles, resources, etc. This information can be used at runtime for evaluation.
  3. External/trusted repository - the policy engine may receive data from external repository via push or pull model during evaluation of the policy(at runtime) or in offline mode.
  The management and ensuring the accuracy of the source of data is very important and data conflict may have to be solved (for example requestor and policy database both may have the same data with different values and it may be required to decide which data source take precedence )
• Audit This forms a very important part of the Access Control. Even though most of the products generate some kind of audit, it is mostly left in the archives of the company vault till they can be destroyed according to the policy. But application audit monitoring in conjunction with IDS, IPS, honeypods (Intrusion technology) can be a very strong data mining tools. For example a consistent attack on an application can mean that intruder has been successful in compromizing the internal computer and thus can help to fight the attacks especially the one based on SSL Enabled protocols . At the same time the change in pattern of application audit should work as an alarm. But so far I have not seem at most of my clients any drive to bring these two technologies together and utilize data mining to generate patterns which can then be used by IPS for better management.

This concludes a brief discussion on the access control.