OPAdministrativeTokenRevocationConfiguration
Files: conf/oidc.properties, conf/global.xml
Format: Native Spring
Overview
The administrative token revocation feature is a way to address the need to disrupt existing tokens with the IdP in the event of account compromise. The actual implementation of this feature is based on setting a timestamp for revocation for specific user, meaning that all the tokens that are based on the user authentication before that time will be considered as revoked. This is due to the fact that the current token implementations are stateless on the server-side, so the OP cannot actually know what valid tokens may exist and can’t “delete” them out of band.
A new condition (actually a BiPredicate) attached to token, user info and introspection flows (usually globally via some simple properties) determines whether a particular JWTClaimsSet is revoked, and if configured to do so the OP will check this condition as a part of the token validation.
This feature has many similarities with the IdP’s administrative logout feature.
Configuration
The feature is enabled and disabled via the idp.oauth2.revocationCondition property (defaults to shibboleth.BiConditions.FALSE, which is a BiPredicate that always returns false).
When enabled, the idp.oauth2.revocationCondition property defines the name of a bean to use as the implementation of the BiPredicate to use. There is one implementation provided with the software:
shibboleth.oauth2.AttributeTokenRevocationCondition
This implementation abstracts away the back-end storage and management of revocation information and accesses it via a special run of the AttributeResolver, which can be configured easily to “just” resolve a single IdPAttribute to obtain the records. Obviously any DataConnector can be used to obtain them, allowing use of LDAP, JDBC, HTTP, etc. This is more flexible and recommended for production use.
The actual mechanics of revocation depend on the condition implementations, but in any case the content of a revocation record is expected to be a timestamp (the Unix epoch in seconds, NOT milliseconds). This timestamp signifies the demarcation point such that any tokens that is based on an authentication event prior to that time are treated as revoked. This is, in other words, the time at which an account might have been reset and put back under the control of authorized subject(s), i.e., when a password is reset or an account locked.
Attribute-Based Revocation
To use the AttributeResolver as a source of revocation records, the idp.oauth2.revocationCondition.attributeId property defines the ID of an IdPAttribute to resolve at runtime to fetch revocation timestamps as discussed above. The ID “revocation” is used by default.
During resolution, the “phase” is set to “oauth2/tokenRevocation”, so it is possible to automatically limit the resolution of this attribute to this use case via the resolutionPhases XML Attribute you can attach to definitions in the resolver. This is a simple way to avoid the need to resolve it during “ordinary” use of the resolver.
The usual fields in the AttributeResolutionContext are populated to allow for scripting, construction of searches, etc. It is entirely arbitrary on what basis the results are compiled but the resulting attribute values must either be of type StringAttributeValue and contain long integers representing the number of seconds since the Unix epoch, as described earlier, or be of type DateTimeAttributeValue. Any token claims sets that base on an authentication time created prior to any value returned will be considered revoked.
Reference