Saturday, June 26, 2010

VirtualBox networking between host & guest

When I first setup VirtualBox 3.2.4 to host Ubuntu 9.04 on Windows 7, I had a NAT network adapter selected and soon found that my host could not see the virtual guest and the NodeJS server I was running. So after Googling I found a great post that directed me to to use the Bridged Adapter that would request an IP address from my router and play as an equal member of my network and all was good... but then later I happened to be offline and since there was no central DHCP server, my host could not see my guest once again! A little more Googling and experimentation later I found that the best solution for me was to setup a second Host-Only Adapter set to the VirtualBox Host-Only Ethernet Adapter. When the guest started I selected to enable the second adapter and so now my setup would work whether I was online or off! Yeah!!! :D

Friday, June 4, 2010

SAML and WSRP trials and tribulations

Well, this wasn't the first blog I thought I'd be writing, but since I just resolved a blocking production promotion configuration issue last night and the initial exception I ran into only turned up one forum post when Googling on it, I thought this might be a good one to post...

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 FederationServicesMBean
The 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:

Tuesday, June 1, 2010

Why is this here?!

The obligatory first post!

I've been programming for many years and some of the most helpful information that has either saved me time or saved my butt I've found on one blog post or another. So I thought I'd try and pay back the gift and blog on my own technical triumphs in case they may be useful to someone else...

Whatever subject I'm sure to blog on will be something I'm probably not an expert on since I was struggling to solve it myself and felt that it might be worth sharing and possibly if i'm lucky I might get some additional helpful feedback! :)