[jboss-dev-forums] [JBoss AS 7 Development] - Connection Re-Authentication and Security Propagation [DRAFT / Work In Progress]

[Darran Lofthouse]

Darran Lofthouse [https://community.jboss.org/people/dlofthouse] modified the document:

"Connection Re-Authentication and Security Propagation [DRAFT / Work In Progress]"

To view the document, visit: https://community.jboss.org/docs/DOC-47864

--------------------------------------------------------------
h2. Introduction
The purpose of this article is to outline the problems that we are attempting to solve and the solution currently being considered, this work is being tracked under the following Jira issue: -

 https://issues.jboss.org/browse/AS7-5901 https://issues.jboss.org/browse/AS7-5901

Currently for remote EJB invocations (Actually all invocations to the server but in this case EJB invocations are the priority) a Remoting connection is established by the client, early in establishing this connection the remote client performs authentication using SASL - once authenticated the authentication is valid for the life of the connection.  As EJB invocations are received the identity on this connection is the identity used for the EJB call.

The following diagram illustrates the exising calls for remote EJB clients: -

 https://community.jboss.org/servlet/JiveServlet/showImage/19891/Existing+Calls+%281%29.png  https://community.jboss.org/servlet/JiveServlet/downloadImage/19891/Existing+Calls+%281%29.png 
The established connection here is a Remoting connection, the connection itself is independent of any service being accessed and on establishing the connection authentication is performed using the associated realm.  Subsequently when the client connects to the EJB Container and sends a request to a deployed EJB the identity used for the EJB call is the identity taken from the underlying connection.  As the authentication takes place as the connection is established the only way for the clients to send in requests as an alternative user is to establish a new connection as the new user.

A second scenario is where the call is also passed from one server to another: -

 https://community.jboss.org/servlet/JiveServlet/showImage/19892/Existing+Calls+C--S--S.png  https://community.jboss.org/servlet/JiveServlet/downloadImage/19892/Existing+Calls+C--S--S.png 
In this second scenario there is now a connection from the first server to the second server, this connection also requires authentication and the call to the EJB on the second server runs as the identity of this second connection.

These two diagrams illustrate the problems to be solved: -
* For a client to run as different identities different connections are required for each identity.
* For a server to server call the identity on the second server is the identity of the connection and not the original caller.

h3. Remoting Authentication
Before reviewing alternative solutions it is worth describing the decisions relating to the authentication of the actual connection as at the very minimum it is desirable that we do not undermine this with a solution that allows interception of the exchanges in such a way that either passwords are revealed or items are revealed that could be basis for a plain text attack.

When a client attempts to connect to the Remoting connection a challenge is sent back to the client containing a list of supported authentication SASL mechanisms that the client can select from to attempt to authenticate, the client selects on and attempts the authentication.  If authentication succeeds then the client can then request to connect to the service it wished to use, if not the client is re-challenged with the list of mechanisms and this is repeated until the client either successfully authenticates or the list is exhausted.

The SASL mechanisms that are offered are selected based on the capabilities of the backing user store - as an example if we have a user store what we can query to obtain the users password or a pre-prepared hash of their password we offer the client the Digest-MD5 mechanism - however if we can only verify a supplied password but not generate the hashes required for Digest based authenitcation then PLAIN is offered as a mechanism.

A second SASL mechanism that we also support is the External mechanism, this mechanism is a special mechanism in that it automatically authenticates as an identity associated with the surrounding connection - currently we use this for ClientCert style authentication where after a TLS connection is established authentication will then proceed based on the clients certificate.

Another mechanism that we are currently adding support for is GSSAPI, this is a mechanism that authenticates a user by the use of authentication tokens with no exchange of passwords between the points involved in the authentication process.

The ability to authenticate using these different approaches where we can reduce the places where either passwords or replayable tokens are visible is the key reason why we do not want to introduce those kind of vulnerabilities in the solution to the two problems being described here.

h2. Proposed Solutions
This section describes the solutions currently considered and where appropriate describes why those solutions are currently discounted, at this point this is intended to be for discussion rather than a final definitive decision.

h3. Solution from Previous Releases
In previous AS releases unless a custom RMI socket was used the connections to the application server were not authenticated, instead the username and credential would be passed along with the EJB invocation and intercepted before the call reached the EJB - the supplied information would then be used to authenticate the remote user before allowing the call to proceed.

 https://community.jboss.org/servlet/JiveServlet/showImage/19893/Previous+AS+Calls.png  https://community.jboss.org/servlet/JiveServlet/downloadImage/19893/Previous+AS+Calls.png 
Where a client wanted to run as multiple identities that was fine as for each invocation a different username and password could be set for the call.

This approach also potentially allowed for the security context to be passed onto subsequent servers as the contents from this message invocation are available.

 https://community.jboss.org/servlet/JiveServlet/showImage/19894/Previous+AS+Calls+C--S--S.png  https://community.jboss.org/servlet/JiveServlet/downloadImage/19894/Previous+AS+Calls+C--S--S.png 
Whilst this approach does solve the problem of being able to switch identities and propagate identities it suffers from the problem that the users password is sent in the clear so should we undertake a similar solution for AS7 it would undermine the protection available from the currently available SASL mechanisms, in addition to this it is assuming that a username / password based authentication is always the approach we will want to take even though there are now alternative mechanisms in common use.

h3. Reauthenticate The Connection

As the calls are executed as the identity of the connection one approach could be to allow the client side to initiate a re-authentication of the connection so that a different identity can be used.

 https://community.jboss.org/servlet/JiveServlet/showImage/19895/Reauthenticate+Whole+Connection.png  https://community.jboss.org/servlet/JiveServlet/downloadImage/19895/Reauthenticate+Whole+Connection.png 
Whilst this would allow a client to switch identities and it could potentially be implemented using the SASL mechanisms the biggest issue here is if the client is multi-threaded and wants to run as multiple identities concurrently.  At best the client would need to maintain a pool of connections one for each identity in use and if all identities could be used at once then it is no better than the current situation.

The multi threaded client issue is also made worse in the server to server case where sharing a single connection would be a major benefit in reducing the resources used.

For the server to server case there is also the issue regarding how is the users identity propagated to the second server, for this possible solution the multi-threaded client problem appears to be sufficiently blocking so will cover that in subsequent solutions.
--------------------------------------------------------------

Comment by going to Community
[https://community.jboss.org/docs/DOC-47864]

Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&containerType=14&container=2225]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20121116/5e8ea26c/attachment.html