About a year ago I used to religiously use the SSO database as a config store for my BizTalk applications, regardless whether there was a requirement around security or not. Back then the site I was working on had the all the BizTalk host accounts in the SSO affiliate application users group so by default every host had access to every SSO application.

A year later, and after many debates about the ideal store for rules, I have changed my stance somewhat. I must say that my current bias is towards the business rules engine, be it for orchestration or pipeline config.

That said, there are still scenarios in which I would want to use the SSO database (note that I personally am very anti using the BizTalk config files, the way I see it that is specific to the runtime on a given server and should be for the framework rather than applications within the framework, but that’s another discussion altogether). The way I see it, SSO is relevant in the scenarios below.
•The storage of secure configuration items.
•The storage of configuration items that may vary from environment to environment thus can’t be statically defined in a business rules policy unless you had varying policies deployed to each environment.
•The storage of configuration items that might need to be changed on the fly without any formal controlled deployments.

Some colleagues and I recently tried using the SSO database to store the credentials used by a webservice being called on through a WCF send port in our BizTalk application. These credentials needed to be added to the SOAP header of the outbound message thus this was a task well suited for a send pipeline. Given that there is a requirement for security around these credentials, our recommendation was that the BizTalk host accounts shouldn’t be in the SSO affiliate applications users group by default and instead for the specific accounts to have rights over the pertinent SSO application provided through the SSO administration MMC.

This worked fine for awhile, until much to my dismay the application stopped working when we had to update the credentials in the SSO store using the SSO Application Configuration MMC (using Richard Seroter’s tool which was a pre-cursor to the aforementioned Microsoft MMC demonstrated the same problem as well). The specific error message I saw was that the BizTalk host did not have the required rights over the SSO application.

Further investigation showed that any changes made to a SSO application through the MMC will result in any non-default permissions being dropped off the application. These changes might include adding or deleting a key/value pair, or updating one of the value in an existing key/value pair.

The conclusion I had to take from this was that either the host account must be in the SSO affiliate application users group or any changes made to config need to be done so in a very controlled manner, most probably during an outage. This experience has definitely tipped me even further into the BRE camp except when there are strict requirements around authorization for retrieval of configuration items.