Enterprise Java Development@TOPIC@
Secure access to EJB and Web applications
Decouple business logic from common tasks
Provide for asynchronous processing.
Re-use the eLeague and eClub implementations from projects 1 and 2.
Implement authentication and access restrictions for EJB methods and WEB URIs thru declarative and programmatic APIs.
Implement authentication for RMI and HTTP(s) clients.
Implement DTO validation using interceptors.
Implement a filterable, publish/subscribe capability with portable payloads between applications.
Schedule and invoke certain behavior based on an EJB timer.
The project will build on the core implementation from Projects 1 and 2. We will mostly extend existing projects with security and asynchronous logic.
JavaEE defines authentication and authorization to be independent of the overall API and capability. JBoss and other application servers provide default mechanisms behind the scenes to implement these features -- that can make it simple and easy to demonstrate. A switch to more realistic and sophisticated mechanisms should require no change to JavaEE-compliant application code. We will use the simple, default "other" security-domain defined within the standard JBoss installation. This uses the RealmUsersRoles login-module -- which is powered by two property files supplied and pre-populated by the course server files from ejava-wildfly(version) in your course examples source tree. You unzipped this file into your application server configuration as part of course setup and it would be wise to repeat that to make sure your server configuration is up to date with any changes added since then.
Table 26.1. User Credential Files
| File | Description |
|---|---|
| ${jboss.server.config.dir}/application-users.properties | defines username=password lines that list the login username and hashed password |
| ${jboss.server.config.dir}/application-roles.properties | defines username=role1,role2 lines that list the login username and assigned roles |
${jboss.server.config.dir} is a reference to an internal JBoss variable that references the "standalone/configuration" directory.
$ ls standalone/configuration/application*.properties standalone/configuration/application-roles.properties standalone/configuration/application-users.properties
We are going to have several types of user roles. Some of the users will have zero, one, or more of these roles. Because of the static nature of our demonstration authentication solution, all users will have a login configured before the application is even deployed to the server.
Table 26.2. Application Roles
| Role | Description |
|---|---|
| (anonymous) | These users can view standings and schedules in league |
| eleague-sys | Authorized to publish to eLeague topic |
| eleague-user | Authorized to subscribe to eLeague topic |
| eleague-admin | Authorized to reset and populate the database |
| eleague-coord | Authorized to create season, divisions, clubs, and schedule contests. |
| eleague-clubcoord | Authorized to create teams, provide contacts for the teams, and assign them to divisions. |
| eleague-divcoord | Authorized to report scores. |
| eclub-admin | Authorized to run ClubTestUtil operations. |
| eclub-member | Authorized to obtain team rosters and update contact and role information. |
| eclub-coord | Authorized to create teams and assign players, coaches, and managers. |
If a user has a login for one application, they will use the same account to access the other application (e.g., user2 has both eleague-clubcoord and eclub-coord roles).
The "sys" accounts are meant to be used by the application code when actions taken require an authenticated user but there is no caller context (e.g., async callbacks) or the identity of the incoming caller is not appropriate for the outgoing call being triggered (e.g., elevated permission access).
Table 26.3. User Roles
| User Login | Roles |
|---|---|
| known | (no roles) |
| eleaguesys1 | eleague-sys |
| eclubsys1 | eleague-user |
| admin1 | eleague-admin,eclub-admin |
| lmtucker | eleague-coord |
| user2 | eleague-clubcoord,eclub-coord,eclub-member |
| user3 | eclub-member |
| jtflynn | eleague-divcoord |
Based on the test data, the following are some other logins that may be useful. They have been added to your users and roles property files and are referencs either in the ingested XML file or part of the end-to-end demonstration steps.
Table 26.4. Other Users/Roles
| Role | Users |
|---|---|
| eleague-clubcoord | tbswanson, kdromero, sthart, lmfuller, rgrobbins, gchamilton, avschultz, jcbell, user4 |
| eleague-divcoord | jddavidson, whlee, pjjimenez, ksharrison, acrussell, ckriley5687 |
To clarify, your application will have a static set of logins and will dynamically ingest a set of Contacts at scenario startup. More Contacts and Members will be added during the scenario. A user with a login and no Contact/Member info within the database can login, but won't be able to do anything meaningful to them personally. A user with a Contact/Member defined and no login won't be able to access the protected areas of the system. Normally the login would be created at the same time the Contact/Member is added. Except for your JBoss configuration and your add user logic, no other part of your project should be aware of this tradeoff made for class project simplicity.
Some actions are open to any users; authenticated or not. Authentication will be performed using a JNDI login for RMI, BASIC for HTTP web services, and FORM for Web UIs. All users will have a password of "password1!".
We will optionally (for the assignment) use HTTPS to provide confidentiality between our client and server for communications. The server has a keystore for identity. The JUnit tests can conveniently use that as a trustStore through the base path defined by the "jboss.home" property.
# build/dependencies/pom.xml
<java.truststore>${jboss.home}/standalone/configuration/application.keystore</java.truststore>
...
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<javax.net.ssl.trustStore>${java.truststore}</javax.net.ssl.trustStore>
Table 26.5. HTTPS Keystore(s)
| File | Description |
|---|---|
| ${jboss.server.config.dir}/application.keystore | Self-signed JKS keystore with server certificate. Also also used as client trustStore during testing. |
jboss.home is a property you should define in your "$HOME/.m2/settings.xml" file and have it reference your installation directory for JBoss/Wildfly.
# .m2/settings.xml
<profiles>
<profile>
<id>wildfly13</id>
<properties>
<jboss.home>.../apps/wildfly-13.0.0.Final</jboss.home>
</properties>
</profile>
...
<activeProfiles>
<activeProfile>wildfly13</activeProfile>
<activeProfile>h2db</activeProfile>
</activeProfiles>
Although essential in securing communications, SSL and/or HTTPS is not a requirement for implmenting this assignment. The instructions above are provided for students wishing to satisfy a key but not very noticeable portion of a secure interface.
For asynchronous activity, we will implement a Schedule JMS Topic where eLeague will publish messages related to team schedules. eClub will subscribe to the topic using a Message Driven Bean (MDB) to keep members up to date on schedule changes. The JMS topic has already been added to your JMS Server within JBoss and has been assigned both an internal and external JNDI name. You will have to design the message type, message properties, and payload of the messages sent on that topic in order that the message carries a partable payload and can be filtered for subscriber-specific criteria via a JMS selector. Your DTOs already express a portable expression of data. Each club will only want to process messages for their teams and only events that impact upcoming schedules (i.e., not scores of completed Contests).
<jms-topic name="esport-eleague-contests"
entries="java:/topic/ejava/projects/esport/eleague-contests
java:jboss/exported/topic/ejava/projects/esport/eleague-contests"/>
eLeague will use EJB Timers to send out schedule reminders for upcoming Contests.