IAM access graph

Problem and backend

This example expands principal, group, role, policy, and emergency grants into an explainable access path. It uses TinkerGraph to isolate modeling from container and network variance. Read core model and TinkerPop first; use the selection guide before production.

Model

• Nodes: IamUser/IamGroup/IamRole/IamPolicy/IamPermission/IamResource/IamSessionGrant
• Edges: MEMBER_OF/HAS_ROLE/ATTACHED_POLICY/GRANTS_PERMISSION/APPLIES_TO/HAS_TEMP_GRANT/TEMPORARY_PERMISSION
• Key properties: userId, roleId, policyId, action, resourceId, grantId, expiresAt

Prerequisites and release boundary

Use JDK 21, commit 72c0256e2e1cf61101d29852210e3c827ca93bc0, and the checked-in wrapper. Examples are not published; run this release fixture as a Gradle project from the release source checkout. In a consumer application, select only bluetape4k-dependencies:<ecosystem-version> and add the required graph module without an individual version.

Run and observe

./gradlew :iam-access-graph-examples:test --tests "io.bluetape4k.graph.examples.iam.TinkerGraphIamAccessGraphTest"

The tests assert two independent grants: inherited group access passes through group:engineering and role:deployer-role, while temporary emergency access passes through grant:break-glass-1001. A failure means the principal-to-role direction, policy expansion, or deny boundary needs inspection.

Reading order

1. Schema
2. Service
3. Shared executable contract
4. Concrete TinkerGraph test
5. Build file

Continue from linkedin-graph, then read fraud-detection. Also see paired APIs, testing, and operations.

Exercises and production gaps

Add one result-changing edge and assertion; repeat through the suspend API; then run a persistent-backend concrete test serially. Add disconnected and malformed inputs as diagnostics. This fixture does not prove throughput, clustering, authorization, tenant isolation, migration, backup, remote-driver timeout, or index quality.