Detaljstyre tilgang

[xibriz]

Hvordan kan man best mulig detaljstyre tilgang.

 

La oss si at man har en modul med mange funksjoner og elementer.

 

En modul kan for eksempel være bilparken.

Noen funksjoner kan være å administrere alle biler og se status på alle bilene.

Elementene er alle bilene som finnes.

 

 

Hvis man nå skulle gi en person tilgang til å se status på bil X, hvordan blir det i praksis?

 

 

 

Burde man ha ett eget objekt til modulen som man tilknytter en person?

 

Objektet inneholder informasjon om at personen har tilgang til modul "bilparken", funksjon "status" og element "X"?

 

Eller er det andre måter å gjøre dette på`?

 

 

 

[Gjest Slettet+9871234]

Jeg antar at du snakker om programmering.

 

I de enkleste tilfellene bruker man if og else, mens man i mer kompliserte tilfeller vil bruke case / caseif / switch o.l. avhengig av programmeringsspråk.

[quantum]

I de enkleste tilfellene bruker man if og else, mens man i mer kompliserte tilfeller vil bruke case / caseif / switch o.l. avhengig av programmeringsspråk.

 

Nei, altså det er definitivt ikke måten å gjøre det på. Det vil bare føre til at systemet blir umulig å vedlikeholde og fullt av sikkerhetshull. Medmindre man skal utvikle et sikkerhets- og autorisasjonsrammeverk, da kommer man nok innom if og case :o)

 

De fleste "plattformer" har rammeverk som løser dette. Eksempelvis kan man på Java benytte f.eks. JAAS eller Spring Security. Andre plattformer har andre løsninger.

Endret 4. juli 2014 av quantum

[Gjest Slettet+9871234]

Så du ville brukt objekter med ulik funksjonalitet?

[quantum]

Så du ville brukt objekter med ulik funksjonalitet?

 

Tja, nei, si det, du ...

[Gjest Slettet+9871234]

De fleste "plattformer" har rammeverk som løser dette. Eksempelvis kan man på Java benytte f.eks. JAAS eller Spring Security. Andre plattformer har andre løsninger.

 

Jeg synes OP var litt uklar, men det syntes vel ikke du siden du gav et så presist svar.

[quantum]

 

Jeg synes OP var litt uklar, men det syntes vel ikke du siden du gav et så presist svar.

 

 

Riktig. Det var et generelt spørsmål, med et generelt svar - bruk et rammeverk som er tilgjengelig og utbredt på den plattformen applikasjonen er bygget på. Hyggelig at du likte svaret, forresten ;-)

Endret 4. juli 2014 av quantum

[rockPaperScissors()]

Hvordan kan man best mulig detaljstyre tilgang.

 

La oss si at man har en modul med mange funksjoner og elementer.

 

En modul kan for eksempel være bilparken.

Noen funksjoner kan være å administrere alle biler og se status på alle bilene.

Elementene er alle bilene som finnes.

 

 

Hvis man nå skulle gi en person tilgang til å se status på bil X, hvordan blir det i praksis?

 

 

 

Burde man ha ett eget objekt til modulen som man tilknytter en person?

 

Objektet inneholder informasjon om at personen har tilgang til modul "bilparken", funksjon "status" og element "X"?

 

Eller er det andre måter å gjøre dette på`?

 

 

 

 

Ok, litt hjernespinn skrevet på lavt blodsukker.. om vi tenker oss at dette er en applikasjon som kjører på en relasjonsdatabase.

 

Da kan man ha ett rolleobjekt, som deles i ett mange-til-mange forhold mellom person og bil. Altså en person kan være tilknyttet mange rolleobjekter, og en bil kan være tilknyttet mange rolleobjekt.

 

Med en liten tvist kan man emulere reglene til ett *nix system, der man alltid er tilknyttet til en enkelt rolle "en-til-en" men samtidig være tilknyttet "grupper". Sett at en bruker har brukernavn "bolle", så vil denne brukeren alltid være tilknyttet rolle(objektet) "bolle". Men i tillegg kan denne brukeren også være tilknyttet "admin" og "innsyn" -rolle(objektet) som deles av flere. Rent teknisk kan dette løses i datamodellen ved at rolleobjektet har ett felt IsAUserRole:bool. Applikasjonen ville så måtte håndtere en-til-en forholdet mellom en bruker og bruker-rolle objekt slik at det ikke oppstår ett en til mange forhold. Rolleobjekter er en gruppe dersom IsAUserRole er falsk, og i motsatt fall er rolleobjektet en individrolle.

 

