public interface OpaInputExtension<T>
OpaInput before sending it to the Open Policy Agent.
Implementing this class should be the last resort. It is more favourable to depend on
the existing extensions and instead use the
constraint feature of the OpaJwtPrincipal.getConstraintsAsEntity(Class) to receive data from
the policy decider and use it to decide based on it in your service.
Each extension is added in an own namespace, that means that it's data is accessible in a
single sub-property. This contents can be represented by any object that is serializable by an
ObjectMapper.
Example that returns a boolean:
{
"jwt": "…",
"path": ["…", "…"],
"httpMethod": "GET",
"myExtension": true
}
Example that returns an object:
{
"jwt": "…",
"path": ["…", "…"],
"httpMethod": "GET",
"myExtension": {
"myBoolean": true,
"myString": "asdf",
"myArray": ["…", "…", "…"]
}
}
The property name in the input is defined during registration in OpaBundle.Builder.withInputExtension(String, OpaInputExtension).| Modifier and Type | Method and Description |
|---|---|
T |
createAdditionalInputContent(javax.ws.rs.container.ContainerRequestContext requestContext)
When registered, it is called in
OpaAuthFilter.filter(ContainerRequestContext). |
T createAdditionalInputContent(javax.ws.rs.container.ContainerRequestContext requestContext)
OpaAuthFilter.filter(ContainerRequestContext). The return
value is added as child of the property name defined during the registration.
Example that adds the property "myExtension": true:
public class OpaInputHeadersExtension implements OpaInputExtension<Boolean> {
@Override
public Boolean createAdditionalInputContent(ContainerRequestContext requestContext) {
return true;
}
}
// ... in your application
OpaBundle.builder()
// ...
.withInputExtension("myExtension", new MyOpaExtension())
.build();
// ...
requestContext - the request context