[
https://issues.apache.org/jira/browse/AIRAVATA-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lahiru Jayathilake updated AIRAVATA-3978:
-----------------------------------------
Issue Type: New Feature (was: Task)
> Dynamic Access Policy Engine: Research & PoC
> ---------------------------------------------
>
> Key: AIRAVATA-3978
> URL: https://issues.apache.org/jira/browse/AIRAVATA-3978
> Project: Airavata
> Issue Type: New Feature
> Components: Custos Airavata Integration
> Reporter: Lahiru Jayathilake
> Priority: Major
> Labels: gsoc, gsoc2026
>
> h3. Summary
> Research, evaluate, and prototype a dynamic policy enforcement engine for
> Custos that can make attribute-based access decisions across all Custos
> services. This includes evaluating policy engines (AWS Cedar, OPA, Google
> Zanzibar, and others), prototyping with the most promising candidates, and
> demonstrating enforcement through real-world use cases relevant to research
> computing.
> h3. Problem
> Research computing infrastructure increasingly needs to enforce dynamic
> access restrictions based on who a user is and the context of their request.
> Some real-world examples:
>
> * A governance directive restricts access to certain compute resources for
> users outside a specific geographic region
> * A dataset is classified and only researchers from approved institutions
> with active clearance should access it
> * A compute partition is reserved for users with active allocations: no
> allocation, no access
> * During a security incident, an admin needs to instantly block a class of
> users from accessing resources without disabling individual accounts one by
> one
>
> Custos authenticates users (verifies who they are) through its identity
> management layer. The next step is a general-purpose authorization layer that
> other Custos components can call to answer: "Should this user be allowed to
> do this action on this resource, right now?"
>
> This enforcement layer needs to be invocable from multiple integration points
> across the system. For example, Custos integrates with PAM modules on HPC
> login nodes for SSH authentication. The policy engine would need to be
> queryable from that PAM flow so that even at SSH login time, the system can
> check dynamic policies (like geographic restrictions or allocation status)
> before granting access. Similar enforcement points exist in the REST API
> layer, the SSH certificate signer, and the allocation management service.
> h3. Description
> This project is a {*}research and prototyping task{*}. The student will
> survey the policy engine landscape, evaluate candidates against Custos's
> requirements, and build a working proof of concept. The goal is to give the
> Custos team a clear recommendation backed by hands-on experience, not to
> build the production integration.
>
> # *Survey and evaluate policy engines* (deep-dive on top 3, survey the rest):
>
> *Deep-dive candidates:*
>
> * {*}AWS Cedar{*}: Attribute-based access control (ABAC) engine with a
> clean, readable policy language. Designed for fine-grained authorization with
> formal verification. Open source. Well-suited for conditions like "ALLOW if
> user.affiliation IN approved_institutions AND user.region == 'US'".
> * {*}Open Policy Agent (OPA) with Rego{*}: General-purpose policy engine.
> Very mature and widely adopted. Rego is a powerful but complex query
> language. Can model any authorization pattern but has a steeper learning
> curve.
> * {*}Google Zanzibar / SpiceDB{*}: Relationship-based access control
> (ReBAC). Models authorization as relationships: "user X has relation Y to
> resource Z". Strong for modeling organizational hierarchies and resource
> sharing. SpiceDB is the leading open-source implementation.
>
> *Survey candidates* (evaluate at a high level for fit, don't prototype):
>
> * {*}Cerbos{*}: Open source, ABAC-focused, simpler than OPA, designed for
> microservices
> * {*}OpenFGA{*}: Open source Zanzibar implementation by Auth0/Okta,
> relationship-based with conditions support
>
> For each engine, evaluate:
>
> * Policy language expressiveness: can it naturally express the use cases
> below?
> * Integration model: sidecar, library, or remote service? Latency
> characteristics?
> * Attribute handling: how does it consume external data (user attributes,
> allocation status, geographic data)?
> * Multi-tenancy: can different tenants (sites/gateways) define their own
> policy sets?
> * Audit trail: does it produce explainable decisions (which policies
> matched, why allow/deny)?
> * Operational maturity: community, documentation, production adoption
>
> # *Prototype with 2-3 engines* against these use cases:
>
> * {*}Geographic access restriction{*}: Evaluate a policy that restricts
> access to a compute resource based on the user's institutional affiliation or
> geographic region. Example: "DENY if user.country NOT IN ['US', 'CA']"
> * {*}Allocation-gated access{*}: Check whether a user has an active,
> non-depleted allocation on the requested resource before allowing access.
> This requires the policy engine to query external state (the allocation
> service).
> * {*}Emergency user blocking{*}: Model a scenario where an admin publishes a
> "block list" policy that immediately denies access for a set of users or a
> class of users (e.g., all users from a specific institution), without
> modifying individual accounts.
> * {*}Time-based access{*}: A resource is only available during certain hours
> or a maintenance window blocks access temporarily.
>
> For each prototype, demonstrate:
>
> * Writing the policy in the engine's language
> * Feeding user attributes and request context into the evaluation
> * Getting an allow/deny decision with an explanation
> * Measuring evaluation latency
>
> # {*}Design the integration architecture{*}:
>
> * How would the chosen engine be deployed alongside Custos services?
> * How would existing Custos components (signer, allocation service, PAM
> module on HPC nodes) call the policy decision point?
> * How would policies be managed per-tenant (each site defines its own rules)?
> * How would policy changes be deployed and tested safely (dry-run /
> simulation mode)?
>
> # *Deliver a recommendation report* covering:
>
> * Comparison matrix of all evaluated engines
> * Prototype results with code and performance measurements
> * Recommended engine with rationale
> * Proposed integration architecture for Custos
> * Limitations and open questions
> h3. Expected Deliverables
> * Policy engine comparison report (Cedar, OPA, Zanzibar/SpiceDB, Cerbos,
> OpenFGA) evaluated against Custos requirements
> * Working prototypes with at least 2 engines demonstrating all four use cases
> * Integration architecture proposal showing how the policy engine fits into
> Custos (including PAM, signer, allocation service enforcement points)
> * Recommendation report with rationale, prototype code, and performance
> benchmarks
> h3. Required Skills
> * Go or Java (for building the prototype service and integration code)
> * REST API design
> * Understanding of authorization concepts (RBAC, ABAC, ReBAC), or
> willingness to learn
> * Comfort reading and writing policy languages (Cedar, Rego, etc.), or
> willingness to learn
> * Basic understanding of how SSH/PAM authentication works, or willingness to
> learn
> h3. Resources
> * {*}Custos repository{*}:
> [github.com/apache/airavata-custos|https://github.com/apache/airavata-custos]
> * {*}Custos identity module{*}: identity/ directory for understanding the
> current authentication layer (TokenAuthorizer, AuthClaim)
> * {*}PAM integration{*}: deployment/account-provisioning/ shows how Custos
> integrates with PAM modules on HPC login nodes via pam_oauth2_device for SSH
> authentication
> * {*}Signer service{*}: signer/ directory for the SSH certificate signing
> service, one of the enforcement points
> * {*}AWS Cedar{*}: [https://www.cedarpolicy.com/] and
> [https://github.com/cedar-policy]
> * {*}Open Policy Agent{*}: [https://www.openpolicyagent.org/] and
> [https://play.openpolicyagent.org/]
> * {*}Google Zanzibar paper{*}: [https://research.google/pubs/pub48190/]
> * {*}SpiceDB{*}: [https://authzed.com/spicedb] and
> [https://github.com/authzed/spicedb]
> * {*}Cerbos{*}: [https://cerbos.dev/] and [https://github.com/cerbos/cerbos]
> * {*}OpenFGA{*}: [https://openfga.dev/] and
> [https://github.com/openfga/openfga]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
