Background: We run several clustered BEA 10 domains at work. Each run 2 nodes each on 3 boxes. At the primary data center we have 3 domains running on those 3 boxes and at a secondary data center in another state we have only one active domain with the same configuration.
In this this case I developed and deployed a WSRP producer EAR at the secondary data center and I needed to register that producer on one of the domains located at the primary domain. The steps to setup SAML and WSRP are not difficult and the documentation is pretty easy to follow. However, when I first configured this setup in the test environment I ran into the following exception:
com.bea.wsrp.faults.TransportException: Security token failed to validate. weblogic.xml.crypto.wss.SecurityTokenValidateResult@5d70680[status: false][msg The SAML token is not valid.]After tweaking and adjusting everything I could think of, I could finally get it to work if I "touched" the configuration, but then it would eventually stop working or if I bounced the nodes the exception returned immediately. I opened a support case with Oracle, but they were not able to solve it before I happened on a solution myself. What I discovered is that in our configuration I had to check (set to true) the "Include Keyinfo" option on the Relying Party defined on the SAMLCredentialMapper. Why so is still a mystery to me...
Now when it came to the production promotion, I thought, based on my test deployment and configuration, I had a firm understanding of what I had to do if not exactly why. And it turned out in the end I did, but I still ran into a speed bump! When trying to apply the "Issuer URI" and "Signing Key Alias" changes to the SAMLCredentialMapper I got the following error:
SAMLBeanUpdateListener SAMLCredentialMapperV2: prepareUpdate() failed with exception: provider SAMLCredentialMapperV2: SAML Key Manage failed to validate key (Assertions signing) configuration in the FederationServicesMBeanThe one forum post I found did not give an answer except to manually change the setting in the config.xml and restart. So that's what I did! :) Everything came up as expected so I moved forward and then my old nemesis returned... I was seeing the token error again when trying to register the producer.
After engaging Oracle support again to no avail, I once again solved this one with a little help from my buddy in the Data Security group. Turns out the keystore files in the production environment were not configured with shared aliases (specifically the one I was using on the credential mapper) and I noticed that early on and dutifully used keytool to export and import the aliases to the other boxes in the cluster. I thought I was smart and had averted that problem before it started. But I wasn't smart enough...
In the end what I found is that the aliases were chained (visible when using the command: keytool -list -v) and had a private key. So my simple export/import did not bring over the second chained entry nor the private key. Fortunately for me, Google did find me a good solution in KeyTool IUI. With KeyTool IUI I was able to export the chain and the private key from one keystore and import them both into the other keystore files. Once the aliases were properly set on each box, the producer registered perfectly and the content was there!
Here are the two screens I used to export and import my aliases: