There are a number of issues/concerns with storing the password in an arbitrary file:
- Life-cycle management – Keeping track of changes to the file
- Cluster propagation – Migration to all the managed servers? May mandate use of a shared disk
- Config Export/Import - How would this information migrate from one system to another? Having this in a Service Account helps export and import this info across systems. If passwords are in an arbitrary file, we have no way of migrating this data elegantly
Can you provide more detail about your specific use-case and how this is necessary? What other options have you considered and ruled out?
Credentials are stored in a Vault(similar to a file but more secured). Credentials varies from environment to environment and already taken care of for other systems for migration, cluster etc. Passwords will be rotated every x days, so our Security team is pushing every system to read the credentials from the Vault.
They provide a Java Jar which can read the credentials and OSB can do a Java Callout. OSB is able to retrieve the credentials. But, we are having trouble on how to use those retrieved credentials in JMS Proxy (listens to a queue) or in JMS Business (writing to a queue). We only tried Service Account (Static).
There are two phases in accessing a JMS queue -- authentication and authorization.
- Authentication is verifying the user is who he claims to be by checking the password. It is taken care of by WLS security realm, and by default all users defined in the WLS can access JMS queues.
- Authorization is checking what the user can do and is taken care of by Authorization Provider. A JMS queue can be protected by allowing the access only to specific users or roles.
You may not need a custom Authorization provider, though you may need to protect the queue with a specific role to comply with the security team requirements.
You do need a way to authenticate users that are not in the WLS list of users though -- i.e. the Vault may contain the username not in the WLS at all, or, at least, it would contain the password that is not in WLS own default store.
For that you may need to use the custom Realm and a custom realm authentication provider. There is a bunch of pre-defined providers. I never did it, but I believe you may try and use DBMS provider and use, for instance, a HSQL with a CSV-backed database to read the credentials (username and password). The Vault then would have to contain that CSV file.
It may be possible to write a totally custom authentication provider for the realm which reads a totally custom file format that Vault is keeping, but I do not have any information on how to do it.
Hope that helps.