Re: Informix Connection without Unix ID

>From: cphdcbl@ted.cs.depaul.edu (Brian Li) >Date: 15 Aug 1996 13:36:04 GMT >X-Informix-List-Id: <news.27150> > >In article <918347775.271290494@cornut.fr>, >Frederic Bouquet <fbouquet@cornut.fr> wrote: >>dave, >>you wrote : >>>I would like to be able to connect a lot of windows clients (Win95, >>>Win3.1) to an unix box without an account (user and password) defined >>>for each one in the unix side. I wouldn't like to have a unique user >>>for all my clients. >>> >>>I know that Oracle/Sybase maintain a list of user ids internal to the >>>database. Is this possible in Informix? >> >>Some of our customers use exactly the configuration you describe here. Only >>one Unix account to connect to one or several Informix database. So my answer >>is Yes it's possible with Informix . (We do the same with Oracle) > >I think Dave's question is: does Informix provide its own internal security >scheme other than using unix's. There are two parts to a security scheme: * Controlling the actions of authorised users. * Identification (verification, authentication) of authorised individuals. Informix uses a wholly non-Unix scheme for controlling the authorised actions because the actions it controls are database actions rather than Unix actions. The primary vehicle for these controls are GRANT and REVOKE, augmented by views, triggers, stored procedures and roles. Informix identifies people by Unix login ID and using no other scheme (no auxilliary authentication mechanisms). It assumes that (a) the Unix security has not been compromised, and (b) that an individual doesn't need multiple identities within the database. There is no concept of logging into the database as there is in Sybase, and probably Oracle -- you login to Unix and then access Informix without further verification/authentication. This has the great advantage of simplicity, especially for non-interactive programs (no fiddling around working out how to get the password information into the non-interactive program). It has the disadvantage that if UserA is entitled to delete sales orders, for sake of argument, using an application ProgramA, then UserA can also delete sales orders using DB-Access. This is a serious issue -- I'm not wholly convinced that Sybase or Oracle have a solution to that, either. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>