Easy Login - OpenID Connect authentication provider
Easy password-less logins for your web-apps.
This project is originally be meant to be both practical and exploration of technology.
OpenID Connect authentication server stub in development
From practical point of view it is an OpenID Connect compatible authentication server. Mostly to be used in development/testing environments and maybe for some not mission critical production settings. But the main intention is to facilitate development environments, giving developers a test-authentication server, which they can run in their dev environment allowing to develop authentication-enabled apps offline. While, in production this will be swapped with full-featured authentication-server solution, like Keycloak.
Exploration of Jakarta web stack
Developing web applications in Java, Spring Framework is often used as a default choice. Yet, Jakarta EE platform has its MVC implementation provided by Krazo.
Given that Jakarta EE is the official standard for developing enterprise-level Java applications, including web applications it is necessary to explore this technology, and evaluate its fit for purpose, before just jumping into Spring hype-train.
Also, I need some clean reference implementation of authentication server, for my other projects.
This projects also does some exploration into TOTP, as it uses TOTP as its primary authentication method. On one hand it provides a trendy "password-less" authentication, yet, TOTP is primarily designed for a second factor authentication, and using it as one and only way to authenticate, may not be the best idea from security point of view.
Development
Start wildfly with local DB:
docker-compose up -d --force-recreate --build
There is a development helper script deploy.txt which rebuilds and deploys the war to local container.
To shell into local database client:
docker-compose exec db psql postgresql://easylogin_user@localhost:5432/easylogin_db
To shell to local wildfly console:
docker-compose exec wildfly bash -c '$JBOSS_HOME/bin/jboss-cli.sh --connect'
Development web UI accessible:
IntelliJ settings
To run tests using the green triangle is better to set a template for Junit run configurations, which has default VM options set to:
-ea -Djboss.home=build/wildfly-27.0.1/wildfly-27.0.1.Final
To debug Arquillian tests from IntelliJ a Remote JVM Debug configuration need to be added with Debugger mode set to "Listening on remote JVM" port 15007.
To debug Wildfly running in a Docker container a Remote JVM Debug configuration need to be added with Debugger mode set to "Attach to remote JVM" port 15005.
Issues and Workarounds
I have resolves some issues with the platform, and some of them are just common pitfalls, but some are strange and not well known behaviours.
- JSF does not seem to work with the "latest" tag of Wildfly image. Using "27.0.1.Final-jdk17" works.lk
- Must use
Response.accepted("redirect:onboarding").build()syntax for redirects if @RedirectScope is used. Using long syntax of the Response builder with 2XX codes does not seem to follow Location header; and using 3XX code redirects but cannot access object ser to @RedirectScope before redirection. - For mocking to work
@Deployment(testable = true)is required. But it is troublesome still to get it working with Mockito. For now Mockito version is pointing to v4.4.0, as there is not other known good configuration. - Sometimes tests are not executed but build shows successful(!), but in reality no test has run.
07:29:07,646 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-000119: Not generating any bean definitions from dev.luke10x.easylogin.registration.RegistrationControllerTest because of underlying class loading error: Type com.gargoylesoftware.htmlunit.WebClient from [Module "deployment.44fde11d-8f41-4669-8169-32e44babfa56.war" from Service Module Loader] not found. If this is unexpected, enable DEBUG logging to see the full error.I think that in this case it should treat the failure as critical and fail the test.