Ahh joy, after a wait few weeks long I an finally typing on by brand new purple type cover 2, snapped to a shiny new Surface Pro 2! I just *have* to use this guy, and what better mixed workload than writing a blog post? That will exercise Visual Studio, the portal, Live Writer\u2026 it\u2019s a comprehensive workout!<\/p>\n
Today I\u2019d like to talk about some features of the new organizational ASP.NET project templates, which might catch you by surprise if you don\u2019t know about it.<\/p>\n
Here there\u2019s the customary backgrounder. If you don\u2019t care about the theory, you can skip to the last section right away.<\/p>\n
As many of you know, the essence of authenticating a call boils down to deciding whether the caller is presenting a valid token with his\/her\/its request. What determines if a token should be considered valid? Well, the usual: some aspects are purely structural (it should be signed and not having been tampered with; should be of the expected format; should be scoped for your app; should not be expired; and so on) while others are expressions of the trust relationship between your application and the authority you are outsourcing your authentication to. In a nutshell, the latters boil down to the following: the incoming token should be signed with the key <\/strong>that you know belongs to the authority you trust (or the infrastructure the authority uses for minting tokens), and should have an Issuer <\/strong>value corresponding to it too.<\/p>\n Traditionally, WIF 1.0 and the corresponding classes in .NET 4.5 kept track of those values by saving them in the web.config. I already spoke about some of the limitations the original classes had in terms of expressive power<\/a> and maintaining the settings fresh<\/a>.
Although for relatively stable scenarios you are fine, there are multiple issues in keeping those in the config if your settings change often and if you have to keep tab of a large number of authorities (if you sell SaaS apps, that\u2019s a good place to be).
Given that those are scenarios of great interest, the ASP.NET templates use the WIF extensibility endpoints to save the validation coordinates in a database. The process is pretty straightforward, although a bit verbose: you can trace it back by looking of the autogenerated code in the template. Starting from the web.config, the first change is in the <identityConfiguration> element:<\/p>\n <<\/span>system.identityModel<\/span>><\/span>\r\n <<\/span>identityConfiguration<\/span>><\/span>\r\n <<\/span>issuerNameRegistry<\/span> type<\/span>=\"WebApplication1.Utils.DatabaseIssuerNameRegistry, WebApplication1\"<\/span> \/><\/span><\/font>\r\n <<\/span>audienceUris<\/span>><\/span>\r\n <<\/span>add<\/span> value<\/span>=\"https:\/\/contoso7.onmicrosoft.com\/WebApplication1\"<\/span> \/><\/span>\r\n <\/<\/span>audienceUris<\/span>><\/span>\r\n <<\/span>securityTokenHandlers<\/span>><\/span>\r\n <<\/span>add<\/span> type<\/span>=\"System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\"<\/span> \/><\/span>\r\n <<\/span>remove<\/span> type<\/span>=\"System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\"<\/span> \/><\/span>\r\n <\/<\/span>securityTokenHandlers<\/span>><\/span>\r\n <<\/span>certificateValidation<\/span> certificateValidationMode<\/span>=\"None\"<\/span> \/><\/span>\r\n <\/<\/span>identityConfiguration<\/span>><\/span>\r\n <\/<\/span>system.identityModel<\/span>><\/span><\/pre>\n