Results 1 to 9 of 9

Thread: user roles + access control in database applicatie, aanpak.

  1. #1
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357

    user roles + access control in database applicatie, aanpak.

    Gezien de stilte, bij deze een vraag. Dit speelt al langer, maar het nogal open einde ervan heeft me altijd dwars gezeten.

    We hebben een klein database client applicatietje voor interne administratie, en dat is gewoon een aantal tabellen met een kleine, efficiënte GUI. De applicatie is ZEOS-postgresql gebaseerd, en wordt met Delphi gecompileerd, al werkt ie ook wel met Lazarus(*) Dat laatste is zelfs ooit gedemonstreerd op een pannenkoek avond, compleet met raspberry pi server.

    De applicatie heeft geen echte access control, voorbij de normale database inlog credentials. Dat was nooit nodig, maar nu zouden we toch graag wat externe beperkte toegang willen verlenen.

    De eigenlijk vraag is een beetje hoe pak je dit aan, hoe zet je zowat op ? (andere frameworks zijn niet aan de orde, dit is een principe/design vraag, sorry Benno).

    Ik heb wel eens met bestaande frameworks gewerkt, maar nog nooit zowat ontworpen, zelfs niet in een relatief kleine app (12 echte tabellen + nog eens 15 koppel en lookup tabellen)

    Werk je puur op de db access controls, en vang je excepties af? Probeer je het helemaal in de applicatie op te lossen? (extra velden + tabellen, e.d.?) Hoe lastig is het om de gewenste fijnheid van toegang in te bereiken ? In ieder geval op een kern entiteit (lees: een contact; klant of andere zakelijke contact zoals toeleverancier e.d.) moet row level access control zijn, en dat is dus ook zichtbaarheid, niet alleen schrijf rechten.

    (*) er zijn wat kleine event volgorde problemen in het Lazarus compilaat met wat refresh problemen die ik nooit helemaal uitgezocht heb. Kunnen overigens gewoon bugs/aannames in de code zijn.
    Last edited by marcov; 21-Oct-17 at 16:13.

  2. #2
    Ik heb het bij mijn applicatie opgelost met een INTEGER per recht in het gebruikers-record. Ik begrijp dat dat niet helemaal optimaal is en je eigenlijk met subtabellen zou moeten werken maar voor mij was dit voldoende.

    Oplossen in de DB zelf heb ik speciaal niet gedaan omdat het nogal eens voorkomt, intern in mijn programma, dat bepaalde tabellen waartoe de gebruiker niet direct toegang hoeft te hebben, wel geraadpleegd dienen te worden door het programma zelf.

    Overigens gebruik ik dus een INTEGER i.p.v. een BOOLEAN omdat ik naast wijzig rechten ook inkijkrechten wil toekennen.
    0 = geen toegang, 1 = Volledige toegang en 2 = Alleen leestoegang.
    De toegang zelf wordt dus in de applicatie geregeld.

    SQL Code:
    1. CREATE TABLE GEBRUIKER
    2. (
    3.   LINKNUMMER              D_LINKNUMMER,
    4.   VISIBLE                 D_BOOLEAN_T,
    5.   NUMMER                  INTEGER,
    6.   ZOEKNAAM                D_STRING50,
    7.   NAAM                    D_STRING50,
    8.   /* etc, etc */
    9.  
    10.   /* Administratie */
    11.   R_OFFERTE               INTEGER DEFAULT 0 NOT NULL,
    12.   R_OFFTEKST              INTEGER DEFAULT 0 NOT NULL,
    13.   R_OFFAANLEVER           INTEGER DEFAULT 0 NOT NULL,
    14.   R_ORDER                 INTEGER DEFAULT 0 NOT NULL,
    15.   R_ORDTEKST              INTEGER DEFAULT 0 NOT NULL,
    16.   R_ORDAANLEVER           INTEGER DEFAULT 0 NOT NULL,
    17.   R_ORDAFLEVER            INTEGER DEFAULT 0 NOT NULL,
    18.   R_FORMULIER             INTEGER DEFAULT 0 NOT NULL,
    19.   /* etc, etc */
    20. )^

  3. #3
    Senior Member Wok's Avatar
    Join Date
    Dec 2002
    Location
    Alkmaar
    Posts
    2,085
    Ik heb het soortgelijk als Rik opgelost.
    Alleen heb in 1 integer op bitniveau het toekennen van de menu's bepaald (In het verre verleden zo bepaald toen ruimte nog schaars was)
    De action's woorden stuk voor stuk Enabled

    { Systeem
    1 Log
    2 Instellingen
    4 Gebruikers
    8 Administratie
    16 Projecten
    32 Record
    64 Reorganiseren
    128 Import
    256 Tabel
    512 Support

    2048 Maak Database
    }

    Gr.Peter
    10.4.2, Delphi2010, of Lazarus 2.2.0

  4. #4
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Hoe handelen jullie row level filtering af ?

  5. #5
    Ik gebruik geen row level security.
    Bedoel je daarmee dat je per gebruiker toegang tot bepaalde klanten of orders wil geven maar geen toegang tot andere klanten en orders? Dat zou je natuurlijk in code aan kunnen geven. Je kunt daar een bepaalde code voor bedenken en indien die van toepassing is voor die gebruiker, dat je wel of geen toegang geeft tot die selectie van gegevens.

    Maar als je echt voor DB row level security wilt gaan kun je dat met postgresql wel.
    https://www.postgresql.org/docs/9.5/...wsecurity.html

  6. #6
    Hi

    Misschien dat je hier iets aan hebt :

    https://www.getdonedone.com/building...r-application/

  7. #7
    sorry Benno
    no problem, al is kbmMW een prima oplossing ook daarvoor .

    Je vraag is nogal open eerlijk gezegd. In mij pre kbmmw tijd (oude client server) deed ik het vergelijkbaar met de aanpak van Rik en Peter. Ik had een usertabel en een rechtentabel die aangaf of een gebruiker rechten had op een bepaald onderdeel. Dat was dus in feite op actionlist nivo.

    Jij wilt zoals ik het lees ook row level security. Dat is nu typisch iets wat je op je middleware zou oplossen. Je hebt een prima db gekozen, je zou dus kunnen kiezen om die logica in de db te leggen. Niet mijn advies omdat dat uiteindelijk een onderhouds hel wordt, maar mogelijk voor jou voldoende.

    Je zou ook kunnen overwegen je security vast te leggen in rollen. Rollen hebben rechten, users hebben een of meer rollen. Zeker bij veel gebruikers scheelt je dat werk, omdat je de rechten maar 1 keer hoeft vast te leggen. De authorization manager van kbmMW is bijvoorbeeld daarop gestoeld. Vergelijk het met de manier waarop het in een windows domein werkt.

    TMS heeft ook een component voor dit doel. Zelf nooit gebruikt maar mogelijk interessant om te bekijken voor inspiratie. Hun documentatie staat over het algemeen online als pdf.

  8. #8
    Wij hebben de gebruikers ondergebracht in groepen en aan die groepen kan je rechten toekennen. Qua implementatie is het bij ons overigens niet lekker, maar qua idee wel handig, omdat je die groepen inderdaad kan maken aan de hand van rollen, zoals Benno beschrijft, en je gescheiden beheer hebt van wie welke rol heeft, en wat elke rol mag. We overwegen zelfs om die user/rol koppeling naar active directory te brengen.

    Maar dat terzijde werkt het verder eigenlijk zoals bij rik en de rest: rechten per rol, maar niet op row level.

    Daar hebben we wel wat uitzonderingen op. Een voorraadmutatie kan bijvoorbeeld door iemand gemaakt worden, en moet door iemand anders goedgekeurd worden. Door de gebruiker vast te legen kan je daarop controleren en het knopje 'goedkeuren' uitschakelen als de ingelogde gebruiker dezelfde persoon is die de aanvraag heeft gedaan.

    Dan zijn er nog andere dingen die je niet kan zien afhankelijk van het team of de locatie. Iemand in de winkel in Amsterdam kan niet alles zien van de winkel van Rotterdam, en iemand uit het team Outdoor kan wel de sporthorloges aanpassen, maar niet de snelkookpannen. Dat soort logica is wel een maatwerk implementatie op de specifieke plaats. We hebben geen algemeen framework dat teruggeeft of je een rij mag wijzigen of niet. Met een goede middleware is dat ook niet zo erg, want dan zit je implementatie centraal en niet (zoals bij ons) overal.
    1+1=b

  9. #9
    Misschien dat je kunt kijken hoe diverse (gratis en opensource) webapplicaties dit geregeld hebben.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •