OWSM's key store and credential store are always mysterious to me. As i get better understanding them, i'm recording what i have learned.
By default, OWSM key store (also referred to as OWSM agent's key store) is here: "<domain home>/config/fmwconfig/default-keystore.jks". The actual location can be found in this file: <domain home>/config/fmwconfig/jps-config.xml.
You can configure the keystore from the "em" console, expand "Weblogic Domain" on the left, then right click your domain, select "security", then "security provider configuration", and on that page, click "configure" button under the "Keystore" section.
There are many key stores in SOA suite. This one is for OWSM. It uses the certificates in the store for encryption/decryption when processing OWSM security policies. Do not confuse this keystore with the ones for Weblogic server. Those are under Weblogic console->"Environment"->"servers"-> "your server", then under the "Keystores" tab. You will see at least two "identity" and "trust" stores. Those stores contain certificates mostly for the server SSL among other things.
Based on my observation, when a domain is first created, although "em" console, security provider store configuration page shows the file is "./default-keystore.jks", that file doesn't even exist. You need to use java "keytool" command to generate the file. For example,
keytool -genkeypair -alias test_domain_alias -keyalg RSA -keypass welcome2 -keystore test_domain.jks -storepass welcome1 -validity 3650
For example, keytool -list -v -storepass welcome1 -keystore test_domain.jks, will display the certificate contained in the key store.
Once the test_domain.jks file is created, you can put it in the default place (or other place as you choose) under "${your domain home}/config/fmwconfig", then you can configure the store as shown below:
So where is all the information you entered stored? They all went to the credential store. I believe the physical file is cwallet.sso, it's a binary file, you can't see much of it.
What is the credential store then? Well, all I know is that it stores some "credentials", such as user name and password. Each entry has a key. The overall credential store is organized by "maps".
You access the credential store as shown in the first picture above. Here is a sample view:
If you already configured the key store as above, you will see at least one "oracle.wsm.security" map, under the map, you'll see at least 3 keys: sign-csf-key, enc-csf-key, and keystore-csf-key. These are populated when you configured the keystore. If you change them here (for example, edit sign-csf-key, try change the value from "test_domain_alias" to something else), and you go back to the keystore configuration, you'll notice it is updated over there as well. Again, it's garbage in garbage out, whatever you enter, it would be saved as-is. It's your responsibility to enter the info correctly. If you go to the extreme and delete the oralce.wsm.security map here, then go the keystore configure, you'll see the data is wiped out over there and you'll have to reconfigure the keystore.
BTW, how does OWSM know to use these 3 special keys to access the store. If you open fmwconfig/jps-config.xml, you'll find them there.
That's quite enough about these 3 keys! Let's look at the other key i created manually, "basic.credentials". Under the key i have user name "weblogic", password "welcome1". This is typically used like a "service account", if a BPEL or OSB business process need to invoke another service and provide a service account, you can simply reference "basic.credentials" under oracle.wsm.security. It just so happened that several OWSM security policy reference this particular key "basic.credentials" by default. For example,if you have oracle/wss_username_token_service_policy on a proxy and run the test console on the proxy, you'll see it uses "basic.credentials" by default.
I think oracle/wss_username_token_client_policy does the same, at least for SOA client, it uses "basic.credentials" for user/pass if you don't explicitly specify them in your code.If your key name is something different, then your process needs to reference the other name.
great article. keep up!
ReplyDelete