Hallo,
De applicatie waar ik aan werk is een client die op een JBoss server gedeployde EJB's moet invoken. Daarbij moet de identiteit van de ingelogde gebruiker worden meegenomen. Aan de JBoss kant heb ik de JAAS database server login module geconfigureerd om deze gebruiker te authenticeren en zijn authorisaties te bepalen.
De code is oud en gemigreerd vanaf een EJB2 omgeving (JBoss 4 volgens mij). Er werd gebruik gemaakt van de ClientLoginModule aan de client kant. Onder WildFly 10 (wat we nu gebruiken) werkt dit echter niet meer. De identity wordt niet geassocieerd met de EJB invocations. In plaats daarvan wordt uitgegaan van een met properties geconfigureerde identiteit die dan door EJBClientContext wordt gebruikt (of eigenlijk door ContextSelector<EJBClientContext>).
Ik heb gezocht naar oplossingen en kwam erachter dat ik niet de enige was die hier tegenaan liep, maar het meeste wat ik vond is minimaal 4 jaar oud of net niet helemaal wat ik wil, en soms ook niet meer terug te vinden.
Wat ik nu heb gedaan is een decorator om de ClientLoginModule heen bouwen. De ClientLoginModule handelt nog steeds de communicatie met de callbackhandlers af, vandaar dat ik dat er eerst in heb laten zitten. Na het inloggen kan ik de credentials vinden in SecurityContextAssociation. Daar haal ik ze dus vandaan in de decorator en ik zet ze in static variabelen.
Dan heb ik nog een custom EjbClientContextSelector gemaakt die weer gebruik maakt van die statics bij het aanroepen van de getCurrent() methode. Op dat moment wordt er een nieuwe ConfigBasedEJBClientContextSelector gemaakt voor de gegeven credentials (en op basis van properties in een .properties file) en wordt deze teruggegeven. Omwille van de performance houdt ik de reeds aangemaakte ConfigBasedEJBClientContextSelectors ook bij in een map, met als sleutel wederom de credentials. Wordt er een matchende ConfigBasedEJBClientContextSelector gevonden in die map, dan wordt die teruggegeven ipv dat er een nieuwe wordt gemaakt.
O ja, met credentials bedoel ik username en wachtwoord.
Voordat ik verder ga, wil ik eigenlijk eerst deze oplossing toetsen. Volgens mij denk ik in de goede richting, maar ik heb nog wat twijfels over mijn oplossing. Ik kwam er bijvoorbeeld achter dat ClientLoginModule weliswaar de credentials in SecurityContextAssociation zet, maar dat deze op een zeker moment ook weer verdwenen zijn. Vandaar ook dat ik ze nu bijhoud in mijn eigen decorator. Maar ik weet niet precies wat er gebeurt en dat stelt mij niet gerust.
Mijn vraag is dan ook: kan dit beter/betrouwbaarder/eenvoudiger?
edit: Ik ben hier inmiddels iets verder met het "verdwijnen" van de credentials in SecurityContextAssociation. Ze verdwenen niet, maar het werd aangeroepen door een andere thread waardoor SecurityContextAssociation.getPrincipal() en SecurityContextAssociation.getCredential() null retourneren.
edit 2: Door SecurityContextAssociation.setClient() aan te roepen wordt e.e.a. VM-wide bijgehouden ipv ThreadLocal. Mijn decorator heb ik dus al niet meer nodig nu; ik kan vanuit de custom EjbClientContextSelector rechtstreeks de credentials opvragen bij SecurityContextAssociation.
De applicatie waar ik aan werk is een client die op een JBoss server gedeployde EJB's moet invoken. Daarbij moet de identiteit van de ingelogde gebruiker worden meegenomen. Aan de JBoss kant heb ik de JAAS database server login module geconfigureerd om deze gebruiker te authenticeren en zijn authorisaties te bepalen.
De code is oud en gemigreerd vanaf een EJB2 omgeving (JBoss 4 volgens mij). Er werd gebruik gemaakt van de ClientLoginModule aan de client kant. Onder WildFly 10 (wat we nu gebruiken) werkt dit echter niet meer. De identity wordt niet geassocieerd met de EJB invocations. In plaats daarvan wordt uitgegaan van een met properties geconfigureerde identiteit die dan door EJBClientContext wordt gebruikt (of eigenlijk door ContextSelector<EJBClientContext>).
Ik heb gezocht naar oplossingen en kwam erachter dat ik niet de enige was die hier tegenaan liep, maar het meeste wat ik vond is minimaal 4 jaar oud of net niet helemaal wat ik wil, en soms ook niet meer terug te vinden.
Wat ik nu heb gedaan is een decorator om de ClientLoginModule heen bouwen. De ClientLoginModule handelt nog steeds de communicatie met de callbackhandlers af, vandaar dat ik dat er eerst in heb laten zitten. Na het inloggen kan ik de credentials vinden in SecurityContextAssociation. Daar haal ik ze dus vandaan in de decorator en ik zet ze in static variabelen.
Dan heb ik nog een custom EjbClientContextSelector gemaakt die weer gebruik maakt van die statics bij het aanroepen van de getCurrent() methode. Op dat moment wordt er een nieuwe ConfigBasedEJBClientContextSelector gemaakt voor de gegeven credentials (en op basis van properties in een .properties file) en wordt deze teruggegeven. Omwille van de performance houdt ik de reeds aangemaakte ConfigBasedEJBClientContextSelectors ook bij in een map, met als sleutel wederom de credentials. Wordt er een matchende ConfigBasedEJBClientContextSelector gevonden in die map, dan wordt die teruggegeven ipv dat er een nieuwe wordt gemaakt.
O ja, met credentials bedoel ik username en wachtwoord.
Voordat ik verder ga, wil ik eigenlijk eerst deze oplossing toetsen. Volgens mij denk ik in de goede richting, maar ik heb nog wat twijfels over mijn oplossing. Ik kwam er bijvoorbeeld achter dat ClientLoginModule weliswaar de credentials in SecurityContextAssociation zet, maar dat deze op een zeker moment ook weer verdwenen zijn. Vandaar ook dat ik ze nu bijhoud in mijn eigen decorator. Maar ik weet niet precies wat er gebeurt en dat stelt mij niet gerust.
Mijn vraag is dan ook: kan dit beter/betrouwbaarder/eenvoudiger?
edit: Ik ben hier inmiddels iets verder met het "verdwijnen" van de credentials in SecurityContextAssociation. Ze verdwenen niet, maar het werd aangeroepen door een andere thread waardoor SecurityContextAssociation.getPrincipal() en SecurityContextAssociation.getCredential() null retourneren.
edit 2: Door SecurityContextAssociation.setClient() aan te roepen wordt e.e.a. VM-wide bijgehouden ipv ThreadLocal. Mijn decorator heb ik dus al niet meer nodig nu; ik kan vanuit de custom EjbClientContextSelector rechtstreeks de credentials opvragen bij SecurityContextAssociation.
[ Voor 10% gewijzigd door cashewnut op 11-01-2017 17:48 ]