Thanks, your response was very helpful and confirms what I have been seeing.
In our case our SAM is an implementation of SSO based on CA SiteMinder. In our app a Apache server sits in front of GF and will pass a HTTP Header variable to the app indicating the user's identity that was validated by SiteMinder. The Authentication is done via the SSO layer and the authorization logic is up to our app.
So, basically our SAM takes the user ID from the HTTP header and checks against a local DB to see if the user exists and is allowed to access the app according to our business rules. This validation requires some database lookups to check the business rules. Since we never see the password, we are not using a realm-based approach. We needed a way to read data from the HTTP request
We have this SSO split because the 2-3 million user IDs/passwords are managed by the SSO layer which is a group external to us, but the authorization logic is up to us. In short authenticate globally, authorize locally.
So, we need a high performance way of accessing our DB and since user permissions tend to be reasonably stable over a user's session we think it would be useful to cache user/group lookups in a LRU cache that has a timed expiration.
Starting the SAM on each request tends to complicate matters because we need to have a reasonable way of managing a pool of JDBC connections and our cache. We have built this type of provider using Weblogic's security APIs (Identity Assertor) which was much more predictable in terms of life cycle.
I'm thinking that the best approach might be to use some thread-safe singletons which are shared by the SAMs as they come into being.
The desire to use the JDBC pools in the server vs maintaining our own internal connection pool is to avoid having to duplicate JDBC connection configuration information. In Weblogic we could not reuse JDBC pools that were defined as part of the Weblogic domain because we would get a recursive endless loop because of the design of the security framework. I was hoping that on GF we could maintain our DB connection info in just one place. So the SAM and the applications would share the same pool.\\
To add to the fun we're also mixing in some JRuby based apps.
[Message sent by forum member 'davebolt' (davebolt)]
http://forums.java.net/jive/thread.jspa?messageID=266358