The proliferation of applications outside the corporate network has led to a loss of control over user accounts, specifically, how the lifecycle is managed, how security controls are applied, and how access is controlled. All organizations are impacted by these disparate systems and controls, which present significant security and compliance risks. Instead of managing all user identities and access through Active Directory as most organizations are used to, user identities and permissions need to be setup and managed per application.
Identity and Access Management (IAM) solutions provide a platform to centralize user identities and access controls to modern applications that utilize new delegated authentication methods such as Security Assertion Markup Language (SAML), Web Services Federation (WS-Fed), and OAuth. These delegated authentication methods allow the application to target an external system for identifying and authenticating a user while permissions authorization remains within the application.
Why is IAM Important?
Centralized Identity
Traditionally, user identities were centrally managed in Active Directory. This provided an easy to administer, single source-of-truth about the user and was utilized by most applications. As applications move outside the corporate network, they’re no longer able to integrate with Active Directory. Administrators are forced to manage user identities per application, increasing the amount of work required to provision and de-provision users. There’s also an inherent risk of forgetting to disable a terminated user. IAM brings centralized identity back to applications outside the corporate network and increases efficiency by managing user identities in a single location. Identity actions performed on the IAM apply to all integrated applications.
Centralized Security
As with Centralized Identity, Active Directory was historically the place where overall identity-based security was applied. Consider how an administrator manages password requirements. With traditional Active Directory solutions, the password policy is applied to the user object via GPO or a Fine-grained Password Policy. Since most applications were integrated with Active Directory, they inherently adhered to the same password policies. As applications move outside the corporate network, administrators need to control the password policies per application (assuming an application vendor even allows the administrator to control the password policy).
With IAM, the password policy is once again centralized and applies to all applications that are integrated with IAM. In cases where the vendor doesn’t allow management of the policies it returns the ability to apply corporate security policies uniformly. In addition to centrally managing password policies, IAM also enables centralized management of security controls, like Multi-Factor Authentication policies, and can often adjust the specific login flow based on user context (e.g., group membership, user location).
How does IAM work?
You might ask, what’s the end-user experience when using an IAM tool? Let’s walk through a typical scenario of a Service Provider Initiated login flow. A Service Provider Initiated (SP-Initiated) flow indicates that the user starts the login process at the Service Provider (the end application, e.g., Box.com) and is redirected to the IAM platform (Identity Provider or IdP, e.g., Azure Active Directory) for authentication.
- User accesses login page for box.com application.
- User provides username.
- com application does a lookup of the user based on the username provided and determines that authentication should happen against the configured Identity Provider.
- com redirects the user to the Identity Provider platform for login.
- User provides username and password on the Identity Provider platform login page (including MFA if required).
- After successful authentication on the Identity Provider platform, a token is issued to the user to indicate a successful authentication and is signed by the Identity Provider. It’s important that the token is signed by the Identity Provider because Box.com will compare the signature against the Identity Provider configuration and confirm the Identity Provider platform is authorized to issue tokens.
- The user is redirected back to Box.com, and the browser seamlessly provides the authentication token back to Box.com.
- com validates the token against its configuration and grants the user access to the application.
Take back control of security
Identity and Access Management solutions offer a great opportunity to regain control over the security of your user accounts with modern applications. Organizations of all sizes will benefit from implementing consistent controls across all their applications.
Additional reading on the ZAG Blog:
