[JAAS] LoginModule thread safety

[JKVA]

Ik heb me helemaal scheel gezocht op internet, maar kan geen officieel antwoord vinden.

Het probleem: Op mijn project gebruiken we JAAS voor authenticatie en autorisatie. In de applicatieserver (JBoss) hebben we onze eigen custom LoginModule gedefinieerd. Deze wordt ook aangeroepen. Eigenlijk werkt alles goed.

Ik zit alleen nog met één dilemma, namelijk dat ik niet zeker weet of een LoginModule thread safe moet zijn. In de documentatie enzo staat niets over thread safety of concurrency. Aan de andere kant, alle voorbeelden op internet gebruiken gewoon members en geen synchronisatie mechanismen.

Dit is ongeveer de opbouw van de klasse:

Java:

public class MyCustomLoginModule
        implements javax.security.auth.spi.LoginModule {

    private Subject subject = null;
    private CallbackHandler callbackHandler = null;
    private FixedSessionProperties theSessionProperties = null;
    private Ticket myTicket = null;

    public void initialize(Subject subject, CallbackHandler callback,
            Map<String, ?> sharedState, Map<String, ?> options) {
        // initialiseer members
    }

    public boolean login() throws LoginException {
        // gebruik de members
    }

    public boolean abort() throws LoginException {
        // gebruik de members
    }

    public boolean commit() throws LoginException {
        // gebruik de members
    }

    public boolean logout() throws LoginException {
        // gebruik de members
    }
}

Alleen het feit dat er niets over concurrency wordt gezegd in de documentatie baart me zorgen, want ik wil op deze plek geen vervelende race conditions. Security is namelijk vrij essentieel voor dit project...

Weten jullie hier iets van?

[-FoX-]

Elke authenticatie sessie zal normaal gezien een nieuwe instantie van uw LoginModule nemen, en deze reference hierna zal na elke sessie weer gereleased worden.

Uw LoginContext op zich is niet thread-safe, maar dat staat ook zo in de docs vermeld.

[JKVA]

Maar dat een LoginHandler niet thread safe hoeft te zijn, staat dat ook nog ergens? JBoss lijkt het idd ook goed te doen, maar zoiets lijkt me wel in een spec thuis te horen.

Ik kan alleen nergens een JAAS spec vinden...

[-FoX-]

Staat blijkbaar niet zwart op wit in de specificatie, maar bij specifieke implementaties staat het er wel vaak bij vermeld, zoals bvb een LoginModule voor Sun ONE.

Ik ben verder ook geen JAAS expert, meestal maken we gebruik van Spring Security. Ik vraag me wel af wat de keuze voor JAAS heeft bepaald in jouw geval?

[JKVA]

De architectuurafdeling van de klant.

[-FoX-]

Die mensen weten ook altijd de juiste keuzes te maken, ook hier hebben we zo'n geweldig team zitten

Serieus, waarom zou het beter zijn om voor JAAS te kiezen itt Spring Security?

[Verwijderd]

-FoX- schreef op vrijdag 13 juni 2008 @ 14:10:
Serieus, waarom zou het beter zijn om voor JAAS te kiezen itt Spring Security?

Wat is het voordeel van Spring Security boven JAAS dan? Is er nog een gebied waar JAAS geschikter is dan Spring Security?

[flowerp]

-FoX- schreef op vrijdag 13 juni 2008 @ 14:10:
Die mensen weten ook altijd de juiste keuzes te maken, ook hier hebben we zo'n geweldig team zitten

Serieus, waarom zou het beter zijn om voor JAAS te kiezen itt Spring Security?

[beetje sarcastisch]
Waarom zou het beter zijn om voor wat dan ook te kiezen itt Spring?
[/beetje sarcastisch]

[JKVA]

Tja, ieder bedrijf heeft zijn policies. Ik ben ook een Spring fan, maar framework keuzes is hier de verantwoordelijkheid van een andere afdeling.

B.t.w. De reden voor JAAS is omdat SSO met een stel andere applicaties dan gemakkelijker is. Die gebruiken namelijk ook JAAS.

[tweakerbee]

Misschien interessant:
http://springtips.blogspo...g-security-aka-acegi.html

Why use Acegi instead of JAAS? It can be difficult to stray from well-documented standards like JAAS. However, porting container-managed security realms is not easy. With Acegi, this security layer is an application framework that is easily ported. Acegi will allow you to easily reuse and port your "Remember Me," "I forgot my password," and log-in/log-out security functions to different servlet and EJB containers. If you have a standards-based security layer that you have re-created for numerous Java applications and it is not getting reused, you need to take a good look at Acegi. Besides, why are you spending time on framework coding when you should be focusing on the business logic? Leave the framework development to product developers and the open source community.

[ Voor 79% gewijzigd door tweakerbee op 15-06-2008 14:11 . Reden: de interessante passage toegevoegd ]

[-FoX-]

flowerp schreef op zaterdag 14 juni 2008 @ 16:05:
[...]
[beetje sarcastisch]
Waarom zou het beter zijn om voor wat dan ook te kiezen itt Spring?
[/beetje sarcastisch]

Omdat Spring cool is

Er zullen vast wel cases zijn waar JAAS beter inzetbaar is dan Spring Security, maar ik heb nog nooit gebruik moeten maken van JAAS. Daarnaast is het ook wel zo leuk om het security-aspect mee te kunnen packagen met uw applicatie, maar ook dat is niet altijd nuttig.

[flowerp]

-FoX- schreef op zondag 15 juni 2008 @ 14:17:
[...]

Omdat Spring cool is

offtopic:
Ik weet het, ik weet het

Maar de argumenten zijn niet altijd steekhoudend Ik bedoel, als je de echt fanatieke Spring aanhangers zou moeten geloven is er op de hele wereld maar plaats voor 1 ontwikkel platform. Weg met PHP, RoR, ASP, Java EE, etc. Waarom zou je ooit iets anders dan Spring kiezen? Voor elke denkbare situatie is Spring altijd de beste keuze... Maar goed, dit is wel heel erg off topic