I'm working with the CallerIdentityLoginModule to passthrough the caller credentials to the database and having some difficulty when the database is hit on another thread.

The call sequence goes as follows:

• Request (authenticated) comes in to an MDB which creates a job and places it in a JMS queue.
• This job is then picked up and executed by another thread and the executing thread is not authenticated.
• In the event it requires a DB connection it no longer has a current caller identity to authenticate with and it fails to complete when it's forced to use the default username/password.

If everything is handled on a single thread there is no issue. The CallerIdentityLoginModule performs as advertised and all is well. But we're running scheduled jobs through Quartz and these may fire at any time and must run as a specific user; so I need to get the above scenario functioning somehow.

I'm at a point now where I'm thinking I'll need to intercept the user's credentials, encrypt and store them in Derby (or somewhere), and then add the key to the credentials as part of the job. Then, when the job fires it can login to the application as part of the process and the underlying database connection will begin to work.

Is that the best way to accomplish this? Other ideas? opinions?

We'd rather not store user credentials in the application of course, but I'm not seeing another way to do what I'm trying to do at this point.

Thanks,

Travis