Wat is standaard (disallow, allow)

[bassiej19]

Beste Tweakers,

Er wordt ontwikkeld aan een pakket en nu is de volgende discussie ontstaan. Verder niet belangrijk maar ik wil via deze weg de discussie tussen 2 anderen oplossen .


Het volgende:
- Je voegt een gebruiker toe aan 2 groepen. Een groep zegt je mag geen dossiers wijzigen en de andere groep zegt je mag wel een dossier wijzigen.

Wat is standaard?

Onderbouwing persoon 1:
Als 1 groep zegt je mag wel dossiers wijzigen dan lijkt het logische dat je het "wel" mag. Je wordt niet voor niks toegevoegd aan het dossier.

Onderbouwing persoon 2:
Wegens security issues mag je het niet. En bij bijv exchange en open directory. Is het altijd de disallow die overruled.

Dus wie kan weet wat standaard is?

[RedHat]

Dat ligt er geheel aan hoe de allow en disallow entrys tot stand komen.

[BtM909]

MS hanteert als standaard (dacht ik ) dat disallow allow overruled, maar dat hangt dus geheel af van hoe jij je rechtenstructuur wilt opbouwen

[Barryvdh]

In Symfony is het standaard genoeg om 1 allow te hebben, maar je kan het ook zo instellen dat het alleen geldig is als er geen disallow komt. Net wat je zelf wil dus inderdaad..

[Fableguy]

Ik zou in Symfony2 een VoterInterface gebruiken om te voten of iemand door mag met wijzigen of niet. Het is namelijk al en design fout als je een default moet zetten. Je kan er nooit vanuitgaan dat de default niet wijzigt en als het wijzigt kun je flink de sjaak zijn...

[Barryvdh]

Fableguy schreef op woensdag 09 oktober 2013 @ 17:42:
Ik zou in Symfony2 een VoterInterface gebruiken om te voten of iemand door mag met wijzigen of niet. Het is namelijk al en design fout als je een default moet zetten. Je kan er nooit vanuitgaan dat de default niet wijzigt en als het wijzigt kun je flink de sjaak zijn...

Met een Voterinterface geef je toch ook ja/nee/geen mening door en kies je de strategie (affirmative/consensus/unanimous) Dan moet je daar alsnog rekening mee houden. Je moet de strategie inderdaad niet halverwege gaan wijzigen natuurlij.

[CyBeR]

Dat kan allebei, of geen van beiden.

Je kunt bijvoorbeeld inderdaad gewoon standaard zeggen dat een disallow voorgaat. Het kan ook andersom. Apache bijvoorbeeld laat je dit instellen: http://httpd.apache.org/docs/2.0/mod/mod_access.html#order

Je kunt 't ook doen aan de hand van een lijst permissions op volgorde: de laatste match is wat geldt. Zo zou je kunnen zeggen, '1: groep A mag bij resource X; 2: groep B mag niet bij resource X'. Iemand die in groep A zit mag er dan bij, maar iemand die in groep A én B zit niet.

Het is maar net wat je wilt, er is geen "standaard".

[Freeaqingme]

Hangt volledig af van wat voor model je implementeert. RBAC is een veel geimplementeerd model bijvoorbeeld.

In het algemeen geldt dat je een default hebt (allow of deny), en dat de rest (al je specifieke regels) het tegenovergestelde van de default is.

[We Are Borg]

Ik heb een inherit optie toegevoegd per groep waarbij je dus van te voren aangeeft als er een conflict ontstaat, wat er moet gebeuren. Positive of negative inherit. Daarnaast overschrijft een individueel recht altijd een groepsrecht. Maar dat is mijn oplossing voor een recent project

[P.O. Box]

zoals hier boven beschreven komt het neer op wat je zelf wilt...

