RE: Ids and passwords for application users
I think the real issue is who is going to keep the usernames and passwords maintained. Is it you? Do you have that much spare time? Also, it can also be inefficient with everyone's time. Someone gets hired. Their supervisor sends you an email so you can create the userid. But wait, they forgot to tell you which functions the employee needs access to. So you email the supervisor back and wait for a reply. Then you complete the user signup. Then it turns out the supervisor misspelled the employee's name (people are so picky), so you get to remove what you did and repeat it again. Don't even get me started on how they never tell you when someone leaves the organization. And of course, there is the ever-popular I forgot my password requests. My point is that creating and maintaining individual Oracle accounts can be very time-consuming and put you, the DBA, in the middle of a lot of application issues you really wouldn't need to be concerned about otherwise. For some systems you will need to create and maintain individual Oracle accounts. But my experience has been that if the application can maintain the security and populate a table with logins, this saves everyone a lot of time and trouble. Often the application security can be handed off to a non-I.S. person, or even distributed among several people. These people probably understand the user community and the application requirements much better than a DBA does. Sure, on those rare occasions when you need to find a user, it is an additional step, but if the system is running pretty well that doesn't occur that often. As for hiding/maintaining the underlying password(s), normally these will be buried in the application. And it sure is easier to change the password in one location and recompile the application. Anyway, these have been my experiences with the applications I've worked with. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Tuesday, July 30, 2002 7:53 PM To: Multiple recipients of list ORACLE-L -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
I worked with one vendor's application that had a security administrator role. The security administrator (not a DBA) had privileges to create Oracle users and grant necessary permissions. The security administrator functions were all handled through the vendor front end software. The method worked well, didn't cause DBA overload, and used the Oracle security model. Kevin Kennedy First Point Energy Corporation If you take RAC out of Oracle you get OLE! What can this mean? -Original Message- Sent: Wednesday, July 31, 2002 7:28 AM To: Multiple recipients of list ORACLE-L I think the real issue is who is going to keep the usernames and passwords maintained. Is it you? Do you have that much spare time? Also, it can also be inefficient with everyone's time. Someone gets hired. Their supervisor sends you an email so you can create the userid. But wait, they forgot to tell you which functions the employee needs access to. So you email the supervisor back and wait for a reply. Then you complete the user signup. Then it turns out the supervisor misspelled the employee's name (people are so picky), so you get to remove what you did and repeat it again. Don't even get me started on how they never tell you when someone leaves the organization. And of course, there is the ever-popular I forgot my password requests. My point is that creating and maintaining individual Oracle accounts can be very time-consuming and put you, the DBA, in the middle of a lot of application issues you really wouldn't need to be concerned about otherwise. For some systems you will need to create and maintain individual Oracle accounts. But my experience has been that if the application can maintain the security and populate a table with logins, this saves everyone a lot of time and trouble. Often the application security can be handed off to a non-I.S. person, or even distributed among several people. These people probably understand the user community and the application requirements much better than a DBA does. Sure, on those rare occasions when you need to find a user, it is an additional step, but if the system is running pretty well that doesn't occur that often. As for hiding/maintaining the underlying password(s), normally these will be buried in the application. And it sure is easier to change the password in one location and recompile the application. Anyway, these have been my experiences with the applications I've worked with. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Tuesday, July 30, 2002 7:53 PM To: Multiple recipients of list ORACLE-L -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: kkennedy INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
Another suggestion is to create an Application Administrator. Create a user template for them w/ default privs, default tbs, etc. Grant the app admin create/alter user privileges and let them manage the user community. hth, Gene [EMAIL PROTECTED] 07/31/02 12:25PM I worked with one vendor's application that had a security administrator role. The security administrator (not a DBA) had privileges to create Oracle users and grant necessary permissions. The security administrator functions were all handled through the vendor front end software. The method worked well, didn't cause DBA overload, and used the Oracle security model. Kevin Kennedy First Point Energy Corporation If you take RAC out of Oracle you get OLE! What can this mean? -Original Message- Sent: Wednesday, July 31, 2002 7:28 AM To: Multiple recipients of list ORACLE-L I think the real issue is who is going to keep the usernames and passwords maintained. Is it you? Do you have that much spare time? Also, it can also be inefficient with everyone's time. Someone gets hired. Their supervisor sends you an email so you can create the userid. But wait, they forgot to tell you which functions the employee needs access to. So you email the supervisor back and wait for a reply. Then you complete the user signup. Then it turns out the supervisor misspelled the employee's name (people are so picky), so you get to remove what you did and repeat it again. Don't even get me started on how they never tell you when someone leaves the organization. And of course, there is the ever-popular I forgot my password requests. My point is that creating and maintaining individual Oracle accounts can be very time-consuming and put you, the DBA, in the middle of a lot of application issues you really wouldn't need to be concerned about otherwise. For some systems you will need to create and maintain individual Oracle accounts. But my experience has been that if the application can maintain the security and populate a table with logins, this saves everyone a lot of time and trouble. Often the application security can be handed off to a non-I.S. person, or even distributed among several people. These people probably understand the user community and the application requirements much better than a DBA does. Sure, on those rare occasions when you need to find a user, it is an additional step, but if the system is running pretty well that doesn't occur that often. As for hiding/maintaining the underlying password(s), normally these will be buried in the application. And it sure is easier to change the password in one location and recompile the application. Anyway, these have been my experiences with the applications I've worked with. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Tuesday, July 30, 2002 7:53 PM To: Multiple recipients of list ORACLE-L -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: kkennedy INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to
RE: Ids and passwords for application users
I don't think administering usernames should be the DBAs responsibilty. There are better things to do than create/manage hundreds of users. But there are applications (for instance Siebel) which require you to create individual logins for each user. We have handled that by creating a package with creates/drops the users and also grants/revokes roles/privileges and creating a front end to it and letting the application administrator deal with it. Then we had applications which use one login for every user. Security is handled within the application. At least for one of them, we have been able to use triggers on the application base tables to create/drop the users and manage roles. Security is still handled within the application. The idea was not to drastically change the application. Instead of being logged in to the database and then validating the user against the application security tables, each user would first get authenticated by the database and then by the application. The only issue was we had to use database login triggers to switch the schema to the application schema. For web based applications which only use one login there is practically no way to identify a specific user when trying to troubleshoot issues. In this case I would suggest using dbms_application_info to set the username or something in v$session to identify that user. Regards, Denny Quoting DENNIS WILLIAMS [EMAIL PROTECTED]: I think the real issue is who is going to keep the usernames and passwords maintained. Is it you? Do you have that much spare time? Also, it can also be inefficient with everyone's time. Someone gets hired. Their supervisor sends you an email so you can create the userid. But wait, they forgot to tell you which functions the employee needs access to. So you email the supervisor back and wait for a reply. Then you complete the user signup. Then it turns out the supervisor misspelled the employee's name (people are so picky), so you get to remove what you did and repeat it again. Don't even get me started on how they never tell you when someone leaves the organization. And of course, there is the ever-popular I forgot my password requests. My point is that creating and maintaining individual Oracle accounts can be very time-consuming and put you, the DBA, in the middle of a lot of application issues you really wouldn't need to be concerned about otherwise. For some systems you will need to create and maintain individual Oracle accounts. But my experience has been that if the application can maintain the security and populate a table with logins, this saves everyone a lot of time and trouble. Often the application security can be handed off to a non-I.S. person, or even distributed among several people. These people probably understand the user community and the application requirements much better than a DBA does. Sure, on those rare occasions when you need to find a user, it is an additional step, but if the system is running pretty well that doesn't occur that often. As for hiding/maintaining the underlying password(s), normally these will be buried in the application. And it sure is easier to change the password in one location and recompile the application. Anyway, these have been my experiences with the applications I've worked with. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Tuesday, July 30, 2002 7:53 PM To: Multiple recipients of list ORACLE-L -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be
RE: Ids and passwords for application users
The DBA usually does not get to decide how the application is developed in most of the cases. We have to manage what's out there. There are some products which use one login for all users and manage security within the application. If the applications is web enabled, the changes are the DBA will have no way of figuring out the client machine/user when troubleshooting issues. In this case I would suggest using dbms_application_info maybe within a database logon trigger to set the username. Whether it's possible depends on the application. I was merely suggesting a way out, not recommending that it be done this way ;) Regards, Denny Quoting Jacques Kilchoer [EMAIL PROTECTED]: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
Title: RE: Ids and passwords for application users -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] I think the real issue is who is going to keep the usernames and passwords maintained. Is it you? Do you have that much spare time? At my previous employer, the responsibility of maintaining usernames at the OS level (for those that needed OS accounts), the network level (e.g. e-mail) and ALSO the database level was the responsibility of someone in the systems administration group. We wrote a package for them with interfaces to add a username with the appropriate role / password, another function to remove a username, and a third function to change a user's password. If your company is large enough that adding/removing usernames happens frequently, then obviously it should not be the task of the DBA. I realize that some third-party applications are written to depend on a single username in the database. But how can you force those applications to use dbms_application_info to generate some client information unique to each user? For any in-house application I still think that individual usernames are preferrable.
RE: Ids and passwords for application users
Title: RE: Ids and passwords for application users Peter, not clear on if the database is going to be used by developers doing development work or will an application use it and you'll have up to 300 application users? If it's an application, how about making one account that owns all of the DB objects, another generic account on top of that which you grant access to execute packages, select on tables, etc...so that it can access the objects owned by real account but has limited abilities accept through privileges it's been granted. That is, app_owner - owns all DB objects app_user - owns no DB objects, but has restricted access to objects owned by PRODUCTION tech_support - granted select privileges only user1/user1, user2/user2, etc... - id's and passwords stored in a table, password encrypted When a user needs access to the application, they give login/password as user1/user1, but the application uses the APP_USER account, to look in the table that stores the logins to see if the user is valid, and if so, the application loads, if not they're denied access. HTH -Original Message- From: Schauss, Peter [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 4:59 PM To: Multiple recipients of list ORACLE-L Subject: Ids and passwords for application users I am in the process of designing a small database which may have as many as 250 to 300 users. We are reaching a stage where we need to decide how we will control access to this database. As I see it we have two options: 1. Provide a single hidden login for the entire application and control access to the applicaiton itself either by roll your own security or using the operating system (UNIX) controls. 2. Create ids for the users in Oracle and grant them access to the necessary tables using roles. Any opinions or alternate suggestions? thanks, Peter Schauss -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Schauss, Peter INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Regards, Denny Quoting Jacques Kilchoer [EMAIL PROTECTED]: I always preferred the option of having a userid for each person, because it makes it easier to match session to user. When you say userid dwilliams locking a table you know who to call, but if you see userid app_user you have to do some extra work to track the person down. From a developer point of view, it's easier to determine the name of the logged in user (use built-in user function) than it would be to find out the machine name / application name (select * from v$session). If you have only one username with a password hard-coded in the application, how do you plan on hiding the password from the user, or changing the password if it becomes compromised? -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] Peter - Go with option #1 unless you relish a career as an Oracle security officer. With option #1 the developers can create some administrator screens. Unless security is really, really critical. -Original Message- I am in the process of designing a small database which may have as many as 250 to 300 users. We are reaching a stage where we need to decide how we will control access to this database. As I see it we have two options: 1. Provide a single hidden login for the entire application and control access to the applicaiton itself either by roll your own security or using the operating system (UNIX) controls. 2. Create ids for the users in Oracle and grant them access to the necessary tables using roles. Any opinions or alternate suggestions? Peter Schauss -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
Title: RE: Ids and passwords for application users -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised?
RE: Ids and passwords for application users
--Create roles for the possible user types. --Grant permissions to the roles. --Create induhvidual lusers in the database. --Assign the appropriate role to the appopriate luser. Anything else can quickly become a maintenance/monitoring nightmare. This is why roles were rolled out. Scott Shafer San Antonio, TX 210-581-6217 -Original Message- From: Schauss, Peter [SMTP:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 3:59 PM To: Multiple recipients of list ORACLE-L Subject: Ids and passwords for application users I am in the process of designing a small database which may have as many as 250 to 300 users. We are reaching a stage where we need to decide how we will control access to this database. As I see it we have two options: 1. Provide a single hidden login for the entire application and control access to the applicaiton itself either by roll your own security or using the operating system (UNIX) controls. 2. Create ids for the users in Oracle and grant them access to the necessary tables using roles. Any opinions or alternate suggestions? thanks, Peter Schauss -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Schauss, Peter INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
Peter - Go with option #1 unless you relish a career as an Oracle security officer. With option #1 the developers can create some administrator screens. Unless security is really, really critical. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Monday, July 29, 2002 3:59 PM To: Multiple recipients of list ORACLE-L I am in the process of designing a small database which may have as many as 250 to 300 users. We are reaching a stage where we need to decide how we will control access to this database. As I see it we have two options: 1. Provide a single hidden login for the entire application and control access to the applicaiton itself either by roll your own security or using the operating system (UNIX) controls. 2. Create ids for the users in Oracle and grant them access to the necessary tables using roles. Any opinions or alternate suggestions? thanks, Peter Schauss -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Schauss, Peter INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Ids and passwords for application users
Title: RE: Ids and passwords for application users I always preferred the option of having a userid for each person, because it makes it easier to match session to user. When you say userid dwilliams locking a table you know who to call, but if you see userid app_user you have to do some extra work to track the person down. From a developer point of view, it's easier to determine the name of the logged in user (use built-in user function) than it would be to find out the machine name / application name (select * from v$session). If you have only one username with a password hard-coded in the application, how do you plan on hiding the password from the user, or changing the password if it becomes compromised? -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] Peter - Go with option #1 unless you relish a career as an Oracle security officer. With option #1 the developers can create some administrator screens. Unless security is really, really critical. -Original Message- I am in the process of designing a small database which may have as many as 250 to 300 users. We are reaching a stage where we need to decide how we will control access to this database. As I see it we have two options: 1. Provide a single hidden login for the entire application and control access to the applicaiton itself either by roll your own security or using the operating system (UNIX) controls. 2. Create ids for the users in Oracle and grant them access to the necessary tables using roles. Any opinions or alternate suggestions? Peter Schauss
RE: Ids and passwords for application users
Title: RE: Ids and passwords for application users trying to understand how oracle 9i proxy authentication work. is anyone using it? -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 29, 2002 4:28 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Ids and passwords for application users I always preferred the option of having a userid for each person, because it makes it easier to match session to user. When you say userid "dwilliams" locking a table you know who to call, but if you see userid "app_user" you have to do some extra work to track the person down. >From a developer point of view, it's easier to determine the name of the logged in user (use built-in "user" function) than it would be to find out the machine name / application name (select * from v$session). If you have only one username with a password hard-coded in the application, how do you plan on hiding the password from the user, or changing the password if it becomes compromised? -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] Peter - Go with option #1 unless you relish a career as an Oracle security officer. With option #1 the developers can create some administrator screens. Unless security is really, really critical. -Original Message- I am in the process of designing a small database which may have as many as 250 to 300 users. We are reaching a stage where we need to decide how we will control access to this database. As I see it we have two options: 1. Provide a single hidden login for the entire application and control access to the applicaiton itself either by "roll your own" security or using the operating system (UNIX) controls. 2. Create ids for the users in Oracle and grant them access to the necessary tables using roles. Any opinions or alternate suggestions? Peter Schauss
