Identity management is an overarching term for the organisational practices and procedures concerned with managing identity. Crystal clear, right? Tautologies aside, identity management is a broad topic that is simple in theory. However, in practice, there is so much to cover.
But in order to uncover how identity management solutions are transforming business, let’s first make sure everyone is on the same page. We’ll quickly cover the fundamentals of identity management. And hopefully, inject some substance into the buzzwords.
To gain a foothold on identity management, however, we first need to cover authentication and authorisation. With a little mental gymnastics, most aspects of identity management will fit into one of these two concepts.
Authentication vs Authorisation
A sensible identity management solution will authenticate the user before they are authorised. Why? Well, you should know who you are dealing with before you work out if they are allowed to access the resource that they are requesting.
Although identities are stored on servers, and enforced by software, there is a crossover between the fundamental concepts of an identity management solution and how you would check someone’s identity in person.
Say, for instance, you are trying to gain access to a bar. Firstly, security will check your ID. They are authenticating you. Now that the bouncer knows who you are, they should let you in? But hang on. Before you are granted access, the bouncer will first need to check you are over 18 and that you aren’t seriously intoxicated. This is the bar’s authorisation process. Their access policy, if you will.
The Origin of Identity Management Solutions
Our online identities aren’t standardised like our physical identity. There is no state-issued ID that’s accepted everywhere you go online, in the same way we use our driver’s licence. Therefore, every service, site, app, system and network is responsible for establishing the ID of their own users.
To sum up, identity management has a history of being complicated and ineffective due to these fragmented, non-standardised profiles. So identity management as we know it, was born.
The process usually goes like this. When an employee logs into payroll, the system checks their identity. Typically, they’d log in with a username and password. The system verifies the username and password combination, and grants access. As a result, the user is now authenticated and authorised to use the app they requested. The pain points begin when that same employee logs into another app, and then another, and they have to create a different username and password for every application. This gets really complicated and bothersome when you have ten different applications that you need to use regularly within an organisation. As we know, it isn’t uncommon to use hundreds of apps across an organisation.
Above all, an identity management solution will provide a company-wide identity, much like the state-issued driver’s license. A standardised ID issued by a central authority. Hence, identity management rolls all these user accounts into one centralised user ID that can be easily managed by admin.
The Different Types of Identity Management
Role-Based Identity Management
Firstly, in any given organisation, employees have different roles. One of the simplest uses of identity management is giving or restricting access to employees, depending on what apps they need to complete their jobs. This is called identity access management or IAM for short.
The IT team doesn’t need access to the enterprise’s accounting applications, and the accounting team shouldn’t have access to IT applications. You don’t want juniors making changes someone will have to fix later. Or maybe, there are contractors in a temporary role and management has decided they should only have access to certain tools or data.
There is no one right answer for how roles should be structured. Roles can be hierarchical, departmental, as needed, or a combination of the above. Grouping identities into roles for IAM is also an exercise in categorising and simplification. Rather than assigning access for every single employee, employees are grouped into a role and receive the privileges assigned to everyone in that role.
It’s fairly common to connect an identity management stack to an HR database. The HR database contains the roles and positions or all the employees in an organisation. In your identity management solution, it’s possible to reference roles saved in the HR database and have business logic group users when they are added to the identity store.
Federated Identity Management
Brower cookies won’t cross domains. It isn’t secure and all kinds of bad things would happen if they did. (Cookies are tiny bits of data that tell a site if you’ve visited before). So how does an external app like Gmail or Salesforce know how to authenticate a user if these apps aren’t getting session tokens from the browser’s cookies? The short answer is federation. So what is federation or federated identity?
Federation encompasses several identity standards like SAML2, OAuth, and OpenID Connect that are used to securely send identity information from our access manager, which is in turn, reading from a directory (see below) to these third-party applications across domains.
Federation does not send a username and password to the identity management solution on the partner app. If it worked like that then we would just run into the same problem we had when sending cookies. It instead sends who the authenticated user is. In the partner application, there will be an identity store that has an account associated with this user.
What is a Directory Service?
So, in reference to above, let’s quickly review what a directory service is. You see and use directories all the time. A phone book or contacts list is a directory, as is a library catalogue, or a dictionary. Fundamentally, a directory is an index or list that helps find and store information.
Overall, it’s important to understand directories. The directory service stores our user data. The user data stored in the directory will tell the IAM which apps the user is authorised to use. This includes managing single sign-ons, sessions, and grouping users.
But the rabbit hole goes deeper than this. Directories rely on directory access protocols. And directory access protocols are pointless without directory implementations, so let’s cover that.
Directory Access Protocols
If the directory is the library’s catalogue, then access protocols are the librarian. Protocols stack the identities nicely away on the libraries shelves and use a reference system (schema) to make sure everything is where it belongs. When done correctly, the librarian can find the book, or identity, quickly when it is next needed.
The identity store is like the shelves where the books are stored. The directory implementation is the library building. Therefore, it makes sense to librarians and has space for all those identity books.
Is a directory a database?
There is a lot of misinformation surrounding directories and databases and the differences between them. In short, a directory is a database. It is a database that implements a directory service. It functions similar to how you look up a name in a dictionary for the definition.
Single Sign-On
Single sign-on is exactly what it sounds like. It requires a user to only sign in once. Afterwards, you are authenticated and authorised for all apps within the enterprise. Single sign-on increases efficiency and prevents security risks like recycling or default passwords.
Sign-on can happen at any time during the access lifecycle. Normally it occurs the first time during the session that the user logs in to an app.
In addition to single sign-on, there are single sign-offs which are just as important. It works in the same way, however, instead of validating the session, sign-off will invalidate the session. All other applications will then get information from the IAM and know that the user has signed off.
Time limits can also be imposed on sessions. Time limits, as well as the single sign-off, are an added security measure that prevent unauthorised users potentially getting access.
Session Tokens and Cookies
Session tokens and cookies are how your browser interprets identity across applications. Your browser stores the cookies, which stores the session tokens. Why do we call them cookies? There’s a few theories, but regardless, it’s easy to remember. The browser will send the cookie when it arrives at the domain, and the applications will use the session token to check if the user’s session is valid.
However, this technique of sharing cookies among applications has weaknesses. A cookie authenticates a user. In practice, a cookie is the same thing as a username and password combination. But since the cookie is stored on a browser, there’s no secure method of encryption to protect it. Anyone can potentially upload your cookies into their browser, tricking the application into believing that you are still browsing.
On the other hand, cookies are great for internal use. For example, passing them around an intranet over secure protocols like HTTPs. However, single sign-on isn’t just for internal application. A good identity management system will automatically log into your Gmail or Salesforce account if you have already logged into an internal application that session.
Identity Management Revisited
So now we’ve spent a bit of time delving into the types of identity management solutions and how does identity management work. Consequently, let’s cover some of the problems they let us solve. Identity management solutions provide centralised control and a single, unified identity for users across all the apps in an organisation.
Without identity and access management software, it’s impossible to easily authenticate and authorise users. You can have every single application store a different username/password combination in their respective databases. But there are innate problems with this design. It is extremely difficult to scale. If there are hundreds of applications across an organisation then that means hundreds of different databases all with variations of every user’s identity.
Consequently, you have admins continually adding and removing users from different applications. Left unchecked this quickly becomes a full-time job for a person or a team of people. This is just one of the reasons that Microsoft’s identity management and Google’s cloud identity and MDM have become industry standard.
Choosing An Identity Management Solution
When deciding which identity management solution is right for your organisation, first consider what apps you are already using. Ideally, you want to get something off the ground as quickly and painlessly as possible.
If you are using G Suite applications for everything, incorporating Googles’ Cloud Identity is probably the way to go. If you use a lot of G Suite apps but don’t store everything online, then it’s worth considering Microsoft’s identity management. Google’s Cloud Identity runs Microsoft Active Directory controllers, so you can quickly sync what’s on the cloud with an offline Microsoft identity management directory.
If you are already using Office 365, why complicate things? Microsoft’s identity management solution is basically the industry standard at this point.
In short, if your business is already utilising G Suite or Office 365, you may have a built-in option already available for you to use and get you going. We do advise you to take your time and review the three options above however. All are excellent choices, and have their pros and cons. It’s up to you which one will match your business needs more closely.
An Overview of Identity Access Management (IAM)
Identity access management (IAM) is the process of identifying, tracking, controlling and managing authorised or specified users’ access to a system, application or any IT instance.
It is a broad concept that encompasses all policies, processes, methodologies and tools to maintain access privileges within an IT environment.
Techopedia
In short, including identity access management (IAM) in your identity management solution means that users aren’t authenticated against the application anymore. The IAM handles authentication for you.
What does this mean in practice? When a user tries to log into an app, their access request is routed through the IAM. The IAM waits for these requests and when it receives them it will ask the directory for that user information. Using the attributes mapped to the users, the access manager is able to authenticate.
The IAM then sends a response back to the application, and once the application receives this response, assuming all is well, will authorise the user to log in to the application.
What is the Access Manager checking for?
The access manager will consult its access policy before granting authorisation to a user.
An access policy is essentially just corporate logic. Remember when earlier, we covered role-based access management? Different groups of employees need access to different apps.
Firstly, you have a request come through to the access manager. The access manager‘s job is to determine if this user is permitted to log into this app. The access manager is just digging into the directory and checking for a boolean true or false value that tells the access manager if it should allow access to that user for that application.
To grasp why access management exists, let’s imagine it doesn’t. Let’s say that you’re an admin. Your job is to extend your authorisation mechanism across the full business. Middle management wants 2FA before employees log into any of the existing 400 applications. Without identity management, this would involve configuring control rules for every application separately. With identity management, you only need to configure an access policy for a single application, the access manager.
Above all, for the convenience that it brings, access management is a feature in all major identity management solutions. Be it Microsoft’s identity management solution or an open source solution, IAM is industry standard.
That’s The Basics Of Identity Management: Where To From Here?
In conclusion, we hope that identity management is now more than just a buzzword. This post was by no means the definitive guide. Professionals spend their entire careers mastering just a single aspect of identity management. So don’t be too hard on yourself if everything didn’t click right away. If you’re looking for more information on identity management solutions, then feel free to reach out. At Stanfield IT we have experience with G Suite, Office 365, Azure and Okta. We’ll help you discuss your needs and what identity management solutions would be suited to your business. This won’t be the last time we tackle how identity management is transforming business.