geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From viola lu <viola...@gmail.com>
Subject Question about Security (Credentials) for database connections(connector)
Date Wed, 10 Aug 2011 04:47:20 GMT
Hi, Dev:

 From geronimo 2.1 doc:
https://cwiki.apache.org/GMOxDOC21/connectors-and-transaction-management-jdbc-jms-j2ca-datasource-connection-pool-eis.html
Security (Credentials)

In the J2CA 1.5 spec security considerations are confined to providing the
credentials for outbound connections. There is no provision for credential
inflow for inbound messaging. This hole is being addressed in the next spec
revision.
There are three possible sources for credentials for outbound connections:

   1. ManagedConnectionFactory configuration. Most ManagedConnectionFactory
   implementations include user and password config-properties. In the absence
   of other credentials these are used to authenticate to the resource manager.
   The values of these properties are generally difficult to conceal securely
   as they are in some geronimo configuration files on disk and need to be
   accessible to geronimo in order to create connections. However, this is by
   far the most frequently used option. This will result in all work in your
   e.g. database being done by the same user, which basically represents the
   identity of the geronimo server.
   2. Application managed security. Many connection factories such as
   DataSource provide a way to request connections with a particular security
   context, such as dataSource.getConnection(user, password). This requires
   your app to have detailed knowledge of the credentials needed which is
   rarely appropriate.
   3. *Container managed security.* With this scheme you deploy a
   LoginModule specific to the connector you are using that installs suitable
   credentials into the Subject on login. When a connection is requested these
   credentials are extracted from the Subject and used in obtaining the
   connection. A wide variety of schemes can be used here including


   - Fixed credentials. Every subject gets the same credentials. This has
   the same effect as the default credentials scheme except that the
   credentials may be stored in an external more secure location more easily.
   - *User credentials. The credentials are the user and password of the
   user themselves. In this case the work will be done in the resource manager
   (database) as the user themselves. Unless the connector supports
   reauthentication (changing the user on an existing connection) this will
   prevent effective connection pooling.*
   - Mapped credentials. The credentials for the resource manager are
   determined from the user identity. For instance the resource manager user
   could depend on the user being a member of a particular enterprise role or
   group. In this case without reauthentication support connection pooling
   should be set up so each resource manager user gets a separate pool.


Seems there is Container Managed Security function in security part of
connector, i  checked the code, currently, we all use ManagedConnectionFactory
to do security authentication. not container-managed security. So the
feature of user credetials of container managed security. And if we plan to
implement this function, any suggestion of tech details of
geronimo-connector module change?

Appreciate your help!
-- 
viola

Apache Geronimo

Mime
View raw message