SAML Authentication on F5 Big-IP (Part 5)

It is time to have a conclusion on this subject.

F5 support team finally lost interest, they didn't reply my question any more, because I was only a trial user I think. I had to put this issue aside for weeks.

Once I thought I had insightful understanding on SAML, especially the XML signature, I decided to review this issue again by myself.

When my eyes rested on the attribute WantAssertionsSigned in F5 BigIP metadata,

I immediately realized I got the answer! IDP sent a SAML response which signed the signature on the whole response, however F5 BigIP appliance specified to expect the signature on assertion part of the response.

After modifying the response (calculate the signature to assertion part), it worked!

I blushed with embarrassment at that time, as SAML authentication on F5 BigIP did work (at least it accepted signature on assertion, not sure it accepts the signature on response). However F5 error message "Digest of SignedInfo mismatch" puzzled everyone.

If we look at the response again, now it is very obvious that the signature was on Response (instead of Assertion, just compare the value of Reference URI with the _IDs)!

Silly me! but could F5 error message become more intuitive?

Password Pass-over In NetScaler

NetScaler supports SAML authentication, and you can pass over the username from IDP to NetScaler through SAML response (see the details in this link). This is very useful when you want to single sign on XenApp, it will pre-fill the username field in CWI login.

Ideally it would be perfect if we could pass over the password as well.

Citrix mentioned the SAML response generated by NetScaler Gateway virtual server could contain password. The vpn SAML profile can have a parameter called "sendpassword". Please see the details in How to Configure SAML SSO Authentication between NetScaler Gateway and Load Balancing Virtual Servers. It implies NetScaler supports the password pass-over, internally at least.

I was very curious if the third-party IDP could take the advantage, so I dug into NetScaler module.

The SAML response generated by NetScaler itself contains password attribute.

<saml2:Attribute Name="password" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:type="xs:string">the encrypted password</saml2:AttributeValue></saml2:Attribute>

How is the password encrypted? If the third-party IDP follows the rule, it may be able to pass over the password!

The password is actually scrambled by vpn_global_key, which is initialized randomly during system boots up.

ns_sslvpn_copy_passwd(char* srcpass, char* dstpass, unsigned int len)

{

for (int  i = 0; i < len; ++i )

dstpass[i] = srcpass[i] ^ vpn_global_key[i];

}

In ns_aaa_saml_auth, the password (if it exists) is restored.

if ( (unsigned int)(len - 1) <= 0x7E )

{

ns_sslvpn_copy_passwd(src, dst, len);

}

Unfortunately, I don't think there is a way to transmit the vpn_global_key over SAML Request which is the only way the IDP get the information from NetScaler, so my conclusion is, currently it is impossible for the third-party IDP to pass over a valid password value to NetScaler.

MSI Major Upgrade by Wix

Wix provides an element MajorUpgrade to make a major upgrade a little bit easier, You still need to pay a lot of attention on the sequence and conditions on custom actions, if you have any.

In MSI, upgrade actually contains two parts: uninstall and install. Which one is done first. it is decided by the attribute Schedule. For instance, if Schedule = afterInstallValidate, this scheduling removes the installed product entirely before installing the upgrade product. While Schedule = afterInstallExecute, it installs the upgrade product "on top of" the installed product then lets RemoveExistingProducts uninstall any components that don't also exist in the upgrade product.

If you have any custom action, for example, retain data file during upgrade, register and start service after installation, stop service and unregister service before uninstallation, inevitably you want to utilize some built-in properties like “Installed”, “UPGRADINGPRODUCTCODE”, “REMOVE”,“REINSTALL”. On StackOverflow, there is a good summary which I copied it here.

As I pointed out earlier, an upgrade consists of two phases, you may wonder, are these property values are same in two phases? Unfortunately, the listed values under “Upgrade” actually apply to the uninstall phase of upgrade. The install phase of upgrade has same values on this properties as a new install, which means you can’t tell the difference with these properties between a new install and the install part of upgrade. I would suggest you writing a vbscript type custom action to check something else directly.

Assume you have installed a product with version1.msi, now you are going to upgrade it with version2.msi. Remember, the install part of upgrade will use version2.msi, but the uninstall part of upgrade will use version1.msi which was saved somewhere when you first installed it.

Read more...