[Java] rol based authorisatie (met JAAS)

[Standeman]

Ik ben bezig om een web app te beveiligen en er voor te zorgen dat er onder meer rollen gedefinieerd kunnen worden van wat users mogen en wat niet. Vrijwel automatisch kom ik uit op JAAS. Nou is het niet zo moeilijk om JAAS te gebruiken in bijv. Tomcat, er zijn namelijk tientallen tutorials te vinden die dat beschrijven. Getting started is dus niet de uitdaging.

Waar ik nu wel over zit te piekeren is in welke laag of lagen (data/business/presentatie) ik de de authorisatie ga regelen. Uiteraard in komt er gedeeltelijk het een en ander in de presentatie laag omdat aan de hand van de rollen dingen wel / niet getoond mogen worden en soms de flow wat anders is.

De vraag is wat en hoe ik in de andere lagen dan de authorisatie ga regelen. Ik neig nu sterk naar de datalaag (DAO's) waar ik kan gaan checken of aan de hand van de rol iemand wel de één van de (CRUD) acties mag uitvoeren. Het probleem hierbij is dat wanneer ik over wil gaan op bijv. JPA (het is nu JDBC) ik het hele riedeltje zo'n beetje weer opnieuw mag implementeren. Ander nadeel is dat de scope van de gedefinieerde rollen vrij beperkt wordt. Ik zal hier een klein hypothetisch voorbeeldje van geven van de verhuizing van een afdeling:

Java:

public class DepartmentService()
{
  public void move(Department department, Location location)
  {
    //start transaction
    for (Employee employee : department.getEmployees();
    {
        //Some employees work at home
        if (employee.getLocation().equals(department.getLocation())
        {
            employee.setLocation(location);
            employeeDao.save(employee);
        }
    }
    department.setLocation(location);
    departmentDao.save(department);
    //end transaction
  }
}

Als ik het in de DAO wil gaan oplossen ben ik alle context kwijt. Dan moet ik of 2 rollen definieren (Role_UpdateEmployee en Role_UpdateDepartment) en deze checken in de DAO's of 1 rol definieren (Role_MoveDepartment) en deze in beide DAO's checken.

Ik kan het ook in business laag kunnen regelen (de Role checken in de beschreven method), dan hoef ik het maar 1x te doen en scheelt het mij weer werk wanneer we de JDBC laag gaan vervangen door JPA. Zo ik nu er over nadenk, zal de laatste optie de beste zijn.

Tevens zit ik te kijken of ik ook het één en ander met AOP kan doen. Hoewel ik al blij ben als ik bovenstaande een beetje uitgedokterd heb.

Wat zijn jullie gedachten hier over? Weet iemand nog goede (online) bronnen over dit onderwerp?

[Macros]

In EJB's heb je ook rollen. Met een klein beetje werk kan je de rollen van JAAS ook gebruiken in je EJB security declarations. Je hebt ook een niet standaard framework i.s.m. Spring die dit doet voor als je geen EJB's gebruikt. Dat heet volgens mijn acegi. Met beide methodes kan je configureren welke rollen welke business methods aan mogen roepen.

[Standeman]

Macros schreef op woensdag 04 november 2009 @ 14:02:
In EJB's heb je ook rollen. Met een klein beetje werk kan je de rollen van JAAS ook gebruiken in je EJB security declarations. Je hebt ook een niet standaard framework i.s.m. Spring die dit doet voor als je geen EJB's gebruikt. Dat heet volgens mijn acegi. Met beide methodes kan je configureren welke rollen welke business methods aan mogen roepen.

Van EJB's is in principe nog geen sprake van. Het is nogal een simpele webapp met de drie standaard tiers. Ik heb inmiddels Spring security (c.q. Acegi) ook al op het netvlies staan, ik moet me er echter alleen nog in verdiepen en er mee spelen.

[Maniacs]

Aangezien authorisatie ook gewoon functionaliteit is zou het het beste passen in de business laag. Nadeel hiervan is dat de gebruikers van je applicatie pas merken dat ze iets niet mogen zodra de business functionaliteit uitgevoerd gaat worden. Het is daarom gebruiksvriendelijk om ook een vorm van authoristatie toe te passen in de gui; laat acties waarvoor een gebruiker niet is geauthoriseerd niet zien.

Gr,
Mark

[JKVA]

Security hoort wat mij betreft sowieso in je business/service laag. Dat geldt niet alleen voor rollen, maar ook voor andere constraints (bv. gebruikers mogen alleen eigen preferences bewerken of een gebruiker die met een zwak token is ingelogd mag alleen overboekingen naar eigen rekeningen doen).

EJB is niet de enige manier waarmee je identity propagation kunt creeeren. Een simpele ThreadLocal i.c.m. Filter is voldoende om je rollen in alle lagen beschikbaar te hebben. Daarna heb je nog een manier nodig om je security constraints uit te drukken op iedere method, bijvoorbeeld met annotations. Met AOP of een proxy (CGLIB, Javassist, InvocationHandler) kun je daarna weer de boel generiek afvangen.

Je business laag is dan safe. Dat is belangrijk, want je ziet regelmatig dat services hergebruikt worden, onafhankelijk van hoe goed en secure ze zijn opgezet. Als je geen security in je services opneemt, wordt het de verantwoordelijkheid van de client code en dat wil je niet. Vanwege controleerbaarheid, want bij security audits sta je veel sterker als je je beveiliging op een centrale plaats regelt. Vanuit onderhoudbaarheid, want als je het niet in je service regelt, wordt de client code verantwoordelijk, met in het beste geval code duplicatie tot gevolg. In het slechte geval wordt security vergeten.

Volgende stap is het verbergen van UI functionaliteit. Dat moet je helaas gewoon per geval afvangen. Voor JSF zijn componenten beschikbaar waarmee je heel gemakkelijk declaratief componenten kunt verbergen (visibleOnUserRole en enabledOnUserRole attributen in Tomahawk). Eventuele resterende UI checks kun je in JSF afvangen met ExternalContext#isUserInRole(). In andere frameworks heb je vergelijkbare constructies.

Check: http://wiki.apache.org/myfaces/User-role_Awareness

Met EL kun je heel gemakkelijk een custom function maken zodat je zoiets kunt doen ${isUserInRole("admin")}. Dat werkt in iedere JSP gebaseerde applicatie.

Overigens, bovenstaand verhaal over proxies, annotations en zo, dat heeft Spring Security standaard. Check de @Secured annotation.