Debug
Access control debug tools available in Aidbox
Aidbox offers multiple ways to debug access policies:

__debug query-string parameter

There is a special query-string parameter __debug=policy you can pass to every Aidbox request. It will toggle debug mode for Request Authorization Layer, and in this mode instead of actual response client will get an object containing:
  • full request object;
  • an array of existing AccessPolicies;
  • evaluation result for every AccessPolicy (under AccessPolicy.evalResult).
Define AIDBOX_DEV_MODE to enable __debug parameter

x-debug: policy request header

For requests with the x-debug: policy header, details of access policy evaluation will be logged.
1
GET /Patient
2
x-debug: policy
3
​
4
# in aidbox logs
5
# :auth/trace-policy {:access-policy-id :policy-1, :policy-type "sql", ...
6
# :auth/trace-policy {:access-policy-id :policy-2, :policy-type "json-schema",...
Copied!

su request header

su header allows to switch user on behalf of whom request is executed. Use su=<user/client id> to check how access control works for that user.
su header functionality can be enabled with box_debug_su_enable env
Example
1
box_debug_su_enable=true
Copied!
su header is only available to admin users, who have at least one AccessPolicy with engine = allow linked to them.

Example

1
# Request as an admin:
2
GET /fhir/Patient
3
​
4
# Response:
5
Status: 200
Copied!
1
# Request on behalf of `myid` User who has no access to Patient search:
2
GET /fhir/Patient
3
su: myid
4
​
5
# Response
6
Status: 403
Copied!

/auth/test-policy Operation

You can use a special operation POST /auth/test-policy to design policy without creating an AccessPolicy resource and for different users and clients. Post on the /auth/test-policy with a simulated request attribute (you can provide existing user-id and client-id β€” Aidbox will find and populate request) and temporal policy in the policy attribute. If you want to test JWT auth, put your token in the headers.authorization with the Bearer prefix β€” the token will be parsed and its claims appear in the request.jwt. JWT in a header is parsed but not validated. This allows you to test JWT policy without TokenIntrospector registration.
The response contains a result of evaluated policy.
1
POST /auth/test-policy
2
​
3
-- simulate request document
4
request:
5
uri: '/Patient'
6
request-method: get
7
headers:
8
authorization: Bearer <your-jwt>
9
user:
10
data: {role: 'admin'}
11
-- or
12
-- user-id: 'user-1' -- aidbox will find user in database
13
client:
14
id: basic
15
grant_types: ['basic']
16
-- or
17
-- client-id: 'client-1' -- aidbox will find client in database
18
19
policy:
20
engine: sql
21
sql:
22
query: 'SELECT {{user.role}} FROM {{!params.resource/type}}'
23
​
24
-- response
25
​
26
request:
27
uri: /Patient
28
request-method: get
29
user: {role: admin}
30
params: {resource/type: Patient}
31
#jwt: ...jwt-claims
32
operation:
33
request:
34
- get
35
- {name: resource/type}
36
action: proto.operations/search
37
module: proto
38
id: Search
39
-- original policy
40
policy:
41
engine: sql
42
sql: {query: 'SELECT {{user.role}} FROM {{!params.resource/type}}'}
43
-- result of policy evaluation
44
result:
45
eval-result: false
46
query: ['SELECT ? FROM "patient"', admin]
Copied!