mij persoonlijk lijkt echter het meest logisch dat een allow in een groep het wint van de disallow in een andere groep... stel medewerker A werkt 2 dagen in de week op afdeling Administratie en twee dagen in de week op afdeling Procesbeheer.... hij heeft in groep Administratie rechten in de administratiemodule, maar in procesbeheer natuurlijk niet.... dan moet medewerker A natuurlijk gewoon kunnen werken, als hij die dag op de administratieafdeling zit en niet geblokkeerd worden door zijn "niet-rechten" op procesbeheer... (in de praktijk kun je medewerker A natuurlijk ook twee aparte inlogs geven, maar het gaat me even om het algemene voorbeeld)

[Douweegbertje]

Wat ik heb gebruikt ooit:

Levels van de groepen.
In feite heb je dan een hiërarchie in je groepen met bepaalde rechten. Ik vind het een logische redenatie op het moment dat je dus 2 of meerdere groepen hebt, waarbij meerdere 'taken' worden ondergebracht. Het is oftewel: je groep klopt niet of er is geen verschil qua 'levels' van de groepen.

Even heel stom gezegd:

Groep Y: a=1 b=2
Groep X: a=2 b=2 c=1

Ongeacht wat de waardes zijn, of wat het inhoud.. je zou moeten zien dat er iets niet klopt? Nu kun je hier wel een "standaard" op gaan verzinnen, wat uiteindelijk je eigen standaard gaat worden. Je kunt altijd zeggen dat een disallow overruled, maar dan moet je dat goed kortsluiten en bij gaan houden.

Logischerwijs is het naar mijn mening 100x beter om één van de 2 voorbeelden te doen:

Groep Z: a=2 b=2
Groep Y: a=1 b=2
Groep X: c=1

Dan kun je gewoon Groep Z + X combineren.

De andere oplossing is:

Groep 1: prio =1 a=1 b=2
Groep 2: prio =2 a=2 b=2 c=1

Waarbij je dan beide groepen toewijst, echter dat je de groepen dus ook ingedeeld hebt op 'niveau'. In dit geval zal je dan beginnen met a=2 b=2 en c=1, waarbij je dan vervolgens a weer op 1 zet, en b blijft 2.

Zo kun je bijvoorbeeld iemand de "basis" rechten verschaffen en daarop hogere 'autoriteits' groepen kunt gooien.

[downtime]

bassiej19 schreef op woensdag 09 oktober 2013 @ 17:16:
Beste Tweakers,

Er wordt ontwikkeld aan een pakket en nu is de volgende discussie ontstaan. Verder niet belangrijk maar ik wil via deze weg de discussie tussen 2 anderen oplossen .


Het volgende:
- Je voegt een gebruiker toe aan 2 groepen. Een groep zegt je mag geen dossiers wijzigen en de andere groep zegt je mag wel een dossier wijzigen.

Wat is standaard?

Onderbouwing persoon 1:
Als 1 groep zegt je mag wel dossiers wijzigen dan lijkt het logische dat je het "wel" mag. Je wordt niet voor niks toegevoegd aan het dossier.

Onderbouwing persoon 2:
Wegens security issues mag je het niet. En bij bijv exchange en open directory. Is het altijd de disallow die overruled.

Dus wie kan weet wat standaard is?

Wat is de standaard als gebruiker lid van geen enkele groep is? Ik neem aan dat hij dan geen recht heeft om dossiers te wijzigen. Waar is dan die Deny groep nog voor nodig?

In Windows overruled Deny een Allow maar wordt Deny in de praktijk bijna nooit gebruikt. Deny heeft namelijk alleen zin als de user ook al een Allow heeft. Maar waarom zou je een Deny geven als het volstaat om de user geen Allow te geven?

[downtime]

P.O. Box schreef op woensdag 09 oktober 2013 @ 21:13:
stel medewerker A werkt 2 dagen in de week op afdeling Administratie en twee dagen in de week op afdeling Procesbeheer.... hij heeft in groep Administratie rechten in de administratiemodule, maar in procesbeheer natuurlijk niet.... dan moet medewerker A natuurlijk gewoon kunnen werken, als hij die dag op de administratieafdeling zit en niet geblokkeerd worden door zijn "niet-rechten" op procesbeheer... (in de praktijk kun je medewerker A natuurlijk ook twee aparte inlogs geven, maar het gaat me even om het algemene voorbeeld)

Dit is natuurlijk een onbenullige oplossing voor een probleem wat niet bestaat. Waarom zou je in vredesnaam een user 2 dagen in de week rechten op iets geven en dan de andere dagen opeens niet? Ik kan me echt geen situatie voorstellen waarbij dat nuttig is.

[Orion84]

downtime schreef op woensdag 09 oktober 2013 @ 21:18:
[...]

Wat is de standaard als gebruiker lid van geen enkele groep is? Ik neem aan dat hij dan geen recht heeft om dossiers te wijzigen. Waar is dan die Deny groep nog voor nodig?

In Windows overruled Deny een Allow maar wordt Deny in de praktijk bijna nooit gebruikt. Deny heeft namelijk alleen zin als de user ook al een Allow heeft. Maar waarom zou je een Deny geven als het volstaat om de user geen Allow te geven?

Het kan handig zijn om uitzonderingen te maken, zonder voor een enkele gebruiker een compleet nieuwe groep met 1 permissie minder op te moeten tuigen. Of bijvoorbeeld een situatie waar het veel makkelijk is om te zeggen: je mag alle dossiers bewerken, behalve dossier 12 en 27. In plaats van dat je alle dossiers die wel bewerkt mogen worden bij naam moet gaan noemen.

Maar in algemene zin zou ik ook zeggen: vermijd negatieve permissies als het even kan, het maakt de boel (vaak onnodig) complex.

[ Voor 12% gewijzigd door Orion84 op 09-10-2013 21:33 ]

[Barryvdh]

downtime schreef op woensdag 09 oktober 2013 @ 21:24:
[...]
Dit is natuurlijk een onbenullige oplossing voor een probleem wat niet bestaat. Waarom zou je in vredesnaam een user 2 dagen in de week rechten op iets geven en dan de andere dagen opeens niet? Ik kan me echt geen situatie voorstellen waarbij dat nuttig is.

Heel toevallig afgelopen weken hetzelfde verzoek gehad, in dit geval voor de besturing van sportveldverlichting. Bepaalde personen geven bijvoorbeeld op maandag en woensdag training en mogen alleen dan de verlichting aanpassen.

[downtime]

Barryvdh schreef op woensdag 09 oktober 2013 @ 22:15:
Heel toevallig afgelopen weken hetzelfde verzoek gehad, in dit geval voor de besturing van sportveldverlichting. Bepaalde personen geven bijvoorbeeld op maandag en woensdag training en mogen alleen dan de verlichting aanpassen.

Ik vind het maar raar. Het betekent eigenlijk dat ze die mensen op maandag en woensdag vertrouwen maar de rest van de week niet.

Hoe heten die mensen? Dr Jeckyll en Mr Hyde?

[Barryvdh]

downtime schreef op woensdag 09 oktober 2013 @ 22:28:
[...]

Ik vind het maar raar. Het betekent eigenlijk dat ze die mensen op maandag en woensdag vertrouwen maar de rest van de week niet.

Hoe heten die mensen? Dr Jeckyll en Mr Hyde?

Dat is toch bij alles? Als je iedereen zou vertrouwen dat hij alleen doet wat hij mag doen, heb je geen rechtenstructuur nodig. Je wil gewoon de rechten beperken voor wat minimaal nodig is.

[Orion84]

Barryvdh schreef op woensdag 09 oktober 2013 @ 22:44:
[...]

Dat is toch bij alles? Als je iedereen zou vertrouwen dat hij alleen doet wat hij mag doen, heb je geen rechtenstructuur nodig. Je wil gewoon de rechten beperken voor wat minimaal nodig is.

Ten eerste: daar kan je natuurlijk ook in doorschieten. Er zijn talloze situaties te bedenken waar een wat soepelere opstelling veel efficiënter werkt (zowel qua rechtenbeheer, als voor de eindgebruiker), zonder dat het daadwerkelijk substantieel meer risico veroorzaakt.

Ten tweede kan je jouw voorbeeld van alleen op twee specifieke dagen natuurlijk ook prima met positieve regels oplossen.

[Barryvdh]

Orion84 schreef op donderdag 10 oktober 2013 @ 09:03:
[...]

Ten eerste: daar kan je natuurlijk ook in doorschieten. Er zijn talloze situaties te bedenken waar een wat soepelere opstelling veel efficiënter werkt (zowel qua rechtenbeheer, als voor de eindgebruiker), zonder dat het daadwerkelijk substantieel meer risico veroorzaakt.

Ten tweede kan je jouw voorbeeld van alleen op twee specifieke dagen natuurlijk ook prima met positieve regels oplossen.

Klopt, maar daar ging het ook niet over. Ik reageerde alleen maar op de stelling dat het nooit voor kwam dat je op 2 dagen wel iets kon doen en op de rest niet
Maar dat is ook wat er al vaak gezegd is, het is maar net wat je zelf (of de klant) wil.

[MueR]

Persoonlijk zou ik een deny altijd final maken. Die zet je immers niet voor niets. Rollen die niets met feature X te maken hebben horen ook geen permissie in te stellen voor feature X. Als je permissie-systeem dat wel doet is het een stom systeem Permissions horen een Yuuuuuup!, Nope, of Meh terug te geven.

[ Voor 25% gewijzigd door MueR op 10-10-2013 10:32 ]

[Cartman!]

Ik gebruik altijd volgorde in het toewijzen van groepen een conflict handler:

- positive, laat positief staan
- negative, laat negatief staan
- overwrite, gebruik van groep die het conflict veroorzaakt
- ignore, laat staan hoe het stond

Zo heb je precies in de hand hoe het moet gaan lopen. Vrijwel nooit nodig gehad nog overigens

[Freeaqingme]

Ik zou vooral een bestaand model zoeken, en je daar aan houden. Zo zit er in Zend_Acl (van Zend Framework) ook een flaw die er voor zorgt dat in bpeaalde situaties iemand wel toegang heeft, terwijl je zou verwachten dat ie dat niet heeft. Is geen bug, maar als je zowel gaat denyen als allowen is het onvermijdelijk.

[Orion84]

Xacml bijvoorbeeld biedt de volgende standaard beslismethoden (maar is uitbreidbaar):
• Deny-overrides (Ordered and Unordered),
• Permit-overrides (Ordered and Unordered),
• First-applicable
• Only-one-applicable
Meer info, zie:
http://docs.oasis-open.or...acml-2.0-core-spec-os.pdf

[Pathogen]

bassiej19 schreef op woensdag 09 oktober 2013 @ 17:16:
Beste Tweakers,

Er wordt ontwikkeld aan een pakket en nu is de volgende discussie ontstaan. Verder niet belangrijk maar ik wil via deze weg de discussie tussen 2 anderen oplossen .


Het volgende:
- Je voegt een gebruiker toe aan 2 groepen. Een groep zegt je mag geen dossiers wijzigen en de andere groep zegt je mag wel een dossier wijzigen.

Wat is standaard?

Onderbouwing persoon 1:
Als 1 groep zegt je mag wel dossiers wijzigen dan lijkt het logische dat je het "wel" mag. Je wordt niet voor niks toegevoegd aan het dossier.

Onderbouwing persoon 2:
Wegens security issues mag je het niet. En bij bijv exchange en open directory. Is het altijd de disallow die overruled.

Dus wie kan weet wat standaard is?

Naast het feit dat ik 2 tegengestelde permissiegroepen raar vind zonder verdere context is dit een kwestie van security policy afspreken en vastleggen.
Stelt je security policy dat je altijd expliciet toegang moet krijgen, dan maak je gebruik van de eerste optie en zou je tweede groep weggegooid moeten worden, en vice versa.

Naar mijn mening heeft disallow altijd voorrang, dus zou de gebruiker geen toegang moeten hebben.
Echter, naar mijn mening is ook het expliciet toestaan van permissies een betere methode dan het expliciet afschermen van permissies. Dit bedenk ik natuurlijk compleet in de context van mijn eigen werkomgeving.