You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by viola lu <vi...@gmail.com> on 2011/08/10 06:47:20 UTC
Question about Security (Credentials) for database connections(connector)
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
Re: Question about Security (Credentials) for database connections(connector)
Posted by viola lu <vi...@gmail.com>.
Thanks for your input, i will setup an environment to try first.
On Thu, Aug 11, 2011 at 12:05 AM, David Jencks <da...@yahoo.com>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>javax.resource.spi.security.PasswordCredential</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
> http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html,
> 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 <da...@yahoo.com>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:
>> 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
>>
>>
>>
>
>
> --
> viola
>
> Apache Geronimo
>
>
>
--
viola
Apache Geronimo
Re: Question about Security (Credentials) for database connections(connector)
Posted by David Jencks <da...@yahoo.com>.
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>javax.resource.spi.security.PasswordCredential</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 http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html, 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 <da...@yahoo.com> 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: 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:
>>
>> 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
>>
>
>
>
>
> --
> viola
>
> Apache Geronimo
>
Re: Question about Security (Credentials) for database connections(connector)
Posted by viola lu <vi...@gmail.com>.
Hi, David:
1. If container-managed security is implemented, but how to configure it
for connector?
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>javax.resource.spi.security.PasswordCredential</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
http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html,
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.
On Wed, Aug 10, 2011 at 1:15 PM, David Jencks <da...@yahoo.com>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:
> 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
>
>
>
--
viola
Apache Geronimo
Re: Question about Security (Credentials) for database connections(connector)
Posted by David Jencks <da...@yahoo.com>.
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: 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:
>
> 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
>