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+...
https://community.jboss.org/servlet/JiveServlet/downloadImage/19891/Exist...
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+...
https://community.jboss.org/servlet/JiveServlet/downloadImage/19892/Exist...
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+...
https://community.jboss.org/servlet/JiveServlet/downloadImage/19893/Previ...
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+...
https://community.jboss.org/servlet/JiveServlet/downloadImage/19894/Previ...
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/Reauthent...
https://community.jboss.org/servlet/JiveServlet/downloadImage/19895/Reaut...
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&a...]