Outside of the discussion regarding how authentication will occur at the protocol level and how this will be cached there will still be a need for an authentication against store of users.
JBoss AS has always shipped with a simple solution that can be used out of the box for the definition of users and their roles, in addition to this there is also a requirement for integration with existing infrastructure so for the initial release I believe we should make the following mechanisms available: -
This is the simplest mechanism currently in use today, one property file is created containing the users and their password and a second property file is created containing the list of roles to assign to each user.
The property file would be placed within a configurable location which in general would be within the JBoss AS installation.
Each AS node would contain it's own copy of the properties files.
At a later point we could review an option for a node to retrieve the properties file from the domain controller on start up but that is not required at this stage.
Within existing security infrastructure user account information is commonly stored within a database, we will support the configuration of authentication against a database.
When running in domain controller mode the management API security will be outside the context of a running AS so we may also need an alternative connection pool mechanism to manage the connection to the database.
Another location commonly used to store user account information is within a directory server accessible using LDAP, we will also support the configuration of authentication against LDAP.
Master Domain Controller
Depending on some other discussions we may have a requirement for clients to be able to establish a connection to each node and authenticate against that node.
Reviewing different mechanisms for the configuration used on the master domain controller to be replicated to the individual nodes is possible but there may still be scenarios where it is not desirable for the exact same mechanism to be used on the non-domain controller nodes, a couple of examples are: -
- Nodes running on restricted network, only outbound communication is to the domain controller.
- The domain controller may be on a different network with less restricted access so whilst the domain controller can connect to the corporate LDAP server or Database this is not possible from the nodes running the AS instances.
- Using properties files but do not wish to replicate these across an entire estate of AS nodes.
There is a trade off between simplifying the configuration and performance but I believe that should be reviewed on an installation by installation basis so I am proposing that we add an authentication mechanism that can be used on slave DCs to call the master-DC to perform authentication. This will allow the master-DC to act as a proxy for the authentication.
This option should however not be mandatory so it's use can be restricted to where it is considered appropriate.