[ASP.NET] Role Based Security *

[CaptBiele]

Ik kon even niet 123 een goede topic titel bedenken, dus zal het nu ff duidelijk uitleggen.
Ik ben bezig om een web-applicatie te schrijven in MySQL en ASP.NET
Ik heb een database structuur met oa een User-tabel en een Usertype-tabel.
Nu wil ik graag voor de verschillende usertypes (5 in totaal) bepalen welke functionaliteit ze kunnen zien en welke niet.

Nu kan bijvoorbeeld een "Administrator" de knop "Beheer" wel zien, maar iemand met het usertype "Viewer" natuurlijk niet.

Nu ben ik me een beetje aan het afvragen hoe ik dit het beste in mijn database model kan opnemen. Ik dacht eerst aan een losse referentie tabel, alhoewel ik dan het gevoel heb dat ik iets van het relationele gebeuren verlies.
Verder mag er worden aangenomen dat de usertypes niet of nauwelijks wijzigen.

Ik dacht zelf om een tabel met de attributen (ID), FUNCTIENAAM, FUNCTIEBESCHRIJVING, en 5 BOOLEAN velden voor de usertypes te creeren.
Een voorbeeld van een rij in die tabel wordt dan:

1, "beheer_knop","knop om iets te beheren",1,1,0,0,0

Dan laad ik deze tabel in ASP, en dan controleer ik voor elke functie of de boolean waarde op true staat voor de ingelogde gebruiker.

Ik hoop dat het duidelijk is wat ik precies in gedachte heb. Verder is alle commentaar van harte welkom, want ik heb sterk het gevoel dat mijn voorstel voor verbeteringen vatbaar is.

[Verwijderd]

Die 5 boolean velden moet je meteen schrappen. Kies liever voor een koppeltabel tussen functie en role, en maak alleen entries aan als iemand met een bepaalde role een functie mag zien.

func ( func_id, func_name, func_title )
role ( role_id, role_name, role_title )
func_x_role ( func_id, role_id )

Een simpele INNER JOIN van func met func_x_role en een WHERE clause op role_id levert alle functies die een gebruiker met een bepaalde role mag zien en gebruiken.

In role komen dus jouw usertypes.

[gorgi_19]

Zoek eens op Role-based security. Wil je met booleans voor rechten gaan werken, kijk dan eens naar bitfields

[Verwijderd]

Overigens, dit is zo'n beetje de standaard oplossing, die ook sterk ondersteund wordt in .NET dmv Role Based Security: http://msdn.microsoft.com...ntorole-basedsecurity.asp

edit:
Damn, gorgi_19 is sneller

[ Voor 14% gewijzigd door Verwijderd op 16-05-2004 11:53 ]

[CaptBiele]

Verwijderd schreef op 16 mei 2004 @ 11:47:
Die 5 boolean velden moet je meteen schrappen. Kies liever voor een koppeltabel tussen functie en role, en maak alleen entries aan als iemand met een bepaalde role een functie mag zien.

func ( func_id, func_name, func_title )
role ( role_id, role_name, role_title )
func_x_role ( func_id, role_id )

Een simpele INNER JOIN van func met func_x_role en een WHERE clause op role_id levert alle functies die een gebruiker met een bepaalde role mag zien en gebruiken.

In role komen dus jouw usertypes.

Duh. Dat is natuurlijk wel veel makkelijker jah. Dat ik zelf niet op zo`n simpele JOIN kon komen ... hehe

Verder lijkt het werken met bitfields niet echt nodig, in MySQL werk ik met TinyInts en zoveel functionaliteit heb ik niet.

Verder zal ik ff kijken naar het Role Based security....

[gorgi_19]

Verder lijkt het werken met bitfields niet echt nodig, in MySQL werk ik met TinyInts en zoveel functionaliteit heb ik niet.

Kijk anders even de onderliggende link, dan snap je wel wat ik bedoel.

[CaptBiele]

gorgi_19 schreef op 16 mei 2004 @ 12:19:
[...]

Kijk anders even de onderliggende link, dan snap je wel wat ik bedoel.

ja die had ik gelezen. Voor de performance lig ik niet zo wakker. Het enige voordeel dat ik las was dat deze declaraties thread-safe zijn. En ik weet niet echt wat er mee bedoeld wordt. Misschien betere ondersteuning voor meerdere gebruikers?

Verder ben ik nog dingen aan het lezen over Role based security. Er zit in ieder geval veel in. Is het niet een beetje overkill voor maar 5 verschillende usertypes? of is het gewoon een goede programmeer techniek die je zo veel mogelijk moet toepassen?

[gorgi_19]

Kort samengevat: Je zegt in je openingsposts dat je 5 bit velden hebt. Vervangen dit door 1 32 bits-veld en je kan 32 booleans omzetten naar 1 integer en 1 getal omslaan. Omgekeerd kan je dan 1 getal later weer terugzetten naar deze booleans. Zo kan je later zonder problemen max. 32 rollen kwijt en deze ook later toevoegen.

Dit werkt goed als je vaste rollen hebt. Als je rollen zelf moet kunnen instellen (en ook toevoegen), dan zit je vast aan de methodiek van Cheatah.

ja die had ik gelezen. Voor de performance lig ik niet zo wakker. Het enige voordeel dat ik las was dat deze declaraties thread-safe zijn. En ik weet niet echt wat er mee bedoeld wordt. Misschien betere ondersteuning voor meerdere gebruikers

Nee, multi-threading staat niet voor meerdere gebruikers.

Is het niet een beetje overkill voor maar 5 verschillende usertypes? of is het gewoon een goede programmeer techniek die je zo veel mogelijk moet toepassen?

Al heb je er 2. Het is een bepaalde methodiek van werken, waarbij je bepaalde acties (lezen, schrijven, wijzigen, etc.) afhankelijk maakt van een rol. MS gaat in een aantal voorbeeld applicaties ook uit van 1 admin en 1 normal user.

[ Voor 67% gewijzigd door gorgi_19 op 16-05-2004 12:43 ]

[CaptBiele]

ah ok. Duidelijke taal. Tnx voor de uitleg Gorgi!

Ik ga me flink verdiepen in die Role Based zooi...

[CaptBiele]

Ik heb flink wat articles (zoals deze)gelezen, en heb ook al een werkend voorbeeld aan de praat gekregen.... iets simpels als:

Visual Basic .NET:

if User.IsInRole("Admin") then
    Response.Write ("You are an Administrator")
Else
    Response.Write ("You do not have any role assigned")
End if

Maar nu wordt er alleen gecontroleerd of de ingelogde gebruiker lid is van een bepaalde groep. Maar was is nu de toegevoegde waarde van het Role Based gebeuren? Want deze info kan ik ook makkelijk direct uit mijn db halen....

is er ook de mogelijkheid om de functionaliteit (en de access ervan) bij de Roles zelf te definieren, zodat ik niet meer in alle aspx pagina`s controles hoef uit te voeren?

[gorgi_19]

Maar nu wordt er alleen gecontroleerd of de ingelogde gebruiker lid is van een bepaalde groep. Maar was is nu de toegevoegde waarde van het Role Based gebeuren? Want deze info kan ik ook makkelijk direct uit mijn db halen....

Toegevoegde waarde is onder andere de verduidelijking (rollen zijn gekoppeld aan een gebruikers, alles wordt bij elkaar gehouden op een centrale plaats), de eenvoud, het toewijzen dmv oa de web.config van bepaalde toegangsrechten tot bepaalde pagina's. Verder werk je nu met functies; je kan ook met rollen gaan werken c.q. gebruikersgroepen gaan maken, welke bepaalde rollen kennen.
Ja, je kan direct data uit je database halen en dan vergelijken. Of dat echt praktisch is, is een tweede.

is er ook de mogelijkheid om de functionaliteit (en de access ervan) bij de Roles zelf te definieren, zodat ik niet meer in alle aspx pagina`s controles hoef uit te voeren?

Zie
http://www.dotnetjunkies....spplus/doc/formsauth.aspx
http://www.dotnetjunkies....us/doc/authorization.aspx

Verder kan je een abstract Page-class maken, waarvan je inherit ipv de standaard Page-class. Met behulp van een regel code in het bijbehorende .cs / .vb bestand kan je dan de rollen bepalen welke toegang hebben of niet voor die pagina.

[ Voor 18% gewijzigd door gorgi_19 op 16-05-2004 16:09 ]

[CaptBiele]

tnx gorgi, nu weet ik waarom ik hier mee bezig ben

Ik heb de forms authorisatie geimplementeerd zoals in jouw eerste link. (dit is ook een goede).

Nu heb ik net je 2e link gelezen.... mijn vraag is nu: moet/kan ik meerdere <authorization> secties gebruiken om de toegang tot knoppen/links te bepalen? Want ik wil ook graag in een enkele pagina bepaalde functionaliteit kunnen verbergen...

als ik bijvoorbeeld iets als:

Visual Basic .NET:

<authorization id="knop1">
   <allow roles="Admins" />
</authorization>

kan doen, ben ik heel tevreden......

[gorgi_19]

Dat laatste is weer specifiek in je code...

Een klein voorbeeldje:

Visual Basic .NET:

Dim btnEditTextArea as LinkButton = CType(Me.FindControl("btnEditTextArea"), LinkButton)
btnEditTextArea.Visible = User.IsInRole("Moderator")

In je web.config gebruik je het normaliter voor complete .aspx bestanden.

[ Voor 14% gewijzigd door gorgi_19 op 16-05-2004 16:40 ]

[Verwijderd]

Toevallig ben ik net naar hetzelfde als de TS aan het zoeken. Ik heb alle links ook al doorgelezen maar blijf nog steeds met een onduidelijkheid ivm Roles.

Wat ik versta is dat je de role van een bepaalde user gewoon kan meegeven in een tabel in je database. Ik snap ook dat ergens in je cookie (die je maakt door de login-page) je username meegeeft. Zo kan ik begrijpen dat je in je web.config authorization kan doen op basis van users. Echter, nergens in de voorbeelden zie ik dat in die cookie de role wordt opgeslagen uit de database. Gebeurt dit dan automatisch? of hoe vindt je web.config de "role" die bij een user hoort

[CaptBiele]

gorgi_19 schreef op 16 mei 2004 @ 16:40:

Visual Basic .NET:

btnEditTextArea.Visible = User.IsInRole("Moderator")

Sorry, maar ik snap het nog niet.

Met de functie IsInRole() controleer je, als ik het goed begrijp, of "Moderator" een geldige groep is.
Maar op het moment dat een gebruiker inlogt, doe ik de volgende selectie:

Visual Basic .NET:

cmd.CommandText = "SELECT user_roles FROM iuser WHERE user_email = ? AND user_password = ?"
            cmd.Parameters.Add(New OdbcParameter("", txtUserEmail.Value))
            cmd.Parameters.Add(New OdbcParameter("", txtUserPass.Value))

Dan heb ik toch automagisch al de juiste groep te pakken?

Ik wil graag weten hoe ik kan controleren of die knop zichtbaar is voor die specifieke groep, en NIET controleren of de groep geldig is of niet.....

offtopic:
Misschien moet de topic titel aangepast worden naar Role Based security?

[ Voor 9% gewijzigd door CaptBiele op 16-05-2004 17:04 ]

[Verwijderd]

CaptBiele schreef op 16 mei 2004 @ 17:02:
[...]


Sorry, maar ik snap het nog niet.

Met de functie IsInRole() controleer je, als ik het goed begrijp, of "Moderator" een geldige groep is.
Maar op het moment dat een gebruiker inlogt, doe ik de volgende selectie:

Visual Basic .NET:

cmd.CommandText = "SELECT user_roles FROM iuser WHERE user_email = ? AND user_password = ?"
            cmd.Parameters.Add(New OdbcParameter("", txtUserEmail.Value))
            cmd.Parameters.Add(New OdbcParameter("", txtUserPass.Value))

Dan heb ik toch automagisch al de juiste groep te pakken?

Ik wil graag weten hoe ik kan controleren of die knop zichtbaar is voor die specifieke groep, en NIET controleren of de groep geldig is of niet.....

offtopic:
Misschien moet de topic titel aangepast worden naar Role Based security?

Volgens mij controleert User.IsInRole() wel degelijk of die user tot de door jou opgegeven role behoort. (dus niet of het een geldige role is)
vb:
user1 zit in role "admins"

dan krijg je met user.IsInRole("admins") true als resultaat, maar
user.IsInRole("users") geeft false als resultaat. [natuurlijk als je ingelogd bent als user1]

[ Voor 6% gewijzigd door Verwijderd op 16-05-2004 17:08 ]

[CaptBiele]

Verwijderd schreef op 16 mei 2004 @ 17:08:
[...]

Volgens mij controleert User.IsInRole() wel degelijk of die user tot de door jou opgegeven role behoort. (dus niet of het een geldige role is)
vb:
user1 zit in role "admins"

dan krijg je met user.IsInRole("admins") true als resultaat, maar
user.IsInRole("users") geeft false als resultaat. [natuurlijk als je ingelogd bent als user1]

Ok dat is wel logisch. maar ik heb nu de user_role als attribuut van de tabel User. Dan krijg ik toch direct de juiste role terug? Hoe wordt anders de link gelegd tussen de users en roles? in aparte tabellen?

[Verwijderd]

CaptBiele schreef op 16 mei 2004 @ 17:16:
[...]


Ok dat is wel logisch. maar ik heb nu de user_role als attribuut van de tabel User. Dan krijg ik toch direct de juiste role terug? Hoe wordt anders de link gelegd tussen de users en roles? in aparte tabellen?

Dat is ook mijn probleem. Ik weet dat bij het inloggen automatisch je username ergens in je cookie gestopt wordt. Ik kon echter nog niet ontdekken hoe dat met de role ging.

Van wat ik er van begrijp zie ik het zo:
Op een of andere manier maak je een login-form waarin gecontroleerd wordt of de user in je database zit. Als je een goeie username/pass combinatie hebt kan je inloggen en wordt automatisch een cookie aangemaakt die je username en role bevat [geen idee hoe je dit laatste moet doen]. Als je daarna IsInRole("iets") uitvoert gaat ASP.NET op zoek naar je cookie en checkt de role die daarin is opgeslagen. Stemt de role uit je cookie overeen met die "iets" dan krijg je True als antwoord, anders False.

Het probleem zit hem bij mij dus enkel nog in hoe je die role in je cookie krijgt.

[CaptBiele]

ehm, volgens mij gebeurt dat met de FormsAuthenticationTicket
maar als je hiermee de role in de cookie zet, waarom is dan de controle nodig van IsInRole? om te kijken of er stiekem iets is gewijzigd of zo?

[gorgi_19]

* gorgi_19 gooit de global.asax van IBuySpy in de strijd. Ik denk dat dit eea wel verduidelijkt.

Je hebt authenticatie (definieren van een UserName / UserID) enerzijds en rollen koppelen aan de UserName / UserID. Je kan de rollen opslaan in een encrypted cookie, maar je kan ook bij iedere request de rollen opnieuw ophalen uit de database.

Als je de User Class kijkt, althans, de User class die je normaal oproept in mbv User.IsInRole, zie je dat User een Property is van Context.
Context is 1 Page request geldig. Oftewel: iedere request komt er een User object beschikbaar. In dit user object staat de Username / UserID (dit wordt uitgebreid in ASP.Net 2.0). Vervolgens worden de rollen opgehaald; indien beschikbaar uit het cookie, je kan ook kiezen om de rollen op te halen uit de database. Dit naar gelang de situatie en de expiratietijd van het cookie.

Ik zag iets bovenaan ook een SQL Statement staan om de rollen op te halen. Stel je hebt 1 .aspx pagina, met daarin 30 user controls. De inhoud van de controls wordt samengesteld op basis van een bepaalde rol. Ga je dan ook 30 keer dat SQL STatement uitvoeren?
Nee. Normaliter ga je 1x de boel laden in een context-item. Als je het goed doet vergelijkbaar met een Singleton op basis van Context. En hiermee doe je dus in principe een vergelijkbaar iets als met User.

[ Voor 84% gewijzigd door gorgi_19 op 16-05-2004 17:56 ]

[Verwijderd]

CaptBiele schreef op 16 mei 2004 @ 17:36:
ehm, volgens mij gebeurt dat met de FormsAuthenticationTicket
maar als je hiermee de role in de cookie zet, waarom is dan de controle nodig van IsInRole? om te kijken of er stiekem iets is gewijzigd of zo?

De IsInRole controle is enkel om te bepalen of je toegang hebt of niet. Een voorbeeld maakt het misschien duidelijker dan uitleg:

Stel je maakt een admin-gedeelte op een website (laten we zeggen: een forum-website) waar verschillende mensen op kunnen inloggen (groepen "moderators" en "administrators").
Je voegt enkele mensen toe met de role "moderator" en anderen met de role "administrators".

Je hebt nu een pagina ontworpen waar de hele style van het forum aangepast kan worden. Uiteraard mogen zowel de "moderators" als de "administrators" deze pagina bekijken.
Je kan echter ook aanpassingen maken aan de style. Je wil wel dat je "moderators" deze pagina kunnen zien, maar je wil helemaal niet dat zij je style kunnen wijzigen. Enkel "administrators" mogen dit.

Je kan dit dan als volgt doen:
Je maakt een login-pagina waarop zowel "administrators" als "moderators" kunnen inloggen. Automatisch maakt ASP.NET dan een cookie die de role bevat. Op je style-pagina gebruik je nu de IsInRole("administrator") op de visibility van de "change"-knop (waarmee je dus je style kan aanpassen).

Wat geeft dit nu als resultaat:
Als je ingelogd bent met als role "moderator" dan is de button invisible omdat de IsInRole() False zal geven als resultaat.
Ben je daarintegen ingelogd als "administrator" dan is de button visible en kan je de aanpassingen aan je style doen.

Dat is volgens mij de functie van IsInRole. Het is hierbij dus overbodig van een SQL-statement uit te voeren om in je database te kijken welke role je user heeft. Bovendien is een boolean (IsInRole) een pak makkelijker om te gebruiken bij dit soort toepassingen (visibility etc) dan een String (result van je SQL-query)

Ik hoop dat ik zo wat duidelijk geweest ben, ik ben daar nogal slecht in namelijk

[CaptBiele]

ehm gorgi_held, kun je misschien even aangeven of de implementatie van role-based security (in combinatie met forms based authorisation) voldoet aan mijn eis: dus in een enkele aspx pagina per button kunnen bepalen of deze zichtbaar is voor de huidige gebruiker/groep?

Als dat zo is, zal ik het morgen nog eens ff rustig doorlezen... Wil wel graag weten of dit de goede richting is

Nu ga ik slapen!

Damoke: heel duidelijke uitleg
Voorbeelden zijn altijd heel verhelderend.

[ Voor 21% gewijzigd door CaptBiele op 16-05-2004 18:07 ]

[gorgi_19]

kun je misschien even aangeven of de implementatie van role-based security (in combinatie met forms based authorisation) voldoet aan mijn eis: dus in een enkele aspx pagina per button kunnen bepalen of deze zichtbaar is voor de huidige gebruiker/groep?

Ja

[ Voor 60% gewijzigd door gorgi_19 op 16-05-2004 18:09 ]

[CaptBiele]

ja sorry, jullie posten alweer terwijl ik met mijn post bezig was... ik bedoel dus de implementatie zoals die nu beschreven is... omdat er meer over die IsInRole gediscussierd wordt... En wil graag zeker weten dat dit een nette methode is om bepaalde knoppen te verbergen.

Deze post mag nu weer weg... er gebeurt weer hetzelfde. Wist niet zeker of je mijn edit zou lezen

[ Voor 17% gewijzigd door CaptBiele op 16-05-2004 18:12 ]

[gorgi_19]

CaptBiele schreef op 16 mei 2004 @ 18:10:
ja sorry, jullie posten alweer terwijl ik met mijn post bezig was... ik bedoel dus de implementatie zoals die nu beschreven is... omdat er meer over die IsInRole gediscussierd wordt... En wil graag zeker weten dat dit een nette methode is om bepaalde knoppen te verbergen.

Erhm.. Dat hoort ook allemaal nog bij Role-based security

[CaptBiele]

ok tnx! (bedankt voor je geduld)

Morgen als ik fit ben, ga ik het eens goed doorlezen. Ik geef wel weer een gil als het niet werkt ......

[whoami]

CaptBiele schreef op 16 mei 2004 @ 18:01:
kun je misschien even aangeven of de implementatie van role-based security (in combinatie met forms based authorisation) voldoet aan mijn eis: dus in een enkele aspx pagina per button kunnen bepalen of deze zichtbaar is voor de huidige gebruiker/groep?

Zo is het idd mogelijk.
Als je in je global.asax, in de AuthenticateRequest oid, je roles toekent aan de current principal oid, kan je dan dit doen in je pagina:

code:

if( theUser.IsInRole ("blaat") )
{
    btnZwiep.Visible = true;
}
else
{
    btnZwiep.Visible = false;
}

[ Voor 7% gewijzigd door whoami op 16-05-2004 22:28 ]

[gorgi_19]

whoami: Waarom doe je dan niet:

C#:

btnZwiep.Visible = theUser.IsInRole ("blaat")

?

[whoami]

Bwah, omdat dat een kwestie van smaak is.

In dit voorbeeld zou dat idd wel beter zijn, maar als je meerdere controls zichtbaar / onzichtbaar wilt maken als de user al dan niet tot een bepaalde role behoort, dan zou ik de if / then / else manier prefereren.

[CaptBiele]

Verwijderd schreef op 16 mei 2004 @ 17:25:
[...]
Ik weet dat bij het inloggen automatisch je username ergens in je cookie gestopt wordt. Ik kon echter nog niet ontdekken hoe dat met de role ging.

Die roles staan ook een in tabel. Ik heb de IBuySpy code gedownload, en daarin hebben ze 3 tabellen: Users, Roles, UserRoles....

Zodra er een nieuwe rol wordt toegevoegd, wordt er een combinatie van UserID en RoleID toegevoegd in de tabel UserRoles, mits deze combi al niet bestaat....
(De tabel UserRoles heeft dan ook geen PK)