Geslaagde tweede JCP meeting en update over Java EE 8

Op donderdag 2 februari 2017 werd het tweede NLJUG JCP event gehouden over JSR-375: Java EE 8 Security. De vorige JCP meeting werd bij Ordina georganiseerd, dit keer was het aan de beurt aan CGI. Na de maaltijd begon de presentatie, waarbij voorzitter van de NLJUG Bert Breeman de avond opende om het belang van JCP voor de Java community en de NLJUG te benadrukken.

Rudy de Busscher van C4J was daarna aan de beurt om enthousiast een overzicht te geven van de JSR. Rudy is als Expert Group Member van JSR-375 nauw betrokken bij deze ontwikkelingen en de ideale kandidaat om de aanwezigen hier meer over te vertellen. Hierbij is duidelijk geschetst waarom er een nieuwe security API nodig is:

  • de huidige Security API past niet in de nieuwe cloud architecturen;
  • er is veel tegenstrijdige terminologie in Security-gerelateerde frameworks;
  • er is geen overkoepelende JSR voor security (andere JSR's lossen het ieder voor zich op).

Ondanks dat JSR-375 onder water complex kan zijn, wordt met annotaties het gebruik ervan zo simpel mogelijk gehouden. Een typisch voorbeeld voor het gebruik van een login-pagina kan gerealiseerd worden met de code uit Listing 1 in de backend:


@CustomFormAuthenticationMechanismDefinition(
    loginToContinue = @LoginToContinue(
        loginPage="/login.xhtml",
        errorPage=""

    )

)
public class Servlet extends HttpServlet {
    public void doGet(HttpServletRequest request,
                      HttpServletResponse response) throws ServletException, IOException {
        Principal principal = request.getUserPrincipal();
    }
}

 Listing 1

 

Een essentieel onderdeel van de JSR is de IdentityStoreHandler, die ervoor zorgt dat de verschillende IdentityStores samen een complete authenticatie en autorisatie verzorgen.

Een van de meer opvallende mogelijkheden, die JSR-375 gaat bieden, is de mogelijkheid tot het scheiden van de bron van authenticatie en de bron voor autorisatie. Hierdoor wordt het mogelijk om bijvoorbeeld te authenticeren tegen een LDAP, om vervolgens de bijbehorende rollen uit een aparte database te halen! Een simpel voorbeeld hiervan staat in Listing 2.

Voor het authenticeren van de gebruiker kan een IdentityStore-implementatie worden aangemaakt, die middels het validation type specificeert alleen authenticatie uit te voeren voor de opgegeven Credentials.


@RequestScoped
public class AuthenticationIdentityStore implements IdentityStore {
    @Override
    public CredentialValidationResult validate(Credential credential) {
        //code voor het valideren van de gebruiker
    }
   
    @Override
    public ValidationType validationType() { return AUTHENTICATION; }
}

Listing 2

Daarnaast kan er nog een IdentityStore-implementatie worden aangemaakt, die specificeert de autorisatie uit te voeren voor de CallerPrincipa (zie Listing 3).


@RequestScoped
public class AuthorizationIdentityStore implements IdentityStore {
    @Override
    public List<String> getGroupsByCallerPrincipal(CallerPrincipal callerPrincipal) {
        //code voor het toevoegen van de autorisaties van de gebruiker
    }
 
    @Override
    public ValidationType validationType() { return AUTHORIZATION; }
}

Listing 3

 

Na de theorie was het tijd om zelf in de praktijk aan de slag te gaan. Eelco Meuter en Joep Kokkeler hadden samen een aantal labs voorbereid, waarmee iedereen aan de slag kon. Hoewel er wat uitdagingen waren met het netwerk, waren de opdrachten zelf goed uitgewerkt en was het een goede oefening met JSR-375!

Door hands-on ervaring op te doen met de Security API werden de deelnemers in de gelegenheid gesteld om hun input te geven op de specificatie en Soteria (de referentie-implementatie). Onduidelijkheden, bugs, spelfouten: alle op- en aanmerkingen zijn welkom. Het verzamelen van feedback is immers, naast het verspreiden van de kennis over de JSR's, één van de hoofddoelen van meetings als deze.

De hands-on labs boeiden de aanwezigen zelfs zoveel, dat bijna iedereen bij het openen van de borrel zelfs nog een tijdje doorging met de labs! Na afloop werd er onder het genot van een drankje nog veel nagepraat over zowel de labs, de JSR als security in het algemeen.

Dat er zowel binnen als buiten CGI interesse is voor de JCP meetings blijkt wel uit het aantal aanmeldingen, want met 35 aanwezigen was het een goed bezochte sessie. Dit benadrukt ook duidelijk dat Security een belangrijk onderwerp is in software development.

 

Hoe gaat het ondertussen met Java EE 8?

Afgelopen september onthulde Oracle tijdens JavaOne de gewijzigde plannen voor Java EE 8. Hierbij werd aangegeven om meer aan te sluiten bij de huidige 'Cloud'-trends en toonde ze een ambitieus schema met een release in de tweede helft van 2017. Het ging weliswaar om een voorstel en de uiteindelijke beslissing zou pas genomen worden, nadat er onder andere een nieuwe Community Survey gehouden was. Maar toen de resultaten hiervan eind december eindelijk bekend gemaakt werden, kwamen die wel heel sterk overeen met de voorgestelde wijzigingen…

In het kort komt het hierop neer:

  • Servlet 4.0, JAX-RS 2.1, JSON-B 1.0 en JSON-P 1.1 kregen voldoende stemmen om onveranderd op de planning te blijven staan.
  • JSF 2.3, CDI 2.0 en de pas later toegevoegde Bean Validation 2.0 vormden dan wel geen onderdeel van de survey, maar er is voldoende voortgang geboekt om ze toch erbij te houden.
  • In de resultaten kwam de vraag naar ondersteuning voor OAuth en OpenID Connect vrij hoog voor op de lijst, maar deze worden met het oog op de haalbaarheid van de planning nog niet in Java EE 8 gestopt; Security API 1.0 wordt niettemin wel meegenomen, maar met een andere scope.
  • De vraag naar Management 2.0 en JMS 2.1 is dusdanig afgenomen dat deze updates teruggetrokken zijn en de bestaande versie wordt aangehouden.
  • Ook MVC 1.0 scoorde erg laag en wordt overgedragen aan de community als stand-alone component.
  • De nog op JavaOne voorgestelde Configuration en Health Checking worden, ook vanwege de haalbaarheid, tot een volgende versie uitgesteld.

Liggen de ontwikkelingen nog wel op schema?

In de zes maanden na JavaOne was er duidelijk meer activiteit te bespeuren dan in de periode daarvoor, maar of dat voldoende is om de gestelde deadlines te halen? Er is nog geen enkele 'final draft' gepubliceerd, dus geen van de standaarden zal echt vroeg af zijn. JSON-B lijkt het verst gevorderd, de stemming over 'public review' was afgelopen augustus al met positief gevolg afgerond. JSON-P, JSF en CDI zitten net in de 'public review'-periode of hebben die net afgesloten, en de rest zit nog ergens in het stadium van de 'early drafts'.

Diagram: Status van de verschillende JSR’s voor Java EE 8, eind februari

 

Er moet dus nog behoorlijk wat werk verzet worden om ervoor te zorgen dat alle 9 resterende JSR's vóór het eind van het jaar tot een 'final release' kunnen komen. Daar willen we vanuit de NLJUG natuurlijk graag ons steentje aan bijdragen. We hebben JSR 375, de Security API, dus al geadopteerd, maar daar hoeft het zeker niet bij te blijven! Mocht je geïnteresseerd zijn om bij te springen bij deze of één van de andere JSR's, laat het ons weten op jcp@nljug.org. Dan helpen wij je om je contributie op de juiste plek te krijgen!

 


Referenties: