Using Credentials Files

Some Web services may require clients to authenticate themselves before allowing access to the service. The authentication process uses credentials. There are two types of credentials supported by LightWave Client:

a userid and password used for authentication
a pass phrase associated with a PKCS12 certificate used for SSL client authentication

The type of authentication required, if any, is dependent on the Web service. If authentication is required, you must supply your credentials to the CLIENT process to use on your behalf .

LightWave Client provides a mechanism for storing your credentials in an encrypted format. Rather then specifying your credentials in clear text as a command line parameter whenever starting CLIENT, you can specify the name of an encrypted credentials file. The encrypted credential information can then be used by the CLIENT process for authentication when necessary.

Credentials files are created and validated using the LWCCOM utility. Refer to LWCCOM for more information. You can create as many credentials files as necessary, since different Web services may require different credentials.

This example stores the userid 'myuserid' and password 'mypassword' in the encrypted credentials file "mylogin", then supplies the credentials filename with the -httpauth command line parameter when starting SOAPAMCP.

CODE

tacl> run lwccom create credentials mylogin !, credentials myuserid:mypassword
CREDENTIALS file $VOL.SUBVOL.MYLOGIN created
tacl> run client / name $cli / -http-credentials +mylogin @otheropts

This example stores the pass phrase in the encrypted credentials file "certpass". Since the credentials parameter was not specified, LWCCOM prompts the user for the credentials without echoing them to the terminal.

CODE

tacl> run lwccom create credentials certpass !
Enter credentials:
Re-enter credentials:
CREDENTIALS file $VOL.SUBVOL.CERTPASS created
tacl> run client / name $cli / -client-cert mycert +certpass @otheropts

Note that the credentials file is location dependent, i.e., if the file is moved or renamed, the credentials cannot be decrypted. This feature is designed to disable the credentials in case the file is stolen or otherwise used inappropriately. You can specify an alternate target location for the credentials file if the file is to be created in one location but moved to another location for deployement. This example creates a credentials file on the current volume for eventual deployment on the $SYSTEM volume.

CODE

tacl> run lwccom create credentials mylogin !, credentials myuserid:mypassword, target $system.deploy.mylogin
CREDENTIALS file $VOL.SUBVOL.MYLOGIN created

Even though credentials become invalid when moved, system administrators should still use Guardian security to prevent unauthorized access to the contents of the file.

This example verifies the contents of the credentials file.

CODE

tacl> run lwccom validate credentials mylogin
CREDENTIALS file $VOL.SUBVOL.MYLOGIN is valid