geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Hogstrom (JIRA)" <...@geronimo.apache.org>
Subject [jira] Updated: (GERONIMO-1085) Authentication between an OpenEJB client and the OpenEJB EjbDaemon needs to be implemented
Date Sat, 10 Dec 2005 00:34:09 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-1085?page=all ]

Matt Hogstrom updated GERONIMO-1085:
------------------------------------

           type: Improvement  (was: Bug)
    Fix Version: 1.1
                     (was: 1.0)

Moving to 1.1 as an improvement.

> Authentication between an OpenEJB client and the OpenEJB EjbDaemon needs to be implemented
> ------------------------------------------------------------------------------------------
>
>          Key: GERONIMO-1085
>          URL: http://issues.apache.org/jira/browse/GERONIMO-1085
>      Project: Geronimo
>         Type: Improvement
>   Components: OpenEJB
>     Versions: 1.0-M5, 1.0-M4
>     Reporter: John Sisson
>      Fix For: 1.1

>
> There seems to be a number of related issues in this area:
> 1. AuthRequestHandler.processRequest(..) method does not implement authentication using
credentials sent by client
> 2. A new TCP connection is opened and closed for the creation of the initial context
and each lookup on the context.  It seems that the context should maintain a connection, where
the connection can have an inactivity timeout configured, that can be used by subsequent lookups??
 If this was done, the protocol version information would only have to be exchanged once.
> 3. Currently the authentication request is sent when the initial context is created,
but AFAIK, the subsequent JNDI requests (each over a new connection) are not authenticated
and therefore someone could easily write their own malicious client that just sends the JNDI
requests, bypassing the authentication step.  If we are going to be using a number of connections,
then some authentication state needs to be passed on requests after the authenticate request.
> 4. This issue probably should be moved to a separate JIRA... AuthenticationRequest message
containing the principal (e.g. system) and credentials (e.g. manager) is in the clear (not
encrypted).  
> Notes...
> When an end user application using the OpenEJB client creates an InitialContext, the
following takes place:
> * OpenEJB client starts a connection to the OpenEJB daemon (server)
> * OpenEJB client sends a version string (ProtocolMetaData) to the server for the OpenEJB
Enterprise Javabean Protocol (OEJP), e.g. OEJP/2.0
> * The server responds with its ProtocolMetaData string
> * The OpenEJB client sends AUTH_REQUEST (value 02) as a one byte message to the server
> * The OpenEJB client sends an AuthenticationRequest message  containing the principal
(e.g. system) and credentials (e.g. manager)
> * The EjbDaemon (server) reads the request type so it can pass the request to the appropriate
handler class.
> * The EjbDaemon (server) passes the AUTH_REQUEST message to the AuthRequestHandler.processRequest(..)
method that does contains a TODO to implement some real authentication.  Currently it does
not use the credentials and always returns a response code of AUTH_GRANTED
> * The OpenEJB client receives the AUTH_GRANTED response and closes the connection.
> * The end user application is returned an InitialContext
> When an end user application using the OpenEJB client performs a lookup on the context
they just created, the following takes place:
> * OpenEJB client starts a connection again to the OpenEJB daemon (server)
> * OpenEJB client sends a version string again (ProtocolMetaData) to the server for the
OpenEJB Enterprise Javabean Protocol (OEJP), e.g. OEJP/2.0
> * The server responds again with its ProtocolMetaData string
> * The OpenEJB client sends JNDI_REQUEST (value 01) as a one byte message to the server
> * The OpenEJB client sends a JNDIRequest message containing the requestMethod JNDI_LOOKUP
(value 27), a clientModuleId of null and a request string of /EchoTest
> * The EjbDaemon (server) reads the request type so it can pass the request to the appropriate
handler class.
> * The EjbDaemon (server) passes the JNDIRequest message to the JndiRequestHandler.processRequest(..)
method 
> * If the JndiRequestHandler finds the name it returns a JNDI_EJBHOME response code and
writes a serialized EJBMetaDataImpl object to the client (containing home class, remoteclass,
keyclass, ejbHomeProxy, type, deploymentID, deploymentCode)
> * The OpenEJB client's JNDIResponse class deserializes the EJBMetaDataImpl object.
> * The end user application is returned the Object
> Example code used for above requests: (see GERONIMO-1062 attachments for full source
of example app)
>     Properties props = new Properties();
>     props.put("java.naming.factory.initial",
>                 "org.openejb.client.RemoteInitialContextFactory");
>     props.put("java.naming.provider.url", "127.0.0.1:4201");
>     props.put("java.naming.security.principal", "system");
>     props.put("java.naming.security.credentials", "manager");
>     Context ctx = new InitialContext(props); 
>     EchoTestHome ejbHome = (EchoTestHome) ctx.lookup("EchoTest");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message