Bil-objektet behøver ikke å vite om tilknyttede roller er for ett individ eller en gruppe, for denne er det akkurat det samme. Men sett fra applikasjonens ståsted har du nå en enkel måte å gi tilgang til en bil enten på bakgrunn av en gruppe eller ett individ. I de fleste tilfeller vil du ønske å gi tilgang på bakgrunn av gruppetilhørighet, og ikke individnivå, med mindre du kan unngå det.

 

Dersom hver av bilene må ha unike typer tilganger (utover f.eks. "se" og "endre"), så anter jeg kontrollen for hvilke rettigheter en rolle får må ligge hos det enkelte bil/bilobjekt.

Endret 4. juli 2014 av rockPaperScissors()

[tingo]

generelt så er det som rockPaperScissors() sier, man bruker rollebasert tilgang. Fra Wikipedia: RBAC.

[quantum]

Det kunne kanskje være en idé for TS å følge kguns subtile hint om å avsløre noe som helst konkret her ...

[xibriz]

Sorry at jeg har vært litt fraværende fra diskusjonen, men jeg har vært på hytta i helgen

 

OK, litt mere info: Applikasjonen er PHP og dataen ligger i MySQL. Jeg har tenkt at en rollebasert modell er veien å gå, kanskje det finnes noen rammeverk.

 

Hvis vi ser på eksempelet mitt så er modulene og funksjonene statisk, mens elementene er dynamisk. Det virker da logisk for meg å begrense tilgangen til modul og funksjon i kode (en kontroller-klasse som sjekker om ett objekt at tilgang til modul:funksjon, lagret i databasen).

 

Problemet er elementene som er dynamiske. Det kan fort bli problemer hvis person A har tilgang til bilparken(modul):status(funksjon), men bare for bil X. Kanskje han tilogmed har tilgang til å se alle biler av merke Y.

 

Det virker som at det fort kan bli feil hvis man skal teste alt dette i koden.

[tingo]

Hvilke rammeverk har du sett på?

[xibriz]

Jeg har ikke sett på noen spesifikke rammeverk. Jeg har prøvd å se hvordan andre applikasjoner jeg bruker gjør det. Men det er ikke noen som detaljstyrer i den grad jeg ønsker.

 

Problemet er når dataen er dynamiske. Da holder det ikke å bare begrense tilgang til en gitt rapport, men også hvilke elementer som skal kunne eksistere i rapporten. Alternativet er å lage flere rapporter som gjør mer eller mindre det samme, men det vil jeg helst unngå.

[quantum]

Dette kan det jo bli veldig mye administrasjon ut av, er du sikker på at det må være så "detaljstyrt"?

[xibriz]

Som regel har alle full tilgang til en funksjon, men så kommer det noen som er spesielle å da må de detaljstyres.

[rockPaperScissors()]

Nevermind.

Endret 8. juli 2014 av rockPaperScissors()

[xibriz]

Foreløpig er det kun to (dårlige) alternativer som jeg kan komme på:

 

1. Lage flere funksjoner som er mer eller mindre lik

2. Lage noen ferdigdefinerte roller som hardkodes

[rockPaperScissors()]

Det virker ikke så vanskelig, i teorien vel og merke.

 

Uavhengig av "modul" og "element" (bilpark og bil), så kan vi kalle disse for "operation object", heretter oo for enkelhets skyld.

 

Ett oo arver fra ett interface med interface metoder userHasAccess(User user, string accessType), getAccessTypes(), grantRole(string accessType, Role role), withdrawRole(string accessType, Role role).

 

Parameter AccessType er hard-kodete streng verdier som er definert i oo klasse (kan være bil eller bilpark). Dette kan være f.eks. 'view', 'edit', 'delete', what-ever som gir mening for akkurat denne oo. I oo klasse hvor du må sjekke om bruker har tilgang til en viss operasjon, gjør du følgende.

if (userHasAccess($user, 'view') {
    viewReport();
} else if (userHasAccess($user, 'edit')) {
  viewReportAndEditForm(); // Noe sånt..
}

I databasen behøver du en tabell, eller du behøver en modell, som kan være noe i denne duren. Har ikke tenkt gjennom detaljene, bare prøver å skisse ett utgangspunkt.

type_access, role_id, oo_id
'view',            3,          4
'edit',             3,          4
'edit',             9,          4
'delete',         3,          4

I tillegg behøver du ett admin-web-grensesnitt for å kalle interface implementasjonene for grantRole() og withdrawRole() slik at du kan gjøre nødvendige endringer uten å måtte gå rett i databasen...

 

Dette er langt fra ferdig uttenkt vel og merke.

[Lycantrophe]

Det er ikke informasjon som bør lekke - det er noe objektet bør styre selv.