Every experienced BizTalk developer knows that the SSO store is a good place to safely store configuration information. It is secure, distributed and can be updated without having to dive into configuration files (but too bad the host instances have to be restarted after a change before it is picked up). Accessing the SSO used to be difficult until Richard Seroter wrote a tool for it.
In 2009 Microsoft acknowledged the problems and introduced an MMC snap-in to basically do the same thing, but then with a nice user interface. However so far no command line version appears to be available to support automated deployment. Although the Microsoft package contains MSBuild support, I couldn’t find a commandline version so I decided to write/create one myself.
The tool is no rocket science, most of the code is borrowed from the code the MMC snap-in executes to perform tasks (long live ILSpy).
The tool supports importing, exporting, deleting, retrieving details and listing SSO applications.
With the MMC snap-in there now are two SSO tools available, because also the good old ENTSSO Administration tool is present. The weird thing is that the ENTSSO Administration tool displays more SSO applications than the MMC snap-in does. The reason for this is the strange fact that the MMC snap-in only retrieves SSO applications where the contact information equals .com">“BizTalkAdmin@<company_specified_in_sso>.com”. This is not always an issue because creating an SSO application automatically sets “BizTalkAdmin@<yourcompany>.com” as the contact email address. It will become an issue if you have to change the email address for example because you don’t have a .com domain…..
Filtering still serves a purpose because there are some default SSO applications that shouldn’t show up in the tool, like adapter configuration settings. In the SSO Config Cmd Tool this potential problem is solved by taking the opposite approach, namely to exclude the contact email addresses “email@example.com” and “firstname.lastname@example.org” because they are related to the build-in SSO applications.
Let’s take a look at the tool and go over the actions one by one.
If you open the SSO snap-in, you’ll get this user interface. For demo purposes I already created a ‘TestApp2’ with two keys.
If you run the SSOConfigCmdTool without arguments, you’ll get help about the usage of the tool.
To list all SSO applications, where the contact info is not “email@example.com” or “firstname.lastname@example.org”:
To retrieve the details of this ‘TestApp2’ application (as you can see the tool is case insensitive):
To export an SSO application, you need a encryption/decryption key and of course a file to export to. If you omit the extension automatically ‘.sso’ is appended. After the export a file is present at the specified location.
To be able to demonstrate the import, first the delete:
After delete, as expected the SSO snap-in doesn’t display the SSO application anymore:
Next we run the import to reinstall the SSO application. The nice thing is you can supply a different name for it (here ‘ImportedTestApp’ is used').
Now we run into the issue mentioned above. The SSO snap-in doesn’t display the newly created application, while the good old ENTSSO Administration tool does. This is caused by the filter I previously discussed. The SSOConfigCmdTool doesn’t know your SSO company name, so it imports (creates) the SSO application with contact information ‘biztalkadmin@YourCompany.com’, which will be filtered out by the SSO snap-in.
How to solve this?
One option is not to solve it, because the SSO application is actually there despite the fact that it isn’t displayed.
Another option is to go into the ENTSSO Administration tool and change the contact info to .com">“BizTalkAdmin@<company_specified_in_sso>.com”, but that would involve manual intervention.
The most easy and sustainable way is to grab the source code from this tool and change “YourCompany” to <company_specified_in_sso>, which is in fact just a single line of code in the Program class.
Just compile it after the change and you’re good to go.
Anyhow, after setting the contact information correctly, the imported SSO application shows up.
The executable and the source code of the tool can be downloaded here at CodePlex.
If you run into an issue, please let me know so I can improve the tool. And of course I’m curious if this tool already existed…..
Didago IT Consultancy