Authentication for batch jobs applications

[aajoseph]

I'm interested in knowing on some of the best authentication mechanisms that can be used for batch jobs which running in database servers. Currently we are using Oracle database and uses the operating system authentication(aka ops$ authentication) for batch job to log into the database.

Basically planning to re-design and rewrite the batch job application in order to uptake Oracle RAC. What are the common design widely used for batch job authentication other than Operating System authentication where we doesn't need to pass the password while connecting.

 

[Tsotne]

Do you mean the structure of log-pass match in design or just the information required to log-in for job-batch apps? If you mean the 2nd, then mail (or username) + password is enough and commonly used in such kind of applications...After all, what else needed?! This if I got the point correctly but I think you are seeking the authentication mechanisms themselves...

 

[aajoseph]

Do you mean the structure of log-pass match in design or just the information required to log-in for job-batch apps? If you mean the 2nd, then mail (or username) + password is enough and commonly used in such kind of applications...After all, what else needed?! This if I got the point correctly but I think you are seeking the authentication mechanisms themselves...

Currently we are using shell scripts to launch different programs whenever user submits any batch job. If we pass username + passsword to connect to the sqlplus through the shell script for authentication seems to be less secure since any other user can list the parameters(ps command ) in the Unix prompt and can see the password which pass for the connection.
I more interested to see any other mechanism like keeping the password in Wallet(like Oracle Wallet) or any similar and more secure authentication mechanism which can be used for batch job..

TIA.

 

[Tsotne]

So you are mainly interested in the logic of saving the password secure. There can be many such depending on the application you are developing. No very different specifics for batch jobs See Microsoft website and see if you can find similar logic for SQL.

 

[alain]

So you are mainly interested in the logic of saving the password secure. There can be many such depending on the application you are developing. No very different specifics for batch jobs See Microsoft website and see if you can find similar logic for SQL.

This is just fluff. I wonder how many batch applications you have deployed in a real production environment.

To the OP, you will have to stored the password somewhere. The first thing that comes to mind is an environment variable that you only have access to.

 

[Tsotne]

Storing username plus corresponding password (and other mathching variables if needed) is the way to go in standard non-bacth job application. He is interested in storing logic such that the variables are secure no much concern on the combination of needed information itself. As for your first question, I have developed many username-password matching logic in SQL not for batch job apps but I don't see the need of some special treatment for that kind of application in terms of safety. So you'd better ask: "I wonder how many batch applications you have deployed in a real production environment in terms of information needed" None.

 

[aajoseph]

I'm just refining my question:
1. All attempts to connect to the database locally using operating system authentication(OPS$ authentication) is inherently flawed security.
2. Batch mechanism always needs to provide a password to access the database. Using shell variable (value) where the password used to connect the database is visible using process listing therefore the question of encryption of a password becomes important.

3. Secure external password( like Oracle wallet) mechanism does provide a practical improvement above plain text passwords but experts reviewed this as bad practice.Still I'm trying to understnad why this is a bad practise!

4. Looking for password encryption strategy to effectively hide the password. But my concern here is encryption is flawed in this case as well because application must always decrypt the password to connect to the database. So if the application is able to execute the decryption function, then determined people will also be able to decrypt the password.

So what is the the correct approach to create a batch job within the database to execute a stored package or procedure. And also require the results the automated execution to be output to a file?