[JBoss AS7 Development] - Management API Security Possible Configuration Samples
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Possible Configuration Samples"
To view the document, visit: http://community.jboss.org/docs/DOC-16576
--------------------------------------------------------------
h1. Management API Security Possible Configuration Samples
For domain management security we are looking to achieve the following: -
* Simplified configuration without need to understand inner workings of JAAS
* Configuration and implementation compatible with both SASL negotiated connections and the simpler single challenge / response we are used to.
* Option to still make use of JAAS if desired.
h2. Sample Configuration
The following sample configuration shows the extent of the configuration to be made possible in the context of the standalone.xml descriptor.
<server xmlns="urn:jboss:domain:1.0"
...
<management>
<security-realms>
<security-realm name="Management Realm">
<server-identities>
<certificate></certificate>
<kerberos></kerberos>
</server-identities>
<authentication useDomainController="true|false">
<user-properties location="" />
<user-database connection="UsersDatabase" query="select password from Users where username=%1" />
<user-ldap connection="UsersDirectory">
<simple userDNPrefix="..." userDNSuffix="... />
<advanced userSearch="..." />
</user-ldap>
<jaas>
<login-module ></login-module>
</jaas
</authentication>
<authorization useDomainController="true|false">
<role-properties location="" />
<role-database connection="UsersDatabase" query="select RoleName from Rolers where User=%1" />
<role-ldap connection="UsersDirectory">
<simple userDNPrefix="..." userDNSuffix="... />
<advanced userSearch="..." />
</role-ldap>
<jaas>
<login-module ></login-module>
</jaas
</authorization>
</security-realm>
</security-realms>
<connections>
<database name="UsersDatabase"><connection-properties/></database>
<ldap name="UsersDirectory"><connection-properties/></ldap>
</connections>
<authorization-control></authorization-control>
</management>
<management-apis>
<native-api interface="public" port="9991" realm="Management Realm"/>
<http-api interface="public" port="9992" realm="Management Realm" />
</management-apis>
...
</server>
h2. Description
If security is enabled the management element will hold one or more security realms, the security realm will contain 3 sub sections: -
h3. server-identities
There are a couple of places where a server requires an identity of it's own a couple of examples are the server certificate used for SSL or a Kerberos identity when used with GSSAPI.
The identities will not be named as they are nested in the security realm, instead there will be some form of ServerIdentityManager with methods such as getX509Idenity or getKerberosIdentity.
h3. authentication
The SASL mechanisms being used require a number of callbacks to be made available whilst the connection is negotiated, for consistency the HTTP API will follow the same approach although SASL will not be directly used.
The authentication element will list one or more 'components' for accessing user stores. These components will advertise their capabilities so that their suitability with the currently selected SASL / HPP authentication mechanism can be verified.
e.g. The User-Database component is expected to be able to return a password so it can be used with both Plan and Digest_MD5, the User-LDAP component will only be able to verify a password it is provided so will only work with Plain.
To allow for legacy modules a JAAS component will also be provided, this allow a list of login modules to be specified and is intended for Plain or External for the scenarios previously covered up to AS6.
It is not intended for new modules to be supported for other negotiated mechanisms.
In the future if we choose to publish an SPI for these components we may allow for custom components to be defined.
The useDomainController attribute is to specify if the requests should be delegated to the domain controller.
h3. authorization
The purpose of this element is to define how additional information relating to the customers identity will be loaded so that it can be used later for authorization checks - generally this would be a list of roles but other information could be added.
As for authentication this will define a number of components to access user repositories, these will be queried to load the identity information.
A JAAS option will also be available to use existing login modules for role queries. (We will ensure these login modules are only loading the roles and not attempting authentication.)
The useDomainController attribute is to specify if the requests should be delegated to the domain controller.
h3. connections
At a higher level a connections element will be defined, this will be used to configure all connections to external systems during the security processing - as authentication and authorization has been split this will allow for connection information to be shared with both parts.
h3. management-apis
Within the management APIs itwill be possible to specify the security-realm that should be used for that connection.
It will be possible once the security-realm has been identified to query the server-identities and the authentication components to identify what capabilities we have. We could decide to support the list of available mechanisms or define additional configuration on the API definition to specify the supported mechanisms.
h3. authorization-control
This is not being defined at this stage but this is where the authorization requirements will be defined.
h2. Domain Management
For managing a domain it will be expected that the <management> element will be defined within the domain.xml and the <management-apis> element will be defined in the host.xml.
It will also be possible to add a <management> element within the host.xml - this will allow any parts of the <management> element from the master domain controller to be overriden, possible needs for this are: -
* Host specific server identities.
* Host specific connection definitions e.g. Using a different database or different connection to same database.
* Different authentication requirements for host direct connections.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16576]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
[JBoss AS7 Development] - Management API Security Authentication Mechanisms
by Darran Lofthouse
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.
--------------------------------------------------------------
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&co...]
13 years, 10 months
[IronJacamar Development] - Reauthentication
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] modified the document:
"Reauthentication"
To view the document, visit: http://community.jboss.org/docs/DOC-16434
--------------------------------------------------------------
h2. Description
A resource adapter can re-authenticate a physical connection (that is, one that already exists in the connection pool under a different security context) to the underlying EIS. A resource adapter performs reauthentication when an application server calls the getConnection method with a security context, passed as a Subject instance, different from the context previously associated with the physical connection.
h2. Requirements
* Reauthentication support: The resource adapter provider must specify whether a resource adapter supports reauthentication of an existing physical connection.
* The matchManagedConnections method in ManagedConnectionFactory may return a matched ManagedConnection instance with the assumption that the ManagedConnection.getConnection method will later switch the security context through reauthentication.
* If reauthentication is successful, the resource adapter has changed the security context of the underlying ManagedConnection instance to that associated with the passed Subject instance.
Detailed description of the reauthentication process is described in section 9.1.9.
h2. Design
There are a couple of design choices
1. An implementation that keeps all connections within the same managed connection pool
2. An implementation that separates connections based on their credentials and does a reauthentication if needed
There are pros and cons for each design solution - basically inverted of each other
* Ease to implement
* Proven already
* Number of reauthentications occurring
In the case of 2) we will need a good LRU mechanism across all managed connection pools.
h2. Implementation
The implementation is currently based on design solution 1.
The classes are
* org.jboss.jca.core.connectionmanager.pool.strategy.ReauthKey
* org.jboss.jca.core.connectionmanager.pool.strategy.ReauthPool
The class
* org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer
have been updated to use the PoolStrategy.REAUTH strategy for all resource adapters which have specified that they support reauthentication.
h2. Test suite
h3. Test client
1. Lookup connection factory / connection
2. Invoke connection with credential #1
3. Invoke connection with credential #2
should lead to success
h3. Resource adapter
* Reauthentication enabled
* Expose simple connection interface
* Configuration: Initially <min-pool-size> and <max-pool-size> should be set to 1
* Maybe do two resource adapters* #1 using Subject
* #2 using CRI
h3. Target system
* Allow a configured number of connections (java.net.Socket)* Binary protocol
* Command
* Payload
* Support Subject based security through raw data
* Support CRI based security through raw data
* Support reauthentication on existing connection
* Be able to run in-VM* All communication has to go over the Sockets for clean separation between RA and EIS
h4. Code
The EIS is located under
org.jboss.jca.core.security.reauth.eis
And test cases under
org.jboss.jca.core.security.reauth.eis.unit
h4. Protocol
Each command is identified with a byte followed by the payload for the command.
|| *Command
* || *Input
* || *Output
* ||
| CONNECT | <nothing> | Boolean (True if granted access) (OBJECT) |
| CLOSE | <nothing> | <nothing> |
| ECHO | Serializable (OBJECT) | Serializable (Echo service) (OBJECT) |
| AUTH | UserName (UTF)
Password (UTF) | String (User name) (OBJECT) |
| UNAUTH | <nothing> | Boolean (True if successful) (OBJECT) |
| GETAUTH | <nothing> | String (User name) (OBJECT) |
Option #C and #A described in section 9.1.9 should be tested in that order.
Ideally the entire test suite setup can be included as an example in the user guide.
h2. JDBC
Some databases support reauthentication, so we need to provide a way to enable support in our JDBC resource adapter.
We can also provide plugins for the Open Source databases that supports this.
h2. Links
* http://jcp.org/en/jsr/detail?id=322 Java EE Connector Architecture 1.6
* https://issues.jboss.org/browse/JBJCA-94 JBJCA-94
* http://community.jboss.org/en/picketbox PicketBox user forum
* http://community.jboss.org/en/picketbox/dev PicketBox developer forum
* http://community.jboss.org/docs/DOC-10430 Old JCA pooling mechanims
* http://community.jboss.org/message/230163#230163 User thread
* https://issues.jboss.org/browse/JBAS-1429 JBAS-1429
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16434]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
