Authentication Authorization Concepts
To promote the most possible flexibility while still allowing for a high-security, high-observability model, AuthJanitor allows for multiple modes of confirming a rekeying operation.
Queued Rekeying Tasks using this strategy must be approved by an administrator. To provide the administrator with the proper knowledge to either approve or deny the Rekeying Task, all Providers are required to provide an Action Description and a scored list of Risks to help the administrator user understand the impact of their approval.
Once an administrator reviews this information, they can approve the actions, which are then executed in the administrator's user context using on-behalf-of access tokens. Approaching application secret rotation in this way allows for traceability of the actions performed back to the administrator approving them.
Using only Administrator-driven strategies is recommended, as it prevents the need for granting overly broad access to a service principal or managed identity.
- Traceability of the Administrator user approving the Rekeying Task
- Administrator presented with a list of risks and high-level actions which are performed, providing visibility into the inner workings of what the automation will execute
- AuthJanitor Agent identity does not require write access to Azure subscription
- Administrator must log in to perform the action when it's needed, which means there's no possibility for scheduling rotation for off-hours
- On-behalf-of actions don't work with B2C tenants and require admin consent
Similar to "Administrator Signs Off Just-in-Time" above, this approach uses an on-behalf-of token to act as the administrator for automated actions. However, this approach persists an access token/refresh token using a Secure Storage Provider (and optional Persistence Encryption). When the scheduled window arrives, the token is retrieved, used, and destroyed (if the rotation succeeded).
This method is less secure than signing off just-in-time, as a credential is saved for future use. However, it does allow for business continuity to dictate the secret rotation strategy, by setting availability windows. This could be used to only rotate secrets on weekends, for example.
- All of the same advantages as Administrator Signs Off Just-in-Time
- Rekeying tasks can be performed semi-automatically; as long as an Administrator logs in within the window of time prior to expiry, these tasks can be run at any time within the expiry window of the access token.
- Access token must be stored in a way which is readable for some amount of time between when the Administrator generates the token and when it is used. There is a risk of compromise of the access token from this storage media; mitigation is performed through encryption and secure storage providers.
- On-behalf-of actions don't work with B2C tenants and require admin consent.
When this strategy is used, the AuthJanitor Agent's identity context is used to perform the secret rotation. Immediately prior to the expiry of the Managed Secret, the Agent will execute the secret rotation.
- Administrators can be completely hands-off the operation, as it is all run under the context of the AuthJanitor Agent.
- Requires that the AuthJanitor Agent have broad permissions over the Azure subscription. While every effort is made to mitigate issues, including limiting inputs to the Agent application, a compromise of the Agent or its credentials would permit an attacker to have as much management-level access as the Agent's identity.
Similar to the Just-in-Time strategy above, the AuthJanitor Agent's identity context is used to perform the secret rotation. However, this is done on a given schedule based on availability windows during which the secret rotation can occur.
- Same as AuthJanitor Agent Rekeys Just-in-Time.
- Managed Secrets can be rekeyed on a schedule based on business continuity needs and/or service availability.
- Same as AuthJanitor Agent Rekeys Just-in-Time.
When this strategy is used, the AuthJanitor Agent accepts HTTP requests from an external service. This request must contain the ObjectId of the Managed Secret, as well as what the external service believes the Managed Secret's nonce to be. If that nonce is valid, the Agent will return 0. If it is invalid (i.e. the Managed Secret has been rotated, and a new nonce generated), the Agent will return 1. The expectation is that the external service will reach out independently to a location where the secret material is stored to retrieve it. This may mean reloading an application to re-cache the value of a secret from Key Vault, for example.
- Provides more granular control over the lifecycle of an application's secrets by a generic HTTP validation URL
- Some degree of app-side control without having to write an entire Provider
- Requires that the AuthJanitor Agent have broad permissions over the Azure subscription. While every effort is made to mitigate issues, including limiting inputs to the Agent application, a compromise of the Agent or its credentials would permit an attacker to have as much management-level access as the Agent's identity.
