Authentication is often confused with authorization even though they are distinct technologies and practices. In some computing models, authentication and authorization are blended together and have little distinction or separation in implementation or management. Apple iOS, for example, uses biometrics for both authorization and authentication, and the end-user experience is blurred regardless of the action type. By definition, authentication is a login (username) in addition to some form of secret, historically a password, to establish proof or trust in an identity. It is essentially a validation of who you say you are.

While there are countless variations of shared secrets that can be used within a login, such as pin codes, passwords, keys, two-factor authentication, and so on, the login itself is generally not a secret and often guessable for an identity. For example, login could be “jtitor” for my alias as an abbreviation of John Titor’s name. However, a login could also be something more complex like an employee number, which better masks a user’s identity. For highly secure environments, this second approach is preferable, especially for administrator or root accounts. You do not visually identify the privileges with the account simply by looking at the account or username. Obscurity is not security but it often helps!

So, in simple terms, authentication is nothing more than proving your identity or you ownership of a given account. It does not provide permissions, privileges, or access, just confirmation that you are who you say you are.

Authorization is the next step after authentication. You cannot be authorized to perform a function, have privileges assigned, or even perform tasks in a given role, without some form of authentication happening first. Even if you are a Guest in an application or operating system and have no login and/or password of your own, your authentication is assumed to be Guest, and you are granted all the rights and privileges of that Guest. The login username and password secret are therefore much less relevant, but you have still been authenticated and have still been assigned some form of authorization, albeit very little.

Authorization is, therefore, the right to perform a function based on your authentication. Your identity and its associated account are granted privileges to perform specific functions and may also be explicitly denied or not privileged to perform other functions. These privileges can be assigned within an application, an operating system, or some part of the supporting infrastructure. It could also be assigned within an identity or privilege management system that is controlling it. In order to manage at scale, the latter is always recommended.

When like privileges are grouped together, they create the foundation of a Role. When a Role is assigned to a group of accounts, the Role is providing authorization for that group to perform those functions.

In the case of a mobile device like an Apple iPhone running iOS, facial recognition or fingerprint touch is used for both authentication and authorization. They will log you into the device (authentication), and they can also be used to secure payments or to make purchases – very specifically an authorization – it does so using the same mechanisms.

In today’s world of high-fidelity cybersecurity, using the same mechanism or technique for both authentication and authorization at the same time can lead to significant issues relating to the integrity, controls, and oversight for the process, and many in the industry now believe they should be kept separate. A breach or weakness in one model leads to a breach or weakness in the other. While Apple has designed high levels of security into their solutions to minimize the risk, in general, most computing environments should avoid using the same technology for authentication and authorization. Just because you have been authenticated does not mean you should have authorization. Those privileges and permissions should ultimately be decided upon using a separate process and a separate layer in the security stack. Even in modern “state-of-the-art” computing environments, we often see the same lack of separation when a Single Sign-On (SSO) solution blurs the line between initial authentication and the automatic authorization within a managed application. Multifactor authentication (MFA) solutions can help mitigate this risk by requiring a second validation for privileged authorization activity.

Search the Internet, and you’ll find 100 different definitions for administration. In the context of this book, we are very specifically talking about the administration of authentication, authorization, and audit controls. Administration here means configuration management and governance controls over any changes made to that authentication, authorization, and audit. In Chapter 6 on Identity Governance Defined, we explain how providing a centralized and normalized set of administration capabilities for all access systems can help; this is the mandate of Identity Governance.

Authentication and Authorization mechanisms are inherently distributed, painfully diverse, and perpetually changing. After 25 years of watching this space develop, most “old-timers” in the IAM space are usually quite retrospect about how much things have changed, but yet how much they are still the same. Most organizations still struggle to get full administrative control over the systems and data they are responsible for protecting. It is therefore essential, in our view, that Administration is treated independently from the ever-changing mix of AuthN (authentication) and AuthZ (authorization) technologies. You might say “stick to your knitting” is the name of the administration game. Don’t just let Authentication or Authorization manage it. That way, through specialization and focus, you might actually get true administrative coverage.

IAM administration is a big part of the Identity Governance remit. Add to it Audit and Analytics (in the following), and you have the product scope of most enterprise-class Identity Governance solutions. Through the use of a dedicated heterogeneous management approach, Identity Governance strives to take on the mantle of global administration, audit, and analytics for all users and all data access. By leveraging the Identity Governance processes (also outlined in Chapter 7), administration can provide visibility, controls, automation, and full lifecycle management (LCM) of all users and their access.

Facilitating the delivery of a repeatable and sustainable user access, Audit process is also the responsibility of the Identity Governance process. Whether it is overlaying specific controls to meet regulatory compliance , or creating system-driven lifecycle management functions that are stable and verifiable as controls proof, Audit is a significant part of the identity management system.

For some, the Audit of IAM means delivering a user access certification program. For others, it’s defining and implementing preventive and detective policy such as Separation of Duty (SoD). For all, it is being able to prove that comprehensive administration processes and policies are in place and being adhered to.

The fifth and final A is the comprehensive analysis of how the IAM system is operating. Analytics means gaining operational and security insights, through the ongoing collection and processing of identity-related configuration, assignment, and usage data.

Advanced identity analytics enables a more informed and predictive approach to governance. Using Machine Learning (ML) and Artificial Intelligence (AI) techniques, identity analytics tools can provide important peer-group analysis information that helps to extend identity audit and administration functions and make them more dynamic and responsive. For example, if an analytics engine discovers suspicious, inappropriate, or unusual access, it can prompt administrators to review that access to ensure that the correct configuration has been implemented. Analytics can provide auto-generated insights and recommendations that allow the line of business to make more informed access decisions that enhance operational security and ensure compliance. With the advancements in ML and AI, mass quantities of operational data can now be discovered and processed to uncover hidden insights and actionable guidance far beyond what a traditional rules-based engine can achieve.