In my l last post, I discussed the basic concepts of Identity Management. In this post I’m going to talk about the need to clearly identify the business requirements for IAM as a whole and not just to a specific technical need. More often than not IAM projects are spawn to satisfy a specific need, and realistically these today are around the adoption of specific cloud technologies, and Office 365 is the most obvious one.
The issue with doing this is that when you implement a solution for a single purpose without putting any consideration into the “What else” question that is always overlooked. Over the course of my career I’ve discovered that when the next requirement comes up within the business that requires an Identity Management solution, they are often left in a situation which either requires them to completely rebuild the solution that has already been built to provide the initial service offering, or they are required to setup a completely separate environment which then complicates and increases the overall support for the solutions that could have, more often than not, been delivered within the single system.
This brings us back to the title, requirements! So, what are requirements? And why are they so important? Simply put, requirements tell you what you want to achieve within the business with the technology you have or are about to invest in.
When thinking of requirements for any IAM solution, there are basic principles that you should always take into consideration. An IAM solution is built to satisfy 4 basic functions;
- User Management
- Central User Store
When establishing requirements within your business for any IAM solution it’s important to understand these basic functions, and what they could mean for your business. So lets break them down.
Most would say this is pretty self-explanatory, but there’s often a lot more to this than what many think. For example, you want to enable a SaaS application such as TechnologyOne Finance. Do you want to provide a seamless authentication model with Single Sign-On (SSO) or do you want to keep the authentication separate from your local security domains to provide a higher level of security. Do you want to provide more of a Same Sign-On solution where they use their local username and password but are forced to login every time which can be a less inviting end user experience.
Authorization within IAM simply put provides authorization workflows to requests for access to resources or the creation of new resources managed by the IAM solutions. Authorizations ensure that access compliance and government processes are followed with all managed resources.
User management is simply that, it manages the user objects of which it knows about, this includes any add moves or changes that occur to these objects throughout their lifecycle, and when a user leaves the organisation for whatever reason they are terminated through the standard business processes that are established as part of the requirements that have been defined.
Central User Repository
This is effectively where everything is stored, in Microsoft it’s referred to as the metaverse, in the Novell space it’s referred to as the Identity Vault. But it’s simply a central repository of all user objects, as well as the configuration items such as workflows, policy rules as well as various other configuration items.
A common misconception with requirements is technical teams will look for what the technical requirements are to satisfy the solutions which is being built! But this is where things will often go wrong, business requirements come down to simple business logic of what are the primary business objectives. These business requirements will often create a bunch of technical requirements, but it must start with the basic business requirements.
So, to summarise, complex IAM solutions all come down to basic principles, what am I trying to achieve as a business? It is for this reason you need to start with the basics and understand the purpose of the solution being built. You wouldn’t want to build a house without plans or you wouldn’t want to build a road without understanding where it’s going. So why would you do the same with your Identity Management solutions.