DSXchange

Hello everyone,

I am developing a utility DataStage v5.2 application to help automate my company's on-site DataStage job update process. My company is of a situation where it must perform on-site updates of a core set of DataStage jobs whose associated parameter values vary by client.

The application, in brief, parses a .DSX file building a list of jobs while keeping track of associated parameter information. It then retrieves pre-existing parameter values from a target DataStage. Next it calls DSCMDIMPORT.exe to perform the actual import of the .DSX file into the repository. And finally, it updates the jobs within the repository with the pre-existing or user-defined parameter values.

My problem exists at the pre-import step where parameter values are displayed and the user is allowed to override them. First, encrypted parameter values from the .DSX file and the target repository are displayed in encrypted form. Here I would like to display the un-encrypted form. Next, if the user modifies the value of an encrypted parameter, I need the ability to encrypt the entered value before updating the repository. Because the Job API is not available for DataStage v5x and above, I am using Universe's InterCall API to connect to and modify the DataStage repository. Is there a ic_subcall() that I can make to handle string encryption/decryption? Or an ActiveX control? Or anything else...

Thanks,

Chris Simms



Edited by - csimms on 12/03/2002 13:56:16

DataStage uses one-way encryption. Put another way, DataStage has an encrypt() but not a decrypt() function. Password checking is performed by comparing encrypted strings.
The same is true in the InterCall architecture. The only place where passwords may be stored in non-encrypted form is in the Password property of a Session object. It is passed to the server always in encrypted form, and can only be retrieved in encrypted form.
Sorry, but that's how it is. I guess you're going to need some mechanism to prevent users from changing encrypted parameter values (training?).

Ray,

First, thanks for responding.

If and I am not saying it does not, DataStage uses one-way encryption, how would an encrypted parameter value used to represent a database connect password work? That is if there is no decrypt() function, how would the DataStage server while executing a job pass an encrypted version of a parameter value, used to represent a connect password, to a DBMS and then expect the DBMS to validate it?

Chris

Edited by - csimms on 12/04/2002 10:03:13

Interesting thought. Perhaps Ray means there is no 'public' decrypt() function available?

-craig

Yes, that's what I meant. In fact, if it does have one, they've either hidden it really well (I can't find the entrypoint) or maybe they've not called it decrypt(). C'est la vie.

With the one way encryption you can still let users re enter encrypted parameters. This is fairly standard functionality in many products, for example a DataStage database stage will show the password as a set of asterisks but the user can erase the value and type in a new one. You could mimic this functionality in your application. Let the user enter a string then encrypt and save it.

If the DataStage product provided a decrypt function it would create a security hole in the application. A user could write a custom app that can connect to any DS server and decrypted all the passwords.

Sounds like if Chris reallys want to display the unencrypted passwords to the users, the answer may be to simply stop using an 'encrypted' parameter and simply go with a 'string'. I don't really see the point in decrypting the password, showing it to the user, letting them override it and then encrypting it back again... kinda seems to defeat the purpose of encrypting it in the first place. [shrug] Just an opinion and a random late night thought.

-craig

Just out of curiousity, did you ever look at the 'Parameter Manager' tool offered here? I'm wondering if it might have some capabilities you could leverage, especially since they seem to maintain a central 'parameter repository'.

-craig

No, not yet. But I think I have arrived at a solution to my problem. I am fairly certain I have been able to duplicate the encryption/decryption that DataStage v5.2 uses. So as far as my tool is concerned, it should work fine for that version of DataStage.


Edited by - csimms on 12/05/2002 16:03:45

Once a job is in place, even on production systems, the Director can be used to set default values for job parameters (Set Defaults), even encrypted ones.
Would this solve Chris's problem? Just supply a short document explaining to the client how to set default values then - should it be appropriate - disable further prompting for the parameter.