If you’ve been in the BizTalk world long enough, you’ve probably heard that you can securely store name/value pairs in the Enterprise Single Sign-On (SSO) database. However, I’ve never been thrilled with the mechanism for inserting and managing these settings, so, I’ve built a tool to fill the void.
Jon Flanders did some great work with SSO for storing configuration data, and the Microsoft MSDN site also has a sample application for using SSO as a Configuration Store, but, neither gave me exactly what I wanted. I want to lower the barrier of entry for SSO since it’s such a useful way to securely store configuration data.
So, I built the SSO Config Store Application Manager.
I can go ahead and enter in an application name, description, account groups with access permissions, and finally, a collection of fields that I want to store. “Masking” has to do with confidential values and making sure they are only returned “in the clear” at runtime (using the SSO_FLAG_RUNTIME flag). Everything in the SSO database is fully encrypted, but this flag has to do with only returning clear values for runtime queries.
You may not want to abandon the “ssomanage” command line completely. So, I let you export out the “new application” configuration into the SSO-ready format. You could also change this file for each environment (different user accounts, for instance), and then from the tool, load a particular XML configuration file during installation. So, I could create XML instances for development/test/production environments, open this tool in each environment, and load the appropriate file. Then, all you have to do is click “Create.”
If you flip to the “Manage” tab of the application, you can set the field values, or delete the application. Querying an application returns all the necessary info, and, the list of property names you previously defined.
If you’re REALLY observant, and use the “ssomanage” tool to check out the created application, you’ll notice that the first field is always named “dummy.” This is because if every case I’ve tested, the SSO query API doesn’t return the first property value from the database. Drove me crazy. So, I put a “dummy” in there, so that you’re always guaranteed to get back what you put in (e.g. put in four fields, including dummy, and always get back the three you actually entered). So, you can go ahead and safely enter values for each property in the list.
So how do we actually test that this works? I’ve included a class, SSOConfigHelper.cs (slightly modified from the MSDN SSO sample) in the below zip file, that you would included in your application or class library. This class has the “read” operation you need to grab the value from any SSO application. The command is as simple as:
Finally, when you’re done messing around in development, you can delete the application.
I have plenty of situations coming up where the development team will need to secure store passwords and connection strings and I didn’t like the idea of trying to encrypt the BizTalk configuration file, or worse, just being lazy and embedding the credentials in the code itself. Now, with this tool, there’s really no excuse not to quickly build an SSO Config Store application and jam your values in there.
You can download this tool from here.
Technorati Tags: BizTalk
RSS Feed
Great stuff, Richard! I will definitely try this out!
This is great! I’ve been wanting to build something similar for some time. Thanks!
Hi Richard,
I working for customer that uses the SSO Config Store to place configuration data in. One of the backdraws is that there is no easy UI or Tool to manage data inside the store. Your tool provides this so I am very happy not to come with a solution myself. I will introduce your tool to this customer next week and try it out.
Thx,
Steef-Jan
Hey Steef-Jan,
If your customer has any feedback, let me know.
This loooks like a very nice tool! This interface is much cleaner than some others we’ve tried.
I am curious about how to add new fields to an existing application entry. We tried adding them to the bottom of the “Manage” grid and clicking the save button, but the new entries aren’t saved – or, at least, they disappear when the “Retrieve Settings” button is clicked.
We anticipate that some of our applications will continue to grow and require additional configuration settings, but deleting and recreating an app doesn’t seem like a great approach.
Are we missing something?
Hi Kelly,
Funny enough, this topic came up at my office yesterday. In looking at the provided SSO API, you can “UpdateApplication” which lets you change settings, but, doesn’t look like there is an “UpdateFields” to allow for adding/modifying/deleting application fields.
In our case, we took the XML file from our application, added the field we wanted, deleted the old one, and created a new one.
Not great, but workable. I’ll see if there’s a way to add this via some other channel …
Hi Richard,
I have been really trying to implement the SSO solution for our windows applications across the company. I have not found a real good sample which helps to integrate all windows applications (desktop/web [asp/asp.net 1.0,1.4,2.0 etc]) using Biztalk SSO.
Please let me know if you have any ideas/resources relating this.
My email id is jacobmathew@hotmail.com.
Thank you
Jacob
Richard, I was able to finally use this in one of our solutions, and it’s awesome. Thank you for taking the time to put this together and publish it!
Thanks Wade.
And Jacob, I haven’t considered using BizTalk SSO in that broad a fashion. No reason it’s not possible to do so (esp. with AD integration), but I can’t provide you too much direction on this.
Hi Richard,
This looks like a great tool. Is there any guidance on how this compares with the MMC snap-in? I don’t seem to be able to see applications created in one tool when viewing in the other?
Also, are you intending to publish the source code?
Cheers
Mark
Hey Mark,
This does things a bit differently than the snap in. I personally didn’t have as much luck using the built in snap in, thus this tool. I should spend more time comparing the two and seeing how to get the applications created in each to show up for the other.
As for source code, yeah, I need to do that. I’ll try and throw it up on CodePlex this week …
Mark, source code is here … http://seroter.wordpress.com/2008/02/28/sso-config-data-store-tool-biztalkwcf-scenario-source-code-available/
hello,
thanks for the code for that nice little UI, im about to make some changes to your UI to be able to handle an XML inside a field value. I found a way to by pass the problems regarding the static number of field that you can use… that must be set at the SSO application creation. I will probaly attach some text field to your list so you can see much better the XMl value, its hard to see inside a list.
SO we basically have 1 field only in the SSO, that field contain an XML string that you list in it all you config field and values… so it allow you change it as you need.
I also made a rapper around the SSOCOnffighelper class it retreive from the XML(the XML value) the value you want.
thanks again for your code… so i didnt have to completly redevelop such a tool.
Those any1 know if new Biztalk version (other then 2006) will address those COnfig store issue… and have a great UUI for it !!!!
How do I manage SSO config properties using SSO command line tools, if it is at all possible? I could never find any info on this.
Ilya,
Do you mean application-specific properties, or SSO-wide configuration properties? If the latter, you can use the ssoconfig tool to change some things, or use the SSO Admin Snap In to change general SSO properties.
Richard,
Thanks for the great utility. I added some extensions to import/export actual field values to the same configuration file.
Details: http://geekswithblogs.net/paulp/archive/2008/05/16/122205.aspx
That’s awesome, Paul. Smart addition.
Excellent tool. I use it all the time. Just remember not use dots (.) in your application names …
Hi Richard,
Do you have an updated version of this tool that exports existing applications (i.e. from the ‘Manage Application’ tab?) as the File -> Save Configuration to Xml option appears to be grey-ed out; or, can you suggest a way to acheive this?
I appreciate that this sort of defeats the point of an encrypted config store, however our ops team wants a tangible backup before they apply any further changes to the store.
Cheers, Nick.
Hey Nick,
Were you thinking of exporting the “config+data” or just be able to export the configuration of existing applications?
Config+data, but just for a single app.
Hey Nick,
I guess we’d have to add a feature to export the data as well, and, when loading it back in, populate the UI controls. I’ll have to take a look at that and see if you’re proposed “Export Application” is easy to put in.
Absolutely fantastic. We were about to do something like. You saved our time.:)
Hey Richard! Great tool! Ur the man!
Hi,
I’m receiving following error while trying to use code for Helper class:
Class ‘ConfigurationPropertyBag’ must implement ‘Sub Read(propName As String, ByRef ptrVar As Object, errorLog As Integer)’ for interface ‘Microsoft.BizTalk.SSOClient.Interop.IPropertyBag’.
I copied the code as is from your helper class and converted that to Vb.NET.
Let me know if i’m missing something?
Hi Richard,
great tool. thanks.
When i try to use it in biztalk 2006R2 on the send port the affiliated application doesnt show. It must be something in the database. If you ever figure it out please let me know.
I think it is the same reason that biztalk SSO admin tool doesnt show it.
Thanks
Ankur,
What happens if you leave the class in c#, compile it into an assembly, and reference it from VB.NET code instead?
Hi Richard!
It’s a Great tool you’ve got here. Would really want to use it for storing username/passwords in our FTP-ports.
I’ve experimented with it a little bit and it works fine apart from the thing that “john” noticed. The affiliate application wont list neither in the “SSO Affiliate” drop list (in the FTP port config) nor by running “ssomanage -listapps” (nor from the mmc but I guess thats pretty much the same).
However I see it in the SSODB SSOX_ApplicationInfo table and i can use your tool to retrieve the settings.
Perhaps this is not a problem (since there are a bunch of other apps in the SSOX_ApplicationInfo table that don’t get listed either) but I’m new to this so frankly I don’t know. Perhaps I should mention that I’ve tested it on my local developer machine that isn’t connected to a domain (no AD accounts).
The thing here is that I think it would be nice for our administrators to be able to see what apps there are via the standard mmc GUI.
It would be really happy if could help out and shed some light on this.
Best regards/Merry Xmas
Mattias Hammarsten
Richard,
The Save Configuration as XML function is disabled from the Manage Application tab. How do I get it to work?
Hi there,
I think that option is only enabled when you create a new application, not when you view an existing one.
Hi Richard
I’ve developed a GUI tool that does a similar job to yours except that you can view all apps and associated key/value pairs.
The problem I have is that if a single app contains more than 512 config entries, the SSODB throws a fit and responds with the following error: [RPC: 0x800706F7: The stub recieved bad data] and none of the config data is viewable.
I was wondering if you’ve ever come across this limitation on the number of config entries an app can contain and, if you have, if you know of a workaround.
Regards
Patrick
Hey Patrick,
I haven’t seen that limitation and unfortunately am not aware of a resolution except for splitting up the values into multiple apps!
Sir,
I know it is slightly off the topic but do you know if and how I can package this onto a applicaion using deployment framework. Also, am I allowed to do that from a licencing perspective(since it is your code)
regards,
PS
Not sure how to package it, but you are certainly welcome to do so without any fear of me chasing you down later. All I ask is that you keep the acknowledgements of me as the author.