WIF supports a flexible configuration system and various ways to programmatically interact with that configuration.
This flexibility comes in two ways:
- Named configuration elements that you can selectively load (service & token handler configuration)
- Configuration extensibility (e.g. for token handlers, issuer name registries or claims authorization)
In this first part I’ll focus on the service configuration.
The WIF configuration can have several service elements. Services can be named, the unnamed element becomes the default configuration:
<!– default configuration –>
<!– alternate configuration –>
You can get a handle to the configuration by newing up a ServiceConfiguration object. The ctor allows to optionally pass in the name of the service. From there on you have an OM that represents the various configuration options.
This is useful when you build your own integration, but for WCF and ASP.NET there is already an infrastructure in place.
How to couple configuration with a relying party
By default the standard hosting plumbing uses the default service configuration, but there are various ways to make this dynamic (e.g. for different environment like dev, staging etc).
In ASP.NET you can subscribe to the ServiceConfigurationCreated event of the FederatedAuthentication class. This event gets fired during initialization and gives you the chance to load an arbitrary configuration and pass that back via the ServiceConfigurationCreatedEventArgs.
You can then access the current configuration at any point via FederatedAuthentication.ServiceConfiguration (since creating a configuration is expensive, this class takes also care of caching).
In WCF you wire up WIF with by calling FederatedServiceCredentials.ConfigureServiceHost(…). This call allows you to either pass in an instance of ServiceConfiguration or the stringified name of the service. Another option is to use the ConfigureServiceHostBehavior from configuration. Again this behavior has a parameter called serviceName.
You can then access the current configuration either by
- finding the FederatedServiceCredentials behavior from the ServiceHost description (if you have access to the ServiceHost)
- obtain it from a MessageProperty called ServiceConfiguration.