JaxGuardian (Java-EE-Security)

A customized Java EE security module for Java web applications.

I started working on it to get more familiar with the Java EE security standards, CDI, and Wildfly servers.

So far it has been tested with a Resteasy project and works on Wildfly 25.

How it works

The user authenticates either with a username and a password (Basic Authentication), or with a token.

Short description of the algorithm:

1. The validity of the credentials or token is checked.
2. If the creds are valid, and the user is not currently active somewhere else, the user reaches the endpoints without a problem. A token is generated if the user logged in with username and password and has chosen "remember me".
3. If the user is currently active from another session, both sessions are invalidated, and the user is notified for a possible security issue (a response from the website and/or an email about a suspicious login and that his credentials might have been compromised).

Each request is an HttpServletRequest assosiated with an HttpSession generated by the server when first contacted by a client. If the credentials are valid, a Login object associated with the HttpSession is generated. The object contains not only the session, but details such as the ipAddress, the User-agent, the token (if any), etc. The login-object is an HttpSessionBindingListener, which means that it "dies" as soon as the HttpSession expires, removing itself from the hashmap.

The application keeps a hashmap with usernames and login-objects (i.e. usernames associated with active sessions and ip addresses). When a login object is created (i.e. when there is a new HttpSession), is stored along with the assosiated user in that hashmap. When a user tries to authenticate, the authentication mechanism checks whether there is an active session for the user, i.e. whether there is a key for the username in the hashmap. If any, both sessions are invalidated, along with any tokens to the user (and ideally the application notifies the user that their credentials might have been compromised).

With the current implementation of the mechanism, if one uses this module for a website, the users may receive an email for suspicious login attempts in case they e.g. delete their cookies without logging out first, and then try to login again before the session expires (less than half a minute of inactivity for a token-authenticated user, up to several minutes of inactivity for a username/password-authenticated user that rejected the cookies or did not choose "remember me").

How to use for own projects

1. Make sure there is exactly one class that implements the interface JaxG_NotificationService, and that class is annotated with @ManagedBean. The class is suposed to take care of sending an email with details of the initial and the attempted login (IP/location, time, etc) in case someone appears to login from somewhere else.
2. Make sure there are singleton classes implementing TokenRepo and UserRepo.
3. Create entities for the User and the Token by implementing the respective interfaces of the module.
4. Create a @PermitAll annotated endpoint-class with @Path("/authError"), and a method annotated as @Path("/ERROR/{username}") returning your own customized message as a Response.
5. For deploying to a Wildfly server, deactivate the integrated jaspi of the security domain, while keeping jaspi on, as described here: https://stackoverflow.com/questions/70225352/why-does-this-simple-jakarta-security-example-from-soteria-work-on-payara-but-no

The folder howto includes the stackoverflow replies in case it gets deleted, as well as an adjusted wildfly standalone.xml

How to test with JavaEERestful

1. Run mvn clean install in the JavaEESecurityModule and build the JavaEERestful afterwards.
2. Adjust the standalone.xml of your Wildfly server, or use the one in the /howto folder.
3. Deploy JavaEERestful.war

Any GET request to the localhost:8080/JavaEERestful/rest/endpoint/getCreator will return unauthorized if the username is not "principal", unless a successful session has already been established -the module will not even check the authorization headers if a cookie belongs to an active logged in user. Make sure you delete the cookie if you add invalid credentials after successfully logging in, or wait 20 minutes for the session to be invalidated.

TODOs

1. Notify the user of a suspicious login in case there of an attempted login from a country other than their usual one.
2. A blacklist for particular ip addresses (e.g. of anonymization VPNs or other proxies).