geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Question about Security (Credentials) for database connections(connector)
Date Wed, 10 Aug 2011 05:15:52 GMT
Hi Viola,

The docs are correct and we implement everything it says we do.  However except in unusual
circumstances it doesn't make a lot of sense to use container managed security.  I think perhaps
you are getting confused by the name.  In any of these scenarios, the ManagedConnectionFactory
has to be consulted about the credentials, and presumably it will consult the actual resource
manager (e.g. database server).  The "container managed" is about where the credentials come

Usually with a database you want all the connections as the same user.  In this case you might
as well configure the user and password as mcf properties and be done with it.  This is sort
of "unmanaged non-application" security.

Application managed security means (for jdbc) that the application will call ds.getConnection(user,pw).

Container managed security means that the container will take the users identity (and possibly
credentials) and somehow derive the credentials needed by the mcf/database from it.  For instance
you could use the users name and pw to log into the db, or you could use some role they are
in to derive the user name/pw (e.g. each role gets a different database user), or you could
come up with some other scheme.  However, usually people don't want to do this, they just
want everyone to have the same db id, so it doesn't make a lot of sense to set up a mapping
that maps everyone to the same credentials.

Is this clearer?

I implemented the inbound security stuff so we should consider updating the docs for 3.0.
 Perhaps the excerpt below can be made clearer so people other than me can understand it :-\

david jencks

On Aug 9, 2011, at 9:47 PM, viola lu wrote:

> Hi, Dev:
>  From geronimo 2.1 doc:
> 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:
> 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.
> 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.
> 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

View raw message