What I would like to do next is have JAAS authentication enabled and wrapped around the ModeShape REST API. I've found multiple sources suggesting bits and pieces of what to configure, but nothing so far that has clear instructions and shows how to get it working.
If anyone has JAAS working for ModeShape in Tomcat, I would be grateful if you could share your configuration, setup instructions, etc.
I think there are 2 different options that have to be considered here:
Option 1: the REST-API web application. If you're using the default MS artifact for this - modeshape-web-jcr-rest-war - this will use HTTP basic authentication requiring the "connect" role. In other words, by default you would configure Tomcat (users.xml or smth) with user=roles pairs and you'd have to make sure that certain users have the "connect" role. On the ModeShape backend (i.e. repository config) you would use "servlet" authentication, meaning the repository would read whatever principal/password is on the request and simply use that for authentication.
To get this layer to use JAAS, you'd have to
a) not use the default WAR but rather wrap it (explode/re-package it) so that it has a modified web.xml file and Tomcat context.xml file (ModeShape's REST Service - ModeShape 5 - Project Documentation Editor) and
b) configure Tomcat to use the JAAS realm
Both (a) and (b) are essentially independent of ModeShape and represent the steps you would take to use JAAS for *any* Tomcat webapp (you can find online detailed resources on how to do this). Note that in this case the repository configuration would remain unchanged and still use "servlet" authentication
Option 2: the repository (config). This is independent of the/any webapp and it refers to how a ModeShape repository will perform the authentication whenever you do a "session.login(user, pass)". In this case you have
a) the "servlet" option (as discussed above), but also
b) a "JAAS" option, where the repository will look at runtime for an existing JAAS policy (named modeshape-jcr by default) and will use that directly to perform any security-related ops. I don't know how you would need to configure Tomcat to define this policy, but the ModeShape docs use PicketBox as an example for the JAAS provider integration (JAAS authentication in Tomcat example)
If you want to understand the inner workings of the repository internal authentication/authorization mechanism in general, I recommend reading the code for this example: modeshape-examples/modeshape-custom-security-example at master · ModeShape/modeshape-examples · GitHub
Note that IMO if the "entry point of your use case" is a webapp, Option 1 is probably what you're looking at.
Thank you. I'll do some further experimentation with the information in your reply
Thank you. I have a very basic JAAS implementation (homebrew and minimal) which is referenced by a Tomcat JAAS Realm.
That does work. While the write-up isn't elegant, I'll share the info here just so we capture it. I'll try to do a blog post later about the setup.
tomcat's server.xml needs a JAAS Realm Added .
In this simple project, I'm calling out two POC clasess for Users and Classes. See project modeshape-jaas-simple and CustomLoginModule
<Realm appName="modeshape-jcr" className="org.apache.catalina.realm.JAASRealm"
catalina.bat or better yet, setenv.bat
gets the following JAVA_OPTS to tell tomcat where to read the jaas.config
would contain something like this, which tells Tomat's JAAS Realm "modeshape-jcr" how to do authentication and get the roles for that user.
Node the custom class name REDACTED.REDACTED.modeshape.jaas.simple.CustomLoginModule
REDACTED.REDACTED.modeshape.jaas.simple.CustomLoginModule required debug=true usersProperties="users.properties" rolesProperties="roles.properties";
- security-constraint section
- url-pattern restricting the url for the REST API
- auth-contraint for role connect
- BASIC mode auth
- realm-name is modeshape-jcr
web.xml snippet below
In that way,
Tomcat will intercept the URL
The JAAS Realm will be used,
- triggering usage of
- custom user principal
- custom role principal
- finally utilizing the CustomLoginModule
The user's user name and roles are passed to the app
If the user has the role of "connect", they get to use the REST API
Simplistic but it actually works.
The users and roles are basically hard-coded in my sample code, not something we'd use going forward, but the matter of how to configure a Tomcat JAAS provider for working with ModeShape is the important part I figured out.
- security-constraint section