SSO Config Tool

[Source: http://geekswithblogs.net/EltonStoneman]

The Enterprise Single Sign On database can function as a centralized configuration store, as well as an identity store, which is available to all BizTalk instances in a group, and also to custom .Net apps. For a clear explanation of the benefits and drawbacks of the EntSSO approach (and the alternative options), see Michael Stephenson's post Where do I store my custom configuration for a BizTalk solution.

Here I'll look at overcoming some of the practical issues in developing, deploying and maintaining config in an EntSSO store using another tool I've been using for a while and have recently put onto CodePlex: SSO Config Tool.

The original purpose was to codegen a strongly-typed configuration model that abstracted away the EntSSO store, and made read-only config values available from a static class for expressions:

- or .Net code:

//extract the UDDI config settings:

string uddiUrl = ConsolidatedGyroscope_App1Config.UDDIServerUrl;

uint uddiTimeout = ConsolidatedGyroscope_App1Config.UDDICacheTimeout;

So it does that (if you're looking for an app which just lets you manage SSO stores, have a look at Richard Seroter's Config Application Manager), and it also gives you:

• a console app to generate the config, and to import/export between EntSSO and an XML config file
• MSBuild task versions of the console functionality
• a UI version of the console functionality, which also lets you maintain config settings:

There are a couple of things worth noting here.

Application Settings

These are all mandatory. The Groups specify who has access to read and update the config store settings. Groups must exist at the time you try and save the app to EntSSO, and they cannot be built-in groups or the "Everyone" group (not that you would…). The BizTalk groups are sensible options, so they're the default for the UI.

Fields

Field types are limited (by EntSSO) to one of the following built-in types:

• String
• Int32
• UInt32
• Boolean

The type you select will be emitted as the type of the property in the generated config model. Values are validated against the given type. The Masked option is a little misleading – all entries in EntSSO are encrypted, but if the field is defined as Masked in the config store then you can only retrieve it if you access EntSSO with a specific flag. The generated config model gives itself this permission, so the Masked value has no effect if you only use the config model.

XML

A custom schema is used so I can capture the expected field data type (rather than inferring it) – so it's similar but not compatible with the structure used by ssomanage.

Generated Code

The config model produced by SSOConfigTool uses a couple of helper classes in the SSOConfig namespace. When you generate the model, you can either generate the source code (so you'll have to add the SSOConfig assembly to your app as well as adding the C# class), or a compiled assembly (which contains the configuration model in your selected namespace, and the helper classes in SSOConfig, so you can use it on its own). The API (Microsoft.BizTalk.Interop.SSOClient) should be in the GAC.

Structure is quite basic – there's an SSOApplication class that represents the config store for an application, and the business of wrapping the EntSSO API is done in SSOHelper. The config class uses SSOApplication behind the scenes to get field values, and exposes them as the correct type. The class also exposes a CacheSSOAccess property which determines whether values are fetched from EntSSO on each call, or lazy loaded – it defaults to being lazy loaded (this is a static class so be aware of the thread implications if you're changing this value).

Some quirks with the EntSSO API are documented here:

• http://blogs.msdn.com/kevin_michael_schultz/archive/2006/12/14/eat-my-rough-draft-punk.aspx
• http://suneetnangia.spaces.live.com/Blog/cns!AF14D545C10A3693!300.entry

For the config tool, the implication is that it creates a dummy field in the config app, but you won't see it unless you look in SSODB.

Usage

I've mainly used the UI to create the app in the EntSSO store, then used the MSBuild tasks to extract the app as XML and generate code from it. Alternatively you can use the build tasks to create the SSO store and/or generate code from a saved config file. The sample MSBuild files in the project show these uses.

Work Outstanding

Only a couple of things – firstly the SSO Config Tool (in its various guises) expects the EntSSO store to be available locally, so currently it doesn't allow you to run it from one machine to update SSO on another. The other one is more of an annoying niggle – if you try to open an SSO app from the UI, you'll probably find the dropdown list of available apps empty. This is down to ISSOMapper.GetApplications always returning an empty list, so until I work out why it thinks the user isn't entitled to view them, you'll need to type in the name of the app. Think of it as a security measure.