Provide all functionality from Projects 1 and 2.
Enhance eLeague with access restrictions.
Assign the EJBs and WARs to the "other" security domain
Restrict access to WEB URIs in WARS
All API calls must allow authentication.
Use BASIC login-config for API calls.
Use of CONFIDENTIAL (HTTPS) is not required for this project but can be easily added if you have time.
Restrict access to the EJB methods to appropriate read/write roles using declarative security.
Administrators may run the test utility functions like reset() and populate().
League Coordinators may create clubs, seasons, and divisions as well as schedule contests. They may also perform duties normally performed by club and division coordinators -- like report scores.
Club Coordinators may create venues, teams, and assign teams to divisions
Division coordinators may report scores
Perform additional programmatic security checks to verify the right user is accessing the appropriate information.
Club coordinators may only manage teams and venues associated with their club.
Division coordinators may only report scores for contests in their assigned division. Note that the League Coordinator should be able to report a score for any division.
League coordinators may report scores for any division without being the coordinator for that division.
Allow any user to perform read operations.
Use Run-As to assign application code a role sufficient to complete its required actions when there is no calling client identity.
Enhance eClub with access restrictions.
Assign the EJB and WARS to the "other" security domain.
Restrict access to the EJB read/write methods to appropriate roles using declarative security.
Administrators may run the test utility functions like reset().
Organization coordinators may create teams and members/roles. They can also assign players, coaches, and managers to teams.
Members may update contact information and obtain roster information.
Perform additional programmatic security checks to verify the right user is accessing the appropriate information.
Members are accessing rosters for teams they are associated with.
Use Run-As to assign application code a role sufficient to complete its required actions when there is no calling client identity.
Extend your existing client code to optionally accept credentials. No credentials provided should invoke a remote method/URI as an anonymous user. Credentials provided should invoke a remote method/URI using the identity associated with the credentials.
For RMI -- dynamically add security principal and credential properties to your runtime JNDI lookup.
For JAX-RS -- dynamically add a "Basic" Authentication header (ideally using a JAX-RS ClientRequestFilter) to each HTTP(S) request.
Extend your existing remote Test project to address new authentication requirements.
Add a valid login to your existing tests to re-enable them under the newly secure environment.
Add a new unit test case that verifies the access controls of the protected and open methods. This means that -- after fixing access issues in the previous bullet -- you purposely attempt to violate access restrictions from a new JUnit test to show a test of access control.
Please see the grading criteria to identify specific scenarios your JUnit tests should address in this area.
Enhance Web-UIs with authentication and access restrictions for any use case you implement requiring access control. Note that your selected use case may not require an authenticated user -- which would render this section not relevant.
Assign the WAR to the "other" security-domain.
Restrict access beyond the main page to users with the appropriate roles. You may use FORM or BASIC authentication.
Permit only users to only ask the EJB tier for information that is associated with their login. For example, a Club Coordinator should not have to tell the Web UI what club they are managing. It should be derived from their identity and information in the database.
BASIC does not support logout/login well
Co-hosting the Web-UI and API in the same WAR will restrict you to using the same authentication mechanism for both. Since we are suggesting use of BASIC for API calls -- we would use BASIC for the Web-UI as well. That functionally works except the use of BASIC and the way the HTTP protocol and browsers work -- it makes it hard to logout to change identity. Keeping the project within scope -- this may limit the number of steps you implement with Web-UI for the end-to-end scenario.
Implement a "thin slice" of capability to demonstrate JavaEE interceptors using validation.
Define javax.validation constraints on at least one of your DTOs.
Implement a JavaEE interceptor that gets a Validator injected, intercepts all calls of your EJBs, and runs the validator against each parameter input to the EJB method.
The interceptor can have no knowledge of the specific EJB, method, or parameters it is intercepting and validating.
The EJB can have no knowledge of the interceptor and should do no work to validate the DTO itself.
In this portion of the project we are going to send and receive a JMS message using publish/subscribe JMS techniques.
Extend your eLeague EJB implementation to publish JMS messages whenever a Contest is scheduled, changes (e.g., scores posted), or for whatever reason the application has for notifying subscribers. You may want to place an artificial limit on the number of messages sent to help keep from being unnecessarily overwhelmed in the development environment. You can decide on any thresholds used.
Use the esport-eleague-contests topic (JNDI names: java:/topic/ejava/projects/esport/eleague-contests and java:jboss/exported/topic/ejava/projects/esport/eleague-contests)
Design your JMS Message to carry a portable payload. You can use any JMS Type you wish. However, know that subscribers will not likely have your implementation JARs with Entity classes. Use of DTO classes works well here.
Design your JMS Message to be filterable using a JMS selector. You can use any properties you wish. However, know that some subscribers will be filtering on such things as the impacted club, team, or type of event.
Have your eLeague EJBs publish JMS Messages to the topic when a Contest changes state (created, canceled, completed).
Note
This means that there are several reasons for a Contest to be sent and that reason should be a filterable part of the overall message properties using a JMS selector.
Implement a Message Driven Bean within eClub to subscribe to contests that are new, rescheduled, or reminders; but not completed (i.e. it should have a selector that causes the MDB to not be told about scores being reported) that invole the specific club. [Note:] The ability to reschedule a contest was not part of the functional requirements and need not be implemented at this time. Just account for the future event and the relevance to the club in your selector.
Use a JMS Selector for the MDB to limit the types of messages consumed.
Obtain the e-mail address for each individual associated with the team effected by the event. Print a textual message and the address list to the server log.
You do not have to physically send an e-mail as a part of this assignment. The key point of this requirement is for your MDB to be able to succesfully access a protected EJB method without a calling client context present.
Implement an EJB Timer that will allow eLeague to automatically wake-up and send out schedule reminders for contests that have not yet finished. Depending on the provided test data, you might want to limit the number of reminders sent. The main goal of this requirement is that you make use of an EJBTimer and that you trigger the JMS filtered MDB logic in eClub.
Your timer can be declarative or programmatic. However, the programmatic approach is recommended so that -- with a remote interface -- your IT integration test can have control over when the events should start and end.