Scott, if you have time to take a look at the security requirements for the JCA 1.6 implementation that would be great.
Here are a couple of pointers to get started
- Chapter 16 in the specification - it describes requirements plus use-cases
- Investigate security infrastructure in AS/trunk to align requirements
- Create a deisgn for a simple security domain for the standalone project
- Start with a test case where a Work instance uses a SecurityContext
- and build from there
There are a couple of other requirements, since this is one of the big integration points for the project
- Test cases covering the use-cases described
- A chapter in the JCA Developer Guide describing the setup and integration
Keep in mind that this is one of the places where we need an internal SPI such that we can integrate with the standalone setup and the setup used in JBoss Application Server.
You can take a look at the security integration in the current JCA implementation inside AS, but I want a clean design with well-defined integration points - and a documented way of locating the needed information.
For the first implementation of the SPI for the standalone part I would suggest that you start with a simple setup using properties files - similar to the UsersRolesLoginModule idea in JBossSX. And then build from there... The principal mapping tool could just be a file too...
And start with the requirements for the WorkManager (watch out for nested Work submissions with different SecurityContexts) - and save the MessageEndpoints for later.
The code should be located in the core/ module - and feel free to use EmbeddedJCA and the ShrinkWrap support for the test cases.
A simple SubjectFactory implementation has been added to ease testing
A couple of properties
- SecurityDomain -- the name of the security domain (ignored)
- UserName -- the user name
- Password -- the password
The lookup is done on the bean name instead in the standalone distribution.