Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Analyse av videredelering tilgangspakker for virksomheter #887

Open
11 tasks
TheTechArch opened this issue Nov 20, 2024 · 0 comments
Open
11 tasks

Analyse av videredelering tilgangspakker for virksomheter #887

TheTechArch opened this issue Nov 20, 2024 · 0 comments
Labels
area/systemauthentication kind/analysis status/draft Status: When you create an issue before you have enough info to properly describe the issue.

Comments

@TheTechArch
Copy link
Member

TheTechArch commented Nov 20, 2024

Beskrivelse

Denne analysen går i dybden på det mulige konseptet om videredelegering av tilgangspakker.

Konseptet går ut på følgende.

  • Tilgangspakker som delegeres til en virksomhet kan videredelegeres av klientadministrator/hovedadministrator hos mottakende virksomhet
  • Dette gjelder tilgangspakker delegert fra virksomhet og tilgangspakker delegert fra person
  • Standard tilgangspakker som delegeres til en virksomhet arves automatisk til personer med nøkkelroller i virksomheten. (DAGL, LEDE ++)
  • Tilgangspakker som er markert for ikke "automatisk arv" (todo: sett riktig navn på property) vil ikke arves til de med nøkkelroller. De må deleges av klientadministrator
  • Tilgangspakkene kan videredeleges til systembrukere og personer
  • Rolleadministrator vil kunne se

I praksis vil dette kunne anses som en løsning for generell klientdelegering.

Dette behovet er beskrevet i følgende issues.

digdir/roadmap#245

Altinn/altinn-access-management#343

Endring fra dagens rolledelegering

I dag vil en slik delegering ikke kunne videredelegeres uten at tilgangstyring blir delegert samtidig.

Krav

  • Det må vurderes i hvilken grad dette må være tydelig under delegering at dette skjer
  • Når den originale tilgangspakken slettes så må videredelegeringer også slettes.
  • Tilgangspakker definasjoner må få et flagg som tilsier om disse skal automatisk videredelegeres til nøkkelrolleinnehavere. Default vil være at det gjør de. (analyser om dette er et funksjonelt behov)
  • Delegeringer av tilgangspakker må ha flagg som tilser om pakkene kan videredelegers.

Avklaringer

  • Er det ok at tilgangstyrer hos bedrift/persons om har gitt tilgangspakke ser hvem pakken er videredelgert til?
  • Er det aktuelt å kunne gjøre det samme for enkeltrettigheter
  • Hva med tilgangspakker som arves fra ER roller som ikke er REGN/REVI. Skal de være videredelegerbare?

Design

Det må utvikles et design som lar bruker videredelegere. Hvor dette skjer

Alternativ 1 - Som del av vanlig klientdelegering

I dette konseptet blir videredelegering håndert i samme GUI som klientdelegering.

  • Skal man ha filter for type relasjon man ønsker å behandle?

Alternativ 2 - Som del av rettigheter for andre

I dette konseptet blir det mulig å velge å videredelegere fra vinduet hvor man ser hvilke rettigheter virksomheten har fått for andre.

Man bør da kunne få en oversikt over hvilke videredelegeringer som er gjort, og legge til eller fjerne nye videredelegeringer til personer eller systembrukere.

Alternativ 3- Annet?

Noen som har noen glupe ideer her?

Oppgaver

  • [ ]Det må lages en egen delegation check som håndterer dette med at man skal kunne delegere videre fra kunde selv om man ikke er tilgangsstyrer for kunden
  • Utvide tabell for tilgangspakke delegering til å ha en referanse til den originale pakken
  • Utvide sletting av delegerte tilgangspakke slik at den inkluderer alle tilgangspakke delegeringer som er utført grunnet videredelegering
  • Utvide GUI til å presentere slike relasjoner (Skal det vises som en vanlig klientdelegering)
  • Det må lages et API for kunder som inkluderer tilgangspakker eller dagens klientroller. (REGN, REVI)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/systemauthentication kind/analysis status/draft Status: When you create an issue before you have enough info to properly describe the issue.
Projects
Status: 🆕 Ny
Status: No status
Development

No branches or pull requests

2 participants