A directory deployment does not constitute an identity and access management deployment. This may be a bold statement, but I have just had enough of hearing the "we have deployed xyz directory, therefore we have implemented identity and access management".
Clearly there is a huge miscommunication between IT and the business, and the concepts of managing risk and reducing cost are misrepresented by technical folk to business leaders.
Will I ever get to the point of solving this conundrum? Well, hopefully I will succeed with so many others that share this vision. But first some background.
Within the IT environment, what is the difference between identity management, identity and access management, and a user directory?
Identity management
Wikipedia`s definition states: In information systems, identity management, sometimes referred to as identity management systems, is the management of the identity life cycle of entities (subjects or objects).
Identity and access management
According to Wikipedia: This includes the above space as well as the management of user access to objects within a given context. This introduces the concepts of rule or role-based access controls most often seen on Web pages where your role as a Web mail user gives you access to your e-mail box and its supporting functions.
User directory
Again from Wikipedia, using MS Active Directory as an example of a user directory: "Active Directory is an implementation of LDAP directory services by Microsoft for use primarily in Windows environments. The main purpose of Active Directory is to provide central authentication and authorisation services for Windows-based computers."
So, what`s the difference between authentication and authorisation?
Authentication and authorisation
The concepts of managing risk and reducing cost are misrepresented by technical folk to business leaders.
Karel Rode is solutions strategist for CA`s security practice.
Authentication is the act of establishing "realness" or authenticity to a system. We see this during the login process, where we provide a publicly known user name and secret pass code to authenticate to the system.
The authorisation process is used to decide if person, program or device X is allowed to have access to data, functionality or service Y. So by implication, a user may be authenticated to a system but through some form of subversion of the system, gain a higher level of privilege granting access to data, systems or processes that has not been authorised.
With that, back to the start. We need an enterprise directory, as this is a cool place to centrally store user credentials for authentication purposes. Moreover, as such, a directory has the capacity to store other attributes such as job role, location, seniority and many other attributes that can be leveraged for further authorisation purposes.
This then asks the question: how do we feed this information into the directory? Surely with thousands of users, a few administrators and a staff churn of 3% to 8% each month, this could leave residual user attributes that could raise the pen of a sharp IT auditor, more so if there are multiple systems inclusive of Microsoft, Unix and Linux, AS400 and a mainframe.
Did I nearly forget to mention the multiple applications that also store or consume user IDs? Moreover, manually entering and editing this information will introduce an additional correction overhead.
ID management system
An identity management system strives to automate the provisioning (and reverse or de-provisioning) of users from an authoritative source like an HR or payroll system. A well appreciated benefit of such a system will be a user facility were users can self-service password resets and even request access to additional services or assets, with all of it traced by the system, providing an audit trail throughout of who requested what, for how long and who approved/granted access.
Identity and access management system
An identity and access management system takes the above and extends it across all applicable systems to ensure full rule or role-based access is enforced. This also stresses the importance of containing the super user (Windows = administrator, Unix = root) so that they do not exceed their rights. It will be a gross policy violation if I can ask my sys-admin buddy to create me a user account of the payroll system when I am not in HR or finance!
Industry experts say this is all hard to do and very costly. I can agree with that in part, as it is hard to do if you do not get the appropriate buy-in from the right stakeholders.
As for the costs: yes, there will be licensing costs, and the professional services must be included as the company will possibly look at defining new business processes and deploying a workflow system to assist with the automation.
The key thing to ask is if there is a reasonable ROI to be expected of such a system.
I have now proved that the cost of doing nothing and the associated risk will mean a company lags behind the competition, so organisations must start looking at what the market has to offer.
The company`s environmental complexity or lack of complexity, the capability of the systems integrator to deliver and many other factors should impact its decisions.
* Karel Rode is solutions strategist for CA`s security practice.
Share