putting credentials into environment variables encourages non secure behavior

Issue:

- putting credentials into environment variables encourages non secure behavior such as putting credentials in a clear text file and and loading them via .bashrc or similar at login time. This is particularly problematic if swift authentication is integrated with the corporate ActiveDirectory / LDAP authentication as it would affect Enterprise authentication credentials and potentially violate enterprise policies.

Solution

- longer term a kerberized swift infrastructure would be an appropriate solution, however it takes significant resources to implement. Short term it would be sufficient to use swift auth tokens in a way that could perhaps be described as "poor man's kerberos tickets".
Implementation: after successful authentication to swift, swiftclient should store an auth_token for each storageurl in the user's home directory (e.g. ~\.swiftclient\auth_storage_url). When swiftclient starts and no ST_ environment vars are set and username and password a not provided via command line, swiftclient should attempt to use the stored auth_token. If the auth token is invalid/expired and ST_AUTH is set, the user should be prompted for user name and password/key.

In addition to swiftclient handling persistent auth_tokens a systems administrator could easily implement several methods for keeping an auth_token current. On of these methods could be using a custom pam module such as pam_script. Another simple method would be a shell script running in an infinite loop and updating the auth_token once a day.