[Orion app-server] Authentication

[Verwijderd]

De afgelopen tijd ben ik bezig geweest met het ontwikkelen van een applicatie, gebasseert op java/jsp, Struts 1.1 RC1 en XDoclet. De hele app draait op Orion 1.5.4.

Als front-end wordt er dus gebruik gemaakt van een combo van html/jsp en struts. Daarachter draaien cmp-beans.

De beveiligingseisen van mijn klant waren nogal hoog. Uiteraard moesten alle gebruikers inloggen. Aan de hand van deze inlognaam werd bekenen welke rollen/privileges de gebruikers hebben. Ook moest de gebruiker na 30 minuten van inactiviteit worden uitgelogt.

Nu ben ik geheel nieuw binnen het session/authentication gebeuren binnen java. Maar een ding is me wel duidelijk, zoals het nu werkt, was niet de bedoeling:

Op het moment vindt de gehele authenticatie plaats tegenover de database. Een gebruiker logged in, en binnen de database wordt gewoon bekeken of de gebruiker met het gegeven password bestaat. Zo ja, geweldig, zo nee, een html:error. Na een succesvolle authenticatie krijgt de gebruiker een websessie, die in de database geplaatst wordt. (iedere gebruiker kan dus een maal tegelijk inloggen)
Aan de hand van deze websessie wordt bij iedere actie die de gebruiker onderneemt gecontroleert of de gebruiker wel ingelogged is.

Het gebruik van deze manier van authenticatie is niet geweldig. Om de websessie uit de database te verwijderen moet de gebruiker expliciet uitloggen (ookal wordt dit ook opgevangen door een javascript onUnload-event). Maar wat als de gebruiker zijn compu uitzet zonder uit te loggen bijv?).

Eigelijk wil ik dus (of lijkt het mij beter) als de app-server de authenticatie voor zijn rekening neemt. Denk bijvoorbeeld aan de eerder genoemde websessies; de app-server kan deze na verloop van tijd geweldig invalidaten, lijkt me. Ik weet dat Orion hiervoor mogelijkheden bied. Al weet ik niet of die voldoen aan mijn eisen, ik kan er vrij weinig documentatie/voorbeelden van vinden.

Maar ik heb niet zoveel ideeen over hoe ik dit ga aanpakken/waar ik ga beginnen. Iemand die me een kick in de goeie richting kan geven of goeie must-reads weet?

[Janoz]

Om je initiele probleem aan te pakken zou je bij elke authenticatie/actie van de gebruiker een timestamp kunnen updaten. Als je nu eens in de zoveel tijd een apparte actie draait kun je alle sessies verwijderen met een timestamp ouder dan een half uur. Die actie kun je aanroepen door een cron achtig iets of bij elk request x% kans.

Mooier is natuurlijk om de authenticatie van de container te gebruiken. In principe kun je een principal, manier van inloggen en rollen gewoon in je web.xml aangeven. Nu heb ik nog nooit met Orion gewerkt, dus ik weet niet hoe ze het daar hebben geimplementeerd, maar het lijkt me dat ze daar ook wel zoiets hebben.

[Verwijderd]

Inderdaad werkt orion met een principals.xml (OID). Maar het moet wel mogelijk zijn om binnen de applicatie (dus door een gebruiker) nieuwe rollen te definieeren. Ik vraag me eigelijk af of dat kan met deze file...

[Bobco]

In Orion is het in ieder geval mogelijk om aan te geven dat een sessie na x minuten invalid wordt:

<session-config>
<session-timeout>30</session-timeout>
</session-config>

in je web.xml zet deze session timeout op 30 minuten. Orion houdt dan zelf in de gaten of er activteiten zijn binnen een sessie en verwijderd automatisch een sessie als er 30 minuten niets gebeurd. Dit vangt dus ook meteen het probleem op van de gebruiker die niet expliciet uitlogt.

In principe is het, denk ik, het mooiste om gebruik te maken van de gebruikers en rollen zoals die door principals.xml wordt geboden. Als het om grote hoeveelheden gebruikers gaat is het misschien makkelijker om deze in een database bij te houden. Je zou dan een authenticatie filter kunnen bouwen dat controleert of een gebruiker een valide sessie heeft. Is dit niet zo dan volgt er een redirect naar een inlog-pagina. Deze logt de gebruiker in en forward dan weer naar de URL die je filter in het request object heeft gepropt.

Als je dan met een filter-mapping elke webresource van je applicatie alleen benaderbaar maakt via je filter ben je denk ik al een eind op weg.