(applies to preview 1)

A common request for IdentityServer was being able to run on Azure WebSites (or other constrained deployment environments where you don’t have machine level access). This was never easy because our default implementations in v2 had a dependency on the Windows certificate store which is typically not available in those situations.

Note: A security token service is typically not a good candidate for shared / high density hosting – especially on a public cloud. There are certainly exceptions to that rule, e.g. for testing scenarios as well as private clouds – also – e.g. Azure WebSites do support modes where the machine is not shared between tenants.

1 Loading the signing key
IdSrv3 supports two modes for signing the identity token – either asymmetric using the default x.509 signing certificate or symmetric using the secret of the requesting client. In the latter case no certificates are needed at all for identity tokens.
Similar for access tokens – either you use the X.509 certificate and self contained tokens (JWTs) or you use reference tokens.

So IOW – if you want to get around X.509 certificates – you can. But quite frankly, for most situations asymmetric signatures are really what you want – so we made it much easier to deal with certificates in v3.

The heart of IdSrv3 is the ICoreSettings interface – on there you can find the GetSigningCertificate method from where you return an X509Certificate2. How you load that certificate is now totally up to you – from the certificate store, from a file, blob storage – or like in our test setup – from an embedded resource (we will actually add some helpers to simplify that in a later release). This gives you a fair bit of flexibility.

2 Public vs internal host name
In many (shared) hosting scenarios, your local machine name and the machine / DNS name that external parties will use is different. That could be due to CNAME settings, reverse proxies, load balancers and SSL termination. We added support for that in IdSrv v2 – and it was a bit painful since it was an afterthought. In v3 you can now specify the public host name on ICoreSettings (see above) – see here for an example. If you don’t specify anything here, we assume the value of the host header and SSL.

3 Managing deployment configuration
The above settings are all in code, so you might wonder how you maintain different “configurations” for different deployment scenarios.

One approach would be surely to load the variables from web.config and use config transforms during publishing. This will get very complicated very quickly. The current approach we use is to maintain several Katana startup files, one for each deployment environment. A lesser known feature of Katana is, that you can specify the startup class in web.config, e.g.:

<appSettings>

      <add key=“owin:AppStartup“ value=“LocalTest“ />

</appSettings>

..and then map the value LocalTest to a startup class in code:

[assembly: OwinStartup(“LocalTest”, typeof(…))]

You can then use config transforms to use the right startup class for your target environment, e.g.:

<appSettings>

      <add key=“owin:AppStartup“

                  value=“AzureWebSites“

                  xdt:Transform=“SetAttributes“

                  xdt:Locator=“Match(key)“/>

</appSettings>

I hope the above changes make hosting and deployment easier in IdSrv3 – I you have any feedback please come to the github issue tracker and join the conversation!