Thanks for your input, i will setup an environment to try first. On Thu, Aug 11, 2011 at 12:05 AM, David Jencks <[email protected]>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 <[email protected]>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
