[OpenFGA] Discussion

[swelborn]

I would like to start a discussion about openfga here.

A while back I submitted this PR for a very simple model that does everything that coact needs (at present):

#11

@yee379 committed this model along with a description: https://github.com/slaclab/coact-api/tree/main/schema

I generally fall into the camp of less is more at first, and I think getting too fine grained (i.e., a type for slurm_job, audit_trail, notification) can cause some problems with the amount of tuples we are storing in the database and complexity on first implementation (how do we gather all this information?).

However my model is too simple, I think, so there is some middle ground I think we could definitely reach by discussing it here. Since I do not have the entire landscape of authz at SLAC in my head (like I know @yee379 does 😏) would it be possible to list these sources/links to code that sets them up here as a starting point?

If we don't want to make this a public issue, we can move it to a different repository.

[bisegni]

Personally, I wouldn’t worry too much about the database side of this. Systems like this can usually handle a very large amount of authorization data and tuples without major issues.

I also don’t know all the details of SLAC’s authz landscape yet, but I do have experience from my previous work at INFN on designing centralized IAM systems capable of handling authorization for both existing and future applications.

At INFN we ended up modeling permissions around subject/resource/action tuples, which were then materialized in LDAP as entitlements attached to users. Regardless of how this information is ultimately materialized or stored, I think the important aspect is having a central place where the developer of a specific application or system can model authorization at the level of granularity that makes sense for their use case.

Because of that, I would personally focus on exposing APIs and abstractions that allow this flexibility, while leaving the decision of “how deep to go” to the individual application or use case.

Ideally, I would also love to have a global UI where application/system owners can register their app, define their own resources/actions, and manage authorizations for users directly through the UI, instead of having to hardcode or manually manage everything outside the platform.

That said, since I still don’t have full visibility into the current SLAC authorization landscape and implementation details, I may very well be overlooking some important aspects here and there.

[swelborn]

Personally, I wouldn’t worry too much about the database side of this. Systems like this can usually handle a very large amount of authorization data and tuples without major issues.

good to know about that cardinality aspect. i think most of my worry about getting too fine-grained in our model is that we would be putting ourselves into a concrete corner rather than something more abstract as you mention below

I also don’t know all the details of SLAC’s authz landscape yet, but I do have experience from my previous work at INFN on designing centralized IAM systems capable of handling authorization for both existing and future applications.

nice, is any of that code open source?

At INFN we ended up modeling permissions around subject/resource/action tuples, which were then materialized in LDAP as entitlements attached to users. Regardless of how this information is ultimately materialized or stored, I think the important aspect is having a central place where the developer of a specific application or system can model authorization at the level of granularity that makes sense for their use case.

Because of that, I would personally focus on exposing APIs and abstractions that allow this flexibility, while leaving the decision of “how deep to go” to the individual application or use case.

Ideally, I would also love to have a global UI where application/system owners can register their app, define their own resources/actions, and manage authorizations for users directly through the UI, instead of having to hardcode or manually manage everything outside the platform.

this would be great, and I think we could definitely create something like this with these custom-roles, seems to fit very well: https://openfga.dev/docs/modeling/custom-roles

That said, since I still don’t have full visibility into the current SLAC authorization landscape and implementation details, I may very well be overlooking some important aspects here and there.

me neither! :) it would be great to have some references written down here

[amithmslac]

This is useful reading re auth changes: https://github.com/slaclab/k8s-auth/tree/main/s3df-authnz-service

[bisegni]

nice, is any of that code open source?

No, unfortunately it’s closed source, but the overall logic is actually quite simple.

Everything revolves around a Java backend that processes rules/scripts (written in Java or Lua) to determine each user’s entitlements and then materializes them into LDAP.

The backend is mainly used by internal HR systems to associate users with specific groups, services, or divisions, together with enrollment-related information and validity periods (start/end dates). Then, scripts combine this dynamic information with additional static metadata to compute the complete set of entitlements for each user.

Applications only need to fetch the entitlements associated with a user, filter the ones relevant to their specific application, and determine what the user is allowed to do.

this would be great, and I think we could definitely create something like this with these custom-roles, seems to fit very well: https://openfga.dev/docs/modeling/custom-roles

yess, agree

me neither! :) it would be great to have some references written down here

yes:-)

[2Ryan09]

Regarding current authorization landscape, the link @amithmslac posted is the ideal future state. Currently authorization (via Vouch) for coact infrastructure is handled through Ingress resources within the deployment + endpoint files of slaclab/coact-deploy. We are currently testing it's implementation, I have a draft PR here to migrate to the new service, but for now can serve as a good reference for what was and how we might be headed to (in creation of that PR I was going to logic parity, so feel free to critique).

[swelborn]

Please see below for an fga model that I think can do what we need for registering apps + custom actions with fga. Pardon the LLM-generated comments.

The idea here is that we have two main user types (users + groups) that can be permitted access, and resource groups and resources that the user can act on.

The resources here are generic. The top-level resource is the application, and underneath you can have resource groups and resources. This hierarchy allows us to inherit permissions from top-level. We have 4 "core" permission types baked into the model, and app-specific permissions that people can add.

The problem with this abstraction is that it forces us to use a condition for "has_permissions", since we are not baking in the permissions into the model. It also forces us to have an external registry (e.g., a different postgres schema sitting in the same postgres instance as fga) of per-app permissions and resources.

Claude (mostly) built an API + UI for this, just to see how it would work. I could clean it up, but it would be good to get some feedback before cleaning it.

I have explored alternatives to this. If we wanted to bake things more directly into openfga, we could come up with a solution to have per-app models. That would force new application developers to design their own fga models and we would have to have some CI to build them in.

model
  schema 1.1

# =============================================================================
# OpenFGA Authorization Model
# =============================================================================
#
# This model implements a hierarchical, condition-based permission system.
# Permissions flow downward: application → resource_group → resource.
#
# KEY CONCEPTS:
#
# 1. Subjects (who can be granted access):
#    - user:realm/username        (e.g. user:slac/swelborn)
#    - group:realm/groupname#member (e.g. group:slac/ps-users#member)
#
# 2. Actions:
#    a) CORE actions are first-class OpenFGA relations: can_read, can_edit,
#       can_delete, can_manage. They are typo-proof (unknown relations are
#       rejected at write time), condition-free, and traversed by the native
#       graph engine. A core grant is a plain tuple, e.g.
#         user:slac/alice → can_edit → resource:pief/expX
#    b) app-specific actions (can_manage_groups, can_switch,
#       can_request_allocations, …) ride the `permitted` + `has_permission`
#       escape hatch: a `permitted` tuple carries a `granted_permissions`
#       list, and the `authorized` relation passes when the requested action
#       is in that list. New core actions are a model migration; new exotic
#       actions are instant runtime vocabulary.
#
# 3. Hierarchy (permission inheritance) — two recursive-capable tiers:
#    Every tier has a `parent` relation pointing at [application, resource_group].
#    `resource_group` is self-referential, so groupings nest to arbitrary depth
#    (application → group → group → … → resource). `resource` is always a leaf
#    (its parent is an application or a resource_group, never another resource).
#    Core relations and `authorized` inherit "from parent", so a grant high in
#    the chain flows down to every descendant.
#
# EXAMPLE TUPLES:
#
#   # Core grant: alice can edit experiment "expX"
#   user:slac/alice  →  can_edit  →  resource:pief/expX
#
#   # Core group grant: all members of ps-users can read experiment "expX"
#   group:slac/ps-users#member  →  can_read  →  resource:pief/expX
#
#   # Escape-hatch grant: admin may manage groups (app-specific action)
#   user:slac/admin  →  permitted  →  application:pief
#     condition: has_permission { granted_permissions: ["can_manage_groups"] }
#
#   # Group membership: carol is a member of ps-users
#   user:slac/carol  →  member  →  group:slac/ps-users
#
#   # Hierarchy link: resource "expX" is parented under resource_group "lcls"
#   resource_group:pief/lcls  →  parent  →  resource:pief/expX
#
#   # Hierarchy link: resource_group "lcls" is parented under application "pief"
#   application:pief  →  parent  →  resource_group:pief/lcls
#
# CHECK FLOW (e.g. "can alice read expX?"):
#   CORE action  → check the `can_read` relation directly (no context);
#                  inheritance follows `can_read from parent` up the chain.
#   OTHER action → check `authorized` with context {required_permission};
#                  inheritance follows `authorized from parent`, and each
#                  `permitted` tuple's has_permission condition is evaluated.
#
# =============================================================================

# A user identity. Format: user:realm/username
type user

# A named group of users. Members inherit the group's grants.
# Groups can be nested (a group can be a member of another group).
#
# Example tuple: user:slac/alice → member → group:slac/ps-users
type group
  relations
    define member: [user, group#member]

# The top of the hierarchy. Grants here apply to ALL resource_groups and
# resources that link (recursively) to this application.
#
# Core actions are first-class relations; app-specific actions ride the
# `permitted` + has_permission escape hatch and are checked via `authorized`.
#
# Example (core):       user:slac/admin → can_manage → application:pief
# Example (app-action): user:slac/admin → permitted  → application:pief
#   condition: has_permission { granted_permissions: ["can_manage_groups"] }
type application
  relations
    define permitted: [user with has_permission, group#member with has_permission]
    define authorized: permitted
    define can_read: [user, group#member]
    define can_edit: [user, group#member]
    define can_delete: [user, group#member]
    define can_manage: [user, group#member]

# A grouping of resources (e.g. an instrument like "lcls"). Self-referential:
# groups nest to arbitrary depth via `parent`, and inherit from their parent
# (an application or another resource_group).
#
# Hierarchy link: application:pief        → parent → resource_group:pief/lcls
#            (or) resource_group:pief/lcls → parent → resource_group:pief/sub
type resource_group
  relations
    define parent: [application, resource_group]
    define permitted: [user with has_permission, group#member with has_permission]
    define authorized: permitted or authorized from parent
    define can_read: [user, group#member] or can_read from parent
    define can_edit: [user, group#member] or can_edit from parent
    define can_delete: [user, group#member] or can_delete from parent
    define can_manage: [user, group#member] or can_manage from parent

# A leaf resource (e.g. an experiment like "expX"). App- and
# group-level grants flow down the chain via the native relations / `authorized`.
#
# Hierarchy link: resource_group:pief/lcls → parent → resource:pief/expX
#            (or) application:pief          → parent → resource:pief/expX
type resource
  relations
    define parent: [application, resource_group]
    define permitted: [user with has_permission, group#member with has_permission]
    define authorized: permitted or authorized from parent
    define can_read: [user, group#member] or can_read from parent
    define can_edit: [user, group#member] or can_edit from parent
    define can_delete: [user, group#member] or can_delete from parent
    define can_manage: [user, group#member] or can_manage from parent

# Condition evaluated at check time for app-specific actions only.
# The caller passes `required_permission` (the action being checked) and the
# tuple carries `granted_permissions` (the list written at grant time). Core
# actions do not use this condition — they are native relations.
#
# A check succeeds when the required permission is in the granted list.
condition has_permission(required_permission: string, granted_permissions: list<string>) {
  required_permission in granted_permissions
}