JIT provisioning can be configured by setting up SSO between the target service and the identity provider. You can use just about any protocol for SSO, but for the integration to work, it’s important for the target service to support JIT provisioning. Many major service providers, like Oracle, AWS and Adobe, offer JIT provisioning for their apps.
When a new user logs in to a service, the service sends a SAML assertion request to the identity provider. This request includes all the information needed to create a new user account, including user credentials (e.g. username and password). The identity provider verifies the user’s identity and then creates their account.
JIT provisioning allows administrators to apply authorization policies to users from a central place, based on their groups or roles. For example, when a new developer logs in to a service with JIT provisioning enabled, the identity provider automatically grants them all the permissions of the Developers role.
SSO is an authentication technique that allows users to log in once to access numerous services and systems. JIT provisioning is used on top of SSO to automate the process of onboarding new users to a system.
SSO and JIT provisioning offer similar benefits. Both techniques enhance the login experience. SSO does so by eliminating the need to remember multiple passwords. JIT provisioning achieves it by allowing new users to log in without the need for manual provisioning.
SSO and JIT provisioning differ based on where they operate in the authentication process. SSO is applied during the login stage of the authentication process, whereas JIT provisioning is invoked during the user creation stage.
JIT provisioning:
Just in Time Access is a security approach that grants privileged access to approved users for a limited time as needed. Administrators can use JIT access to track and govern access to sensitive resources at a more granular level.
Conversely, Just in Time provisioning is a way of dynamically registering a user on their first login. In terms of design and philosophy, it’s a fundamentally different approach than JIT access. JIT provisioning’s primary purpose is to reduce administrative workload by eliminating the need for manual provisioning.
JIT access and JIT provisioning can work either together or independently of each other. Both approaches share some overlapping benefits. For example, both JIT access and JIT provisioning enable administrators to restrict privileged access, just in different ways. However, for the most part, JIT access and JIT provisioning serve different use cases.
Just in Time (JIT) Privilege is another flavor of the Just in Time paradigm that automates the dynamic assignment and removal of privileges from user accounts. In an environment governed by JIT privilege policies, elevated privileges are only assigned to approved users temporarily.
JIT privilege can act as an additional layer of security in an Active Directory (AD) setup. Active Directory is a staple of IT infrastructures. It controls and governs access to all sensitive resources on a corporate network. For this reason, it’s often a prime target for cyberattacks, such as privilege escalation.
A common method of AD privilege escalation is through a residual hash. A residual hash is a password hash that is logged whenever a user (privileged or standard) logs in interactively to a system in AD. If a malicious actor gains access to the residual hash of a privileged user, they can perform elevated operations across the entire infrastructure.
JIT privilege offers a way to mitigate these threats by ensuring that privileges are only granted when requested and revoked immediately after use.
In a traditional AD setup, privileges are stored inside Active Directory. When using JIT privilege, privileges are dynamically assigned to users at the time of credential checkout. For instance, if an authorized AD account requires elevated privileges to perform an action, it is temporarily added to a privileged group. As soon as the operation is performed and the privileged access is no longer required, the account’s group membership is revoked, and its password is changed.
For instance, suppose an authorized user wants to perform a privileged operation, such as changing a network-wide security policy. Here’s how it will happen in a JIT privilege-driven AD setup:
Temporary provisioning of AD privileges significantly reduces the chances of a residual hash compromise. Even if a malicious actor manages to retrieve a residual hash of a privileged AD user, they can’t leverage it, since the account’s membership has been cancelled and its password has been changed.
No, JIT provisioning isn’t the same as Zero Trust. However, the Just in Time paradigm is a fundamental concept of Zero Trust. Approaches such as Just in Time access, Just in Time privilege and Just in Time provisioning are aligned with the core tenets of Zero Trust.
Zero Trust entails that no entity in a network is inherently trusted, and that their access privileges are assigned temporarily. Just in Time access and privilege achieve this by dynamically assigning temporary access to resources and ensuring that nobody has indefinite access to anything.
By allowing administrators to apply authorization policies, JIT provisioning ensures adherence to the principle of least privilege, a primary tenet of Zero Trust. So, it’d be fair to say that JIT provisioning and Zero Trust security go hand in hand, but it wouldn’t be fair to equate the two.