RE: Connection Pooling with the .NET Provider on IIS

Sigh. Souka ... Again, I have to say this... you need to think about what you are saying. With respect to MC, you're jumping in to how a web app authenticates and how it tracks a user via its session information. (Note: Depending on how complex you want to get, you can track a lot of information within a session container. Its all up to the developer.) Now if you want, you can use connection pooling. If you want, you could also associate a database connection to a session and store the connection information in your session container. (Again, how you do this will vary on the language and framework you are using.) So when you authenticate against the app server, you can also authenticate and get a database connection at the same time. If you want to implement 'single sign on' you can do this via LDAP or other methods. (An example is that in Spring, you can set it up to authenticate against a security table within a database...) So if your end goal is to have a 'single sign on' so you can trace the actions via a session and user, you can do this. However again, if you pass along the session container and pull out the user id, and a time stamp, you can accomplish what you want without having to change the underlying database. So two solutions that don't require you to modify how your database manages connections and user sessions. With respect to Fernado... Just because someone does something brain dead and not worthwhile , doesn't mean that you have to do it. Clearly you are starting to think about the problem. >From a business perspective, this 'feature' does not offer compelling value in this context. If you have to write the paychecks for your employees, you don't want to waste time, effort and more importantly money on an effort that has very little ROI. A real life example of this... Oracle's temp tables. (IBM's DB2 for that matter too). Oracle realizes that their implementation of temp tables is pretty lame and brain dead. However, no one is really complaining about it and its not important enough for a customer to toss an Oracle implementation in to the trash and switch to a different database. So there is little incentive for Oracle to waste money, time and effort on improving this aspect of their product. (There are more important things they need to focus on... ;-P ) In short, if you want to use connection pooling, then you need to store some information from the session to track the identity. If you don't want to do this then do not use connection pooling and establish a database connection on a per user/session basis. Its that simple. Really. MC needs to quit his belly aching. Now if you're talking about doing a single sign on in terms of IBM's concept of a Master Data Database Manager, then you may want to reconsider how you handle connections and user session information. That would be a complete revamp of a major portion of your database. (Actually there is a way to do this that would be manageable ...) But hey! What do I know? I'm not working for IBM so I'm not going to get paid to lay out design strategies for them. I soon expect a certain clown to poke his head in and make some snide comment calling moi and Chicagoans cunts. Of course I'm asserting rule #1 first. ;-) -G Date: Wed, 17 Jun 2009 13:59:49 +0100 Subject: Re: Connection Pooling with the .NET Provider on IIS From: domusonline@gmail.com To: informix-list@iiug.org On Wed, Jun 17, 2009 at 1:09 PM, mc <mc@community.nospam> wrote: grendal wrote: > On Jun 15, 6:16 pm, Fernando Nunes <domusonl...@gmail.com> wrote: >> Ian Michael Gumby wrote: >>> With respect to Fernando's earlier post, you have to think about the >>> security risks if you can change your connection details within the >>> pool. Not a good idea. >> I'd like a more elaborate response if you can. As I said, it's doable by other >> RDBMS. If you can authenticate securely you can of course change credentials in >> a secure manner... You may not want to do that for simplicity and performance >> but I can't think of any additional security issues... It's not like you simply >> say "authenticate me as john_doe/password" and then simply "now I'm informix, >> thank you!" >> > > Again, which *other* databases? > Unlike DB2 and IDS, do the other databases authenticate against the > OS? From what I've seen, both Oracle and MS Sql Server Authenticate the user based on well established Kerberos/NTLM Authentication methods. Neither of the above would ever allow a connection to be re-used by any other user than the originator. Yes it will... You can define that a user account has special rights to "impersonate" another given certain conditions. That's how it can be done in a light way (no need to go through the authentication process for each request). As I wrote, both Oracle and DB2 allow that in some form. I care little if it is actually changing the authentication on the fly or if the connection pool is authentication aware and blocks the connection re-use. the point is that when developing a secure system you would never want your credentials to be reused and therefore written into DB logs by anyone other than yourself. > >> Although usually J2EE applications just use a connection pool with a single >> user, some customers would like to be able to do end-to-end identity >> propagation. Specially if you're modernizing your application by introducing >> web services for example and you have old logging mechanisms on the database >> side based on the user ID. This is s situation customers may face if they try >> to use the new web services capabilities of newer versions of 4GL. >> > end to end identity propogation? The concept of end-to-end propagation of identity is fundamental in developing a secure and robust system. Most J2EE applications don't do it... The DB actions are sent by the application, and the security is built on the application. Most of them use the same user to connect to the DB. This user can be specifically created for that purpose, and should only have the need rights. I have full traceability from when the user first "Hits" the web page, into web service calls on remote systems which connect into databases. Every system's audit logs reference the user that completed the action not some system account that makes tracing individuals actions very difficult. You can achieve that using the DB2 trusted contexts for example. Informix also allows for user impersonation, but currently it's very limited and you must be DBA (SET SESSION AUTHORIZATION). This feature is not very useful in the context we're discussing > You really need to think about what you're saying. You really need to start thinking about security! I believe DB2 and Oracle engineers have thought about that, but as with any other feature it's up to the users to decided. If you don't feel comfortable with it... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... _________________________________________________________________ Insert movie times and more without leaving Hotmail®.@@NL@