Identity and Access Management - Part I Introduction

What Consumer Want or Problem Definition Well sometimes even they don't know! But objectively looking at the problem definition can be stated as :

"Enterprise have a large number of resources that need to be a accessed by a large number of user. With increasing number of resources being accessed by each user and each resource being controlled and managed by business groups, the following is some of the pain each of the party is going through

1. End User pain: the number of identity that the user need to remember to access each resource is increasing
2. Management pain: Management does not have a clue(leave alone controlling) on what user has access to on a day to day basis and they have the auditors / compliance officers breathing down their neck.
3. Operations pain: Operations spending more and more time in correcting the mistakes of the users(like password reset), management(get me report for user access and make sure that all the security policies are followed) and following business workflow and security policies with a possibility of making mistakes due to non-existant end to end tracking system
4. Developer pain(or is it?): Need to write the same code for managing the user information every time a new application needs identity and access management.
5. Resource owner's pain : As a resource/data owner they need to be able to control who can access the information while following specific policy for access.

The availability of the identity, access and resource management as a service which can be tapped into by the business groups may be a way to solve everybody pain"

Before we continue on this topic I would like to bring out the basic idea of a security / Identity Domain. Basically, it extends from the very common idea of defining scope of the system. This domain can be a single department, multiple departments, a single enterprise or multi-enterprise. It is very important to define the domain and keep that in mind while understanding the requirements. So basically this needs to be achieved taking in to consideration that there are three aspect of the R.A.ID Management( ;-) ).

1. Resource: this, at the moment, needs to evolve as a concept. The products have concentrated on the I.T. Resources(provisioning for server, database, ERP or other third party product) and, in some cases, User Data (privacy manager), but at the same time resources can be any asset like IP address, Multicast address, in-house application(and associated data), web services, etc.
2. IDentity: This is the something that seem to be the center of attraction at the moment. The basic concept being that every physical / logical entity that needs to be identified has to have a unique identifier in the domain. This identifier must then be mapped to all the digital representations in various applications / resources / Tiers / roles in the domain. Typically these identities have associated information which is referred to as user information / attributes, password, users' application data, etc. People have tried to define the concept of identity as three tier models and you can check out the link for complete discussion on the subject. I do not "get it" completely but I will re-visit this topic.
3. Access Control: This bring together the identity and resource. The most popular model of access control is based on the two component system - Access Enforcement Point and Access Decision Point When ever the user tries to access a resource, the resource manager(entity that interacts with client and serves the resource) or a associated component acts as an "Access Enforcement Point". It needs to know

   "Is User X Granted Permission Y On Resource Z?"

   The "Access Enforce Point" typically defers the question evaluation to an "Access Decision Point" which has the access policies that enable it to make the decision and return back result to caller. A typical policy may be of the following form

   "GRANT|DENY User|{Static or Dynamic Group} X Permission Y on Resource Z if constraint is true"

   I will expand on this concept later(TODO - Add URL). These policies and additional information should be available at the Access Decision Point so that it can evaluate the query and return information.

In the next sections I will take each of the component separately and discuss the concepts around each of them. There would be 3 sections about each component.

• Concepts This will discuss the basic concepts associated with each of the component and important ideas that should be kept in mind.
• Runtime This section will discuss the typical components that are come into the play at runtime.
• Management This section will discuss the typical concepts associated with managing the component