Identity Context
When an Authorizer evaluates a policy, it receives an Identity Context from the calling application.
The type
property of that Identity Context instructs the Authorizer how to identify the user:
- IDENTITY_TYPE_NONE: the policy is evaluated without a user context (input.user is empty)
- IDENTITY_TYPE_SUB: the user context is passed in as an OAuth subject
- IDENTITY_TYPE_JWT: the user context is passed in as a JWT access token
Passing a user identity
In the IDENTITY_TYPE_SUB and IDENTITY_TYPE_JWT cases, the Authorizer will treat the identity
string as a
OAuth subject or a JWT access, respectively. In the case of a JWT access token, the Authorizer will extract the sub
(subject) claim, whereas
IDENTITY_TYPE_SUB indicates that the identity
string already contains a subject.
Once the Authorizer has obtained the subject, it will use it as a key and look up the user in its
local directory instance (known as the Edge Directory Service, or EDS). It will then load the user
object identified by the identity context and make it available to the Policy as input.user
.
For a user-facing API (for example, a back-end REST API that requires a JSON Web Token (JWT)
in the Authorization
header), the caller will often extract the sub
claim from the JWT and use it
in the identity
field. That said, the identity
can be any key that is used by the Identity Provider
to identify the user.
Setting the Identity Context
The is
, query
, and decisiontree
API calls all take an identityContext
map:
POST .../api/v2/authz/is
{
"identityContext": {
"identity": "[aserto-user-guid]",
"type": "IDENTITY_TYPE_SUB"
}, ...
}
To access the properties of the user in a policy, you can use input.user
:
package sample.GET.api.orders
default allowed = false
# only allow salespeople
allowed {
input.user.properties.department == "Sales"
}
Using other JWT claims in a policy
Note that the identityContext
is available as input.identity
. If the policy wants to
extract additional claims out of a JWT and use them in the policy, it can readily do so.
Assuming the following identityContext
:
POST .../api/v2/authz/is
{
"identityContext": {
"identity": "[JWT that could contain a 'manager' claim]",
"type": "IDENTITY_TYPE_JWT"
}, ...
}
The following policy will extract the JWT using the io.jwt.decode()
Rego built-in, make it available
as token.payload
, and use claims in the payload within the policy:
package sample.GET.api.orders
default allowed = false
# Helper to get the token payload
token = {"payload": payload} {
[header, payload, signature] := io.jwt.decode(input.identity.identity)
}
# only allow sales managers
allowed {
input.user.properties.department == "Sales"
token.payload.manager
}