geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From viola lu <>
Subject Re: Question about Security (Credentials) for database connections(connector)
Date Thu, 11 Aug 2011 09:12:24 GMT
Thanks for your input, i will setup an environment to try first.

On Thu, Aug 11, 2011 at 12:05 AM, David Jencks <>wrote:

> Hi Viola,
> I haven't looked at the details in some time.... check anything I might say
> :-).
> On Aug 10, 2011, at 1:47 AM, viola lu wrote:
> Hi, David:
>   1. If container-managed security is implemented, but how to configure it
> for connector?
> I think at one time there was a unit test that had most of the setup in it.
>   2. Now one customer doesn't want to use same db id but different user
> credentials as below, container-managed security can meet this requirement?
>   "Configure a geronimo Instance running in a windows domain with a db2
> datasource, which connects to the iseries using kerberos.
> In order for this to work with any kind of success, we believe we need to
> configure some kind of connection reauthentication.  If geronimo
> does not invoke connection reauthentication, then any connection pool would
> quickly fill up with connections per individual user.
> Ultimately this would negate any benefit of connection pooling. connection
> reauthentication would allow geronimo to assert the
> current callers identity onto the running connection."
> "Our ultimate goal here is to configure End To End single signon from a
> windows browser, through geronimo, and onto the System i.  Whereby
> the clients identity is preserved throughout."
>  3. Based on the above requirement, *datasource connects to iseries using
> kerberos*, currently tranql-ra/ra.xml, set authentication-mechanism as
> basicpassword, if datasource uses kerberos, should we change authentication
> mechanism to *Kerbv5 as below? *
> <authentication-mechanism>
>                 <description>Uses JDBC user/password authentication based
> on properties supplied to connect</description>
> <authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
> <credential-interface></credential-interface>
>             </authentication-mechanism>
> And <reauthentication-support>false</reauthentication-support> should
> change to true support connection reauthentication. And in our
> geronimo-connector should handle this connection reauthentication ? Also
> database pool in console should support these configuration?
> 4.From
> it provides a datastorehelper interface to end-users for db connection
> reauthentication function, for example, db2
> end-user can implement its doConnectionPerTransation method by using db2
> api: resetDB2Connection, same way can be used in geronimo? I am not sure
> connection-reauthentication is necessary or good way if different users
> filled up connection pool.
> There are 2 additional issues here:
> 1. using kerberos rather than user-password.  I think there's some support
> in the j2ca spec for this (GSSUP? GSS???), but not in the jdbc spec or
> tranql.  I think this would require understanding how this is supposed to
> work with a test system and modifying the tranql wrapper so it could deal
> with these credentials and send them to the db2 driver in the
> (non-jdbc-spec) expected way.
> 2. implementing reauthentication.  Again, the j2ca spec talks about this
> but the jdbc spec does not.  So we'd need to find out how db2 implements
> this and wrap that in an adapter between the j2ca reauthentication and the
> db2 driver, inside the tranql wrapper.
> In addition, we may need more/better kerberos login modules in geronimo,
> and possibly a "mapping" login module to get from the original identity to
> the db identity.
> As the customer says, without reauthentication the connections will pile up
> and the pool will get full of unused connections.
> I've thought about implementing this in the past, but without a working
> system to test and an actual user it seemed impractical.  With a system to
> try it out on it might not be too hard.
> I am not sure we should expend the effort to make this configurable in the
> admin console until we have more than one user who wants to use this feature
> :-)
> thanks
> david jencks
> On Wed, Aug 10, 2011 at 1:15 PM, David Jencks <>wrote:
>> 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 from.
>> 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 :-\
>> thanks
>> 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:
>>    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
> --
> viola
> Apache Geronimo


Apache Geronimo

View raw message