Jeg har ikke set på OPA, men vi har enn så lenge endt opp med noe deklarative policy greier, med mulighet for imperative escape hatches.

Telia begynte å innføre det men jeg følgte min clojure drøm før de lærte nok om hvordan det fungerer IRL

Jeg kjenner heller ikke til OPA, men er merkelig nok interessert nok i sånt til at jeg skal kikke på det ved anledning 😄

Vi har noe hjemmelaget policy-greier nå som jeg er relativt fornøyd med

Jeg tenker at det uansett er fornuftig å modellere policy som data.

Enig!

Vår modell er fritt modellert som et subset av AWS IAM sin tilgangsmodell, den syns jeg er innmari fin

(def service-config (merge {:service :workspace-service
                            ::authorization-service/permission-holder-mapping-fn (authorization-service/entity-itself-contains-permission-holder core/id)
                            ::authorization-service/policy
                            {:default authorization-service/admin-or-permission
                             :create authorization-service/custom
                             :delete {::authorization-service/action-policy authorization-service/admin
                                      ::authorization-service/permission {:action :admin}}}}
                           workspace-repo/config))

så kan vi spørre:

(auth-service/authorized? user action entity)

Etter hva jeg har lest, så funker OPA sånn at man kompilerer policyene til… noe, som så evalueres av enten et Go-bibliotek eller et WASM-bibliotek. Ikke helt JVM-vennlig altså. Men de har en ferdig serverprosess i Docker som man kan spinne opp som en egen tjeneste eller en sidecar, til hvilken man deployer de kompilerte policyene. Men nylig har det kommet mulighet for å kompilere policyene til et intermediate format (IR), som man kan evaluere selv. Noen har begynt på en slik Clojure-evaluator her: https://github.com/johanfylling/jarl/ Det hele er litt for omstendelig for mine behov akkurat nå, men jeg skal følge med på det i hvert fall.

Ok, der døde min interesse for OPA 😅

Jeg har data, og du tilbyr meg en opak docker-prosess som erstatning 😂

Vel, med en Clojure-evaluator så forsvinner hele det maskineriet.

til en viss grad

jeg satt det litt på spissen altså

Det blir som (auth-service/authorized? user action entity) fra @slipset sin melding ovenfor - der ville hele OPA-greiene være gjemt inni den svarte boksen som er auth-service.

Dette er implementert i ca 100 linjer Clojure. No Rust, No Docker.

Men min forståelse av OPA nå, er at det er mer enterprise-grade enn jeg trenger. Hvis du trenger å ha felles autorisasjonstjeneste for dusinvis av av tjenester, liksom.

Jepp. Fordelene med å bruke et rammeverk vil kunne inneholde: 1. Hvis du må snakke med andre systemer (som du kanskje ikke eier) så har du et kjent interface. 2. Hvis ideene bak rammeverket er velkjente, så er det mulig at det er enklere at flere (utviklere) forstår hva du snakker om enn hvis det er homebrew Ulempene er at rammeverk ofte er mer generelle enn du trenger, kanskje er mer restriktive enn du ønsker (se vår custom policy) Og at de kommer med Rust og Docker og annen misere.

Hadde det bare vært Rust - dette er Go! (Neida, joda…)

whatever 🙂

Uansett. Autorisering befinner seg i den ugne gråsona mellom generisk logikk og forretningslogikk. Jeg skulle det ønske det fantes en helt generell løsning på problemet, eller i hvert fall en sjekkliste: Gjør sånn her, så blir det bra. Den gang ei. Man må tenke og designe og holde på.

Autorisasjon er etter mitt skjønn forretningslogikk.

Det er jo generiske aspekter ved det. Operasjonene, f.eks. Vi har også en authorized? -funksjon. Og så er det filtrering av lister av ressurser - hvilke av alle ressurser av denne typen har denne brukeren tilgang til?