Darran Lofthouse [
http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Authentication Mechanisms"
To view the document, visit:
http://community.jboss.org/docs/DOC-16574
--------------------------------------------------------------
h1. Authentication Mechanisms
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: -
h3.
Property File
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.
h3.
Database Login
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.
h3. LDAP Login
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.
h3. 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.
h2.
Implementation
The management APIs and domain controller can be running outside the scope of a running
server however we do still have msc available for services. A lot of the required
functionality is already made available by PicketBox so the implementation would be along
the lines of: -
* Define the configuration for the management API security and where possible re-use the
XML types already defined for the security integration.
* Implement a custom parser for the management API security parsing but where possible
review where some re-use of the existing security parsers can be used - especially for the
re-used XML types.
* Either: -* Ensure the security integration operations can work both within a running
server and within a domain controller process without the server.
* Modify the security integration operations so they have a common abstract base with
extensions specific to either domain mode or server mode.
* Inbound calls will then be intercepted at a suitable point for the integrated security
subsystem to be called to perform the actual authentication.
At this stage the only required authorization check is that we have an authenticated user,
more advanced authorization will be defined in another document.
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-16574]
Create a new document in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]