[C# 2.0] Role Based Security en custom DB

[DrDelete]

Ik zit met een complex vraagstuk t.a.v. Role Based Security, ik ben er enigzins theoretisch bekend mee, alleen ik kom er niet helemaal uit.

Ik moet een technisch ontwerp schrijven voor een intranet applicatie, geschreven in ASP.NET 2.0 (C#, Visual Studio 2005); database is SQL Server 2005.

De context:

- geen user management in de applicatie zelf; dit is dus volledig uit handen (corporate list) gegeven (active directory van het domein), dus windows authentication
- ik heb dus ook geen invloed op de groepen van deze users
- single sign on is erg wenselijk
- gebruikers kunnen projecten maken en bij elk project wordt de owner (user) opgeslagen en daardoor weet ik altijd de divisie bij dit project. Divisie wordt bij de gebruiker opgeslagen in mijn eigen SQL Server database
- de applicatie heeft autorisatie nodig dmv 3 rollen

1. NL: iemand op NL niveau mag alle projecten van alle divisies openen (en daarna alle data daarvan wijzigen) en een project maken voor zijn divisie.
2. Divisie: iemand op divisie niveau mag alleen alle projecten van die divisie openen (en daarna alle data daarvan wijzigen) en een project maken voor zijn divisie, dit is de default autorisatievorm
3. Admin: iemand op admin niveau mag de stamtabellen wijzigen, rollen toebedelen en alle projecten openen en wijzigen.

Ik wil dus bij een user nog wel wat extra opslaan, namelijk:

• de divisie waar ie bijhoort
• de rol die de user heeft: divisie, NL of admin

-
- Ik wil een aantal menuopties mbt beheer van stamtabellen en roltoewijzing alleen enablen voor admins
- Iemand in de rol "NL" mag alle projecten openen (data filtering op de project list)
- Iemand in de rol "Division" mag alle projecten openen van zijn divisie (data filtering op de project list)


Mijn vraag:
Hoe kan ik met RBS dit oplossen? Ik zou graag de "IsInRole" functie willen gebruiken hiervoor om zo button te disablen of een filtering toe te passen op project lijst.

[ Voor 6% gewijzigd door DrDelete op 26-09-2008 16:51 ]

[jip_86]

code:

<authentication mode="Windows"></authentication>
<identity impersonate="true"/>

In je web.config. Als je op je inetmgr anonymous authentication uitzet gebruikt de pagina al het windows account. IsInRole kun je vervolgens gebruiken om dingen wel of niet te laten zien. Met beheer zul je dan moeten afspreken welke AD groepen er gebruikt kunnen worden voor je applicatie.

edit: als je geen AD groepen kan gebruiken zul je in de applicatie nog een onderdeel moeten hebben waarin je gebruikersnamen gaat koppelen aan rollen.

Heb je wel AD groepen en je moet in je applicatie je groepen nog toe kunnen wijzen aan accounts zou je eens kunnen kijken in de System.DirectoryServices namespace. Daar is oa ook beheer van groepen mee te realiseren.

[ Voor 32% gewijzigd door jip_86 op 27-09-2008 16:55 ]

[Spiral]

Heb je al naar de IPrincipal interface gekeken die kan je gebruiken om custom RBS demands te maken.
Zie: Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

[Orphix]

Helaas zullen de bestaande providers je niet tot het eind brengen. Dit komt omdat de standaard role based security mechanisme vrij grof is: ofwel je bent in een rol of je bent het niet. Dit is onafhankelijk van context, bijvoorbeeld in welke divisie je zit of welk project je wilt openen.

Ik zou voortbouwen op de huidige Principal classes en daar extra methodes aan toevoegen die het mogelijk maken om niet enkel op rol, maar tevens op rol+divisie te checken. Dit is een stukje handmatig programmeer werk wat je zal moeten doen. Het implementeren van je security via principals is wel de aan te bevelen, en aangewezen, manier om het op te lossen.

[ Voor 3% gewijzigd door Orphix op 27-09-2008 20:41 ]

[Face_-_LeSS]

Mogelijk is Microsofts AzMan een optie? Ergens in het .NET Magazine staat dit artikel (PDF). Weliswaar geen RDB ondersteuning maar best een handige tool!

[Alex]

Orphix schreef op zaterdag 27 september 2008 @ 20:40:
Helaas zullen de bestaande providers je niet tot het eind brengen. Dit komt omdat de standaard role based security mechanisme vrij grof is: ofwel je bent in een rol of je bent het niet. Dit is onafhankelijk van context, bijvoorbeeld in welke divisie je zit of welk project je wilt openen.

Dit snap ik niet. Ik zou gewoon een eigen provider schrijven voor dit geval(of 2 eigenlijk, membership en rolemembership). Dan heb je alle voordelen van een goed interface, en je kunt makkelijk de rol in rol / groepen schrijven. Support voor single-sign-on is er ook. Dus waarom moeilijk doen met IPrincipal? Dat kost alleen maar een hele hoop werk, waarbij je er op het einde achter komt dat het ongelooflijk complex is geworden.