The scenario described in my last post works because of the design around HTTP modules in ASP.NET. Authentication related modules (like Forms authentication and WIF WS-Fed/Sessions) typically subscribe to three events in the pipeline – AuthenticateRequest/PostAuthenticateRequest for pre-processing and EndRequest for post-processing (like making redirects to a login page).

In the pre-processing stage it is the modules’ job to determine the identity of the client based on incoming HTTP details (like a header, cookie, form post) and set HttpContext.User and Thread.CurrentPrincipal. The actual page (in the ExecuteHandler event) “sees” the identity that the last module has set.

So in our case there are three modules in effect:

• FormsAuthenticationModule (AuthenticateRequest, EndRequest)
• WSFederationAuthenticationModule (AuthenticateRequest, PostAuthenticateRequest, EndRequest)
• SessionAuthenticationModule (AuthenticateRequest, PostAuthenticateRequest)

So let’s have a look at the different scenario we have when mixing Forms auth and WS-Federation.

Anoymous request to unprotected resource
This is the easiest case. Since there is no WIF session cookie or a FormsAuth cookie, these modules do nothing. The WSFed module creates an anonymous ClaimsPrincipal and calls the registered ClaimsAuthenticationManager (if any) to transform it. The result (by default an anonymous ClaimsPrincipal) gets set.

Anonymous request to FormsAuth protected resource
This is the scenario where an anonymous user tries to access a FormsAuth protected resource for the first time. The principal is anonymous and before the page gets rendered, the Authorize attribute kicks in. The attribute determines that the user needs authentication and therefor sets a 401 status code and ends the request. Now execution jumps to the EndRequest event, where the FormsAuth module takes over. The module then converts the 401 to a redirect (302) to the forms login page.

If authentication is successful, the login page sets the FormsAuth cookie.

FormsAuth authenticated request to a FormsAuth protected resource
Now a FormsAuth cookie is present, which gets validated by the FormsAuth module. This cookie gets turned into a GenericPrincipal/FormsIdentity combination. The WS-Fed module turns the principal into a ClaimsPrincipal and calls the registered ClaimsAuthenticationManager. The outcome of that gets set on the context.

Anonymous request to STS protected resource
This time the anonymous user tries to access an STS protected resource (a controller decorated with the RequireTokenAuthentication attribute). The attribute determines that the user needs STS authentication by checking the authentication type on the current principal. If this is not Federation, the redirect to the STS will be made.

After successful authentication at the STS, the STS posts the token back to the application (using WS-Federation syntax).

Postback from STS authentication
After the postback, the WS-Fed module finds the token response and validates the contained token. If successful, the token gets transformed by the ClaimsAuthenticationManager, and the outcome is a) stored in a session cookie, and b) set on the context.

STS authenticated request to an STS protected resource
This time the WIF Session authentication module kicks in because it can find the previously issued session cookie. The module re-hydrates the ClaimsPrincipal from the cookie and sets it.

FormsAuth and STS authenticated request to a protected resource
This is kind of an odd case – e.g. the user first authenticated using Forms and after that using the STS. This time the FormsAuth module does its work, and then afterwards the session module stomps over the context with the session principal. In other words, the STS identity wins.

What about roles?
A common way to set roles in ASP.NET is to use the role manager feature. There is a corresponding HTTP module for that (RoleManagerModule) that handles PostAuthenticateRequest. Does this collide with the above combinations?

No it doesn’t! When the WS-Fed module turns existing principals into a ClaimsPrincipal (like it did with the FormsIdentity), it also checks for RolePrincipal (which is the principal type created by role manager), and turns the roles in role claims. Nice!

But as you can see in the last scenario above, this might result in unnecessary work, so I would rather recommend consolidating all role work (and other claims transformations) into the ClaimsAuthenticationManager. In there you can check for the authentication type of the incoming principal and act accordingly.

HTH

I recently had the task to find out how to mix ASP.NET Forms Authentication with WIF’s WS-Federation. The FormsAuth app did already exist, and a new sub-directory of this application should use ADFS for authentication. Minimum changes to the existing application code would be a plus ;)

Since the application is using ASP.NET MVC this was quite easy to accomplish – WebForms would be a little harder, but still doable. I will discuss the MVC solution here.

To solve this problem, I made the following changes to the standard MVC internet application template:

• Added WIF’s WSFederationAuthenticationModule and SessionAuthenticationModule to the modules section.
• Add a WIF configuration section to configure the trust with ADFS.
• Added a new authorization attribute. This attribute will go on controller that demand ADFS (or STS in general) authentication.

The attribute logic is quite simple – it checks for authenticated users – and additionally that the authentication type is set to Federation. If that’s the case all is good, if not, the redirect to the STS will be triggered.

          
            
              
                public
              
            
            
               
              
                class
              
               
              
                RequireTokenAuthenticationAttribute
              
               : 
              
                AuthorizeAttribute

              
            
          
          
            
              {

    
              
                protected
              
               
              
                override
              
               
              
                bool
              
               AuthorizeCore(
              
                HttpContextBase
              
            
            
               httpContext)

    {

        
              
                if
              
            
            
               (httpContext.User.Identity.IsAuthenticated
&&

            httpContext.User.Identity.AuthenticationType.Equals(

WIF.
              
                AuthenticationTypes
              
              .Federation, 
              
                StringComparison
              
            
            
              .OrdinalIgnoreCase))

        {

            
              
                return
              
               
              
                true
              
            
            
              ;

        }

            


        
              
                return
              
               
              
                false
              
            
            
              ;

    }


    
              
                protected
              
               
              
                override
              
               
              
                void
              
               HandleUnauthorizedRequest(
              
                AuthorizationContext
              
            
            
               filterContext)

    {            


        
              
                //
do the redirect to the STS

              
                      
              
                var
              
               message
= 
              
                FederatedAuthentication
              
              .WSFederationAuthenticationModule.CreateSignInRequest(

              
                "passive"
              
              , 


filterContext.HttpContext.Request.RawUrl, 


              
                false
              
            
          
          
            
              );

        filterContext.Result = 
              
                new
              
               
              
                RedirectResult
              
              (message.RequestUrl);

    }

}
            
          
        

That’s it ;) If you want to know why this works (and a possible gotcha) – read my next post.

I found some time over the holidays to finalize the Azure edition of IdentityServer.

http://identityserver.codeplex.com/releases/view/81206

The biggest difference to the on-premise version (and earlier Azure betas) is, that by default IdSrv now uses Azure Storage for all data storage (configuration & user data). This means that there is no need anymore for SQL Azure (which is still supported out of the box – just not the default anymore).

The download includes a readme file with setup instructions. In a nutshell:

• Create a new hosted service and upload your certificates
• Modify the service configuration file in the download to your needs (signing cert, connection strings to storage…)
• Deploy the package via the portal or other tools
• Use the new Powershell scripts to add users

If you encounter any problem, please give me feedback.

nice!

My last advice for 2011:

Get a ticket for Troopers 2012 before it is sold out.

If you like to learn about IPv6, Android, iOS, SAP or cloud security (and much more) – that’s the place to be!

see here:

http://blogs.msdn.com/b/windowsazure/archive/2011/12/20/important-announcements-regarding-the-access-control-service.aspx

Claudio Sanchez did it again! thanks!

http://claudioasanchez.blogspot.com/2011/12/walk-though-of-provisioning-identity.html

http://tinyurl.com/claimsguide2

It was brought to my attention that fedutil does not work anymore with IdSrv v1 metadata. And I can confirm that.

The reason for this bug is my recent change to the XmlWriter factory methods which have a different default behavior when it comes to encoding.

Since there were only 20 downloads so far – I fixed the bug in-place (shame on me). So when you are one of the early adopters and run into this problem – just re-download IdSrv ;)

HTH

Yeah – it is finally done. I just uploaded the v1 bits to Codeplex and the documentation to our server. Here’s the official blurb…

Thinktecture IdentityServer is an open source security token service based on Microsoft .NET, ASP.NET MVC, WCF and WIF.

High level features

• Multiple protocols support (WS-Trust, WS-Federation, OAuth2, WRAP, JSNotify, HTTP GET)
• Multiple token support (SAML 1.1/2.0, SWT)
• Out of the box integration with ASP.NET membership, roles and profile
• Support for username/password and client certificates authentication
• Support for WS-Federation metadata
• Support for WS-Trust identity delegation
• Extensibility points to customize configuration and user management handling

Disclaimer
I did thorough testing of all features of IdentityServer - but keep in mind that this is an open source project and I am the only architect, developer and tester on the team.
IdentityServer also lacks many of the enterprise-level features like configuration services, proxy support, operations integration etc.
I only recommend using IdentityServer if you also understand how it works (to be able to support it). I am offering consulting to help you with customization and lock down - contact me.

Download. Documentation.

Up next is v1 of the Azure version. Have fun!

Sam Huggill wrote a great post on how to get StarterSTS working on IIS 6.

Thanks Sam!

In the previous post I showed how token based authentication can be implemented for WCF HTTP based services.

Authentication is the process of finding out who the user is – this includes anonymous users. Then it is up to the service to decide under which circumstances the client has access to the service as a whole or individual operations. This is called authorization.

By default – my framework does not allow anonymous users and will deny access right in the service authorization manager. You can however turn anonymous access on – that means technically, that instead of denying access, an anonymous principal is placed on Thread.CurrentPrincipal. You can flip that switch in the configuration class that you can pass into the service host/factory.

          
            
              
                var
              
            
            
               configuration
= 
              
                new
              
               
              
                WebTokenWebServiceHostConfiguration

              
            
          
          
            
              {

    AllowAnonymousAccess = 
              
                true

              
              }; 
            
          
        

But this is not enough, in addition you also need to decorate the individual operations to allow anonymous access as well, e.g.:

          
            
              [
            
            
              
                AllowAnonymousAccess
              
            
          
          
            
              ]

              
                public
              
               
              
                string
              
            
          
          
            
               GetInfo()

{

    ...

              } 
            
          
        

Inside these operations you might have an authenticated or an anonymous principal on Thread.CurrentPrincipal, and it is up to your code to decide what to do.

Side note: Being a security guy, I like this opt-in approach to anonymous access much better that all those opt-out approaches out there (like the Authorize attribute – or this.).

Claims-based Authorization
Since there is a ClaimsPrincipal available, you can use the standard WIF claims authorization manager infrastructure – either declaratively via ClaimsPrincipalPermission or programmatically (see also here).

          
            
              [
            
            
              
                ClaimsPrincipalPermission
              
              (
              
                SecurityAction
              
            
          
          
            
              .Demand, 


    Resource = 
              
                "Claims"
              
            
            
              ,

    Operation = 
              
                "View"
              
            
            
              )]

              
                public
              
               
              
                ViewClaims
              
            
          
          
            
               GetClientIdentity()

{

    
              
                return
              
               
              
                new
              
               
              
                ServiceLogic
              
              ().GetClaims();

}
            
          
        

In addition you can also turn off per-request authorization (see here for background) via the config and just use the “domain specific” instrumentation.

While the code is not 100% done – you can download the current solution here.

HTH

(Wanna learn more about federation, WIF, claims, tokens etc.? Click here.)

If you wondered how a client would have to look like to work with the authentication framework, it is pretty straightfoward:

1. Request a token
2. Put that token on the authorization header (along with a registered scheme) and make the service call

e.g.:

          
            
              
                var
              
            
            
               oauth2
= 
              
                new
              
               
              
                OAuth2Client
              
            
          
          
            
              (_oauth2Address);

              
                var
              
               swt
= oauth2.RequestAccessToken(

              
                 "username"
              
              , 
              
                "password"
              
              ,
_baseAddress.AbsoluteUri);
            
          
        

          
            
              
                var
              
            
            
               client
= 
              
                new
              
               
              
                HttpClient
              
            
          
          
            
               {
BaseAddress = _baseAddress };

client.DefaultRequestHeaders.Authorization = 


              
                new
              
               
              
                AuthenticationHeaderValue
              
              (
              
                "Bearer"
              
            
          
          
            
              ,
swt); 


              
                var
              
               response
= client.Get(
              
                "identity"
              
              );

response.EnsureSuccessStatusCode();
            
          
        

HTH

This post shows some of the implementation techniques for adding token and claims based security to HTTP/REST services written with WCF. For the theoretical background, see my previous post.

Disclaimer
The framework I am using/building here is not the only possible approach to tackle the problem. Based on customer feedback and requirements the code has gone through several iterations to a point where we think it is ready to handle most of the situations.

Goals and requirements

• The framework should be able to handle typical scenarios like username/password based authentication, as well as token based authentication
• The framework should allow adding new supported token types
• Should work with WCF web programming model either self-host or IIS hosted
• Service code can rely on an IClaimsPrincipal on Thread.CurrentPrincipal that describes the client using claims-based identity

Implementation overview
In WCF the main extensibility point for this kind of security work is the ServiceAuthorizationManager. It gets invoked early enough in the pipeline, has access to the HTTP protocol details of the incoming request and can set Thread.CurrentPrincipal. The job of the SAM is simple:

1. Check the Authorization header of the incoming HTTP request
2. Check if a “registered” token (more on that later) is present
3. If yes, validate the token using a security token handler, create the claims principal (including claims transformation) and set Thread.CurrentPrincipal
4. If no, set an anonymous principal on Thread.CurrentPrincipal. By default, anonymous principals are denied access – so the request ends here with a 401 (more on that later).

To wire up the custom authorization manager you need a custom service host – which in turn needs a custom service host factory. The full object model looks like this:

Token handling
A nice piece of existing WIF infrastructure are security token handlers. Their job is to serialize a received security token into a CLR representation, validate the token and turn the token into claims.

The way this works with WS-Security based services is that WIF passes the name/namespace of the incoming token to WIF’s security token handler collection. This in turn finds out which token handler can deal with the token and returns the right instances.

For HTTP based services we can do something very similar. The scheme on the Authorization header gives the service a hint how to deal with an incoming token. So the only missing link is a way to associate a token handler (or multiple token handlers) with a scheme and we are (almost) done.

WIF already includes token handler for a variety of tokens like username/password or SAML 1.1/2.0. The accompanying sample has a implementation for a Simple Web Token (SWT) token handler, and as soon as JSON Web Token are ready, simply adding a corresponding token handler will add support for this token type, too.

All supported schemes/token types are organized in a WebSecurityTokenHandlerCollectionManager and passed into the host factory/host/authorization manager.

Adding support for basic authentication against a membership provider would e.g. look like this (in global.asax):

          
            
              
                var
              
            
            
               manager
= 
              
                new
              
               
              
                WebSecurityTokenHandlerCollectionManager
              
            
          
          
            
              ();

            
          
        

          
            
              
                

manager.AddBasicAuthenticationHandler((username, password) => 


              
                Membership
              
              .ValidateUser(username,
password));
            
          
        

Adding support for Simple Web Tokens with a scheme of Bearer (the current OAuth2 scheme) requires passing in a issuer, audience and signature verification key:

          
            
              manager.AddSimpleWebTokenHandler(

    
            
            
              
                "Bearer"
              
            
          
          
            
              ,

    
              
                "http://identityserver.thinktecture.com/trust/initial"
              
            
            
              ,

    
              
                "https://roadie/webservicesecurity/rest/"
              
            
          
          
            
              ,

    
              
                "WFD7i8XRHsrUPEdwSisdHoHy08W3lM16Bk6SCT8ht6A="
              
              );
            
          
        

In some situations, SAML token may be used as well. The following configures SAML support for a token coming from ADFS2:

          
            
              
                var
              
            
            
               registry
= 
              
                new
              
               
              
                ConfigurationBasedIssuerNameRegistry
              
            
          
          
            
              ();

registry.AddTrustedIssuer(

              
                 "d1 c5 b1 25 97 d0 36 94 65 1c
e2 64 fe 48 06 01 35 f7 bd db"
              
              , 
              
                "ADFS"
              
            
            
              ); 
              
                var
              
               adfsConfig
= 
              
                new
              
               
              
                SecurityTokenHandlerConfiguration
              
            
            
              ();

adfsConfig.AudienceRestriction.AllowedAudienceUris.Add(

              
                new
              
               
              
                Uri
              
              (
              
                "https://roadie/webservicesecurity/rest/"
              
            
            
              ));

adfsConfig.IssuerNameRegistry = registry;

adfsConfig.CertificateValidator = 
              
                X509CertificateValidator
              
            
            
              .None; 
              
                //
token decryption (read from config)
              
              adfsConfig.ServiceTokenResolver
= 


              
                IdentityModelConfiguration
              
            
          
          
            
              .ServiceConfiguration.CreateAggregateTokenResolver();             


manager.AddSaml11SecurityTokenHandler(
              
                "SAML"
              
              ,
adfsConfig);
            
          
        

Transformation
The custom authorization manager will also try to invoke a configured claims authentication manager. This means that the standard WIF claims transformation logic can be used here as well. And even better, can be also shared with e.g. a “surrounding” web application.

Error handling
A WCF error handler takes care of turning “access denied” faults into 401 status codes and a message inspector adds the registered authentication schemes to the outgoing WWW-Authenticate header when a 401 occurs.

The next post will conclude with authorization as well as the source code download.

(Wanna learn more about federation, WIF, claims, tokens etc.? Click here.)

WIF as it exists today is optimized for web applications (passive/WS-Federation) and SOAP based services (active/WS-Trust). While there is limited support for WCF WebServiceHost based services (for standard credential types like Windows and Basic), there is no ready to use plumbing for RESTful services that do authentication based on tokens.

This is not an oversight from the WIF team, but the REST services security world is currently rapidly changing – and that’s by design. There are a number of intermediate solutions, emerging protocols and token types, as well as some already deprecatedones. So it didn’t make sense to bake that into the core feature set of WIF.

But after all, the F in WIF stands for Foundation. So just like the WIF APIs integrate tokens and claims into other hosts, this is also (easily) possible with RESTful services. Here’s how.

HTTP Services and Authentication
Unlike SOAP services, in the REST world there is no (over) specified security framework like WS-Security. Instead standard HTTP means are used to transmit credentials and SSL is used to secure the transport and data in transit.

For most cases the HTTP Authorize header is used to transmit the security token (this can be as simple as a username/password up to issued tokens of some sort). The Authorize header consists of the actual credential (consider this opaque from a transport perspective) as well as a scheme. The scheme is some string that gives the service a hint what type of credential was used (e.g. Basic for basic authentication credentials). HTTP also includes a way to advertise the right credential type back to the client, for this the WWW-Authenticate response header is used.

So for token based authentication, the service would simply need to read the incoming Authorization header, extract the token, parse and validate it. After the token has been validated, you also typically want some sort of client identity representation based on the incoming token. This is regardless of how technology-wise the actual service was built. In ASP.NET (MVC) you could use an HttpModule or an ActionFilter. In (todays) WCF, you would use the ServiceAuthorizationManager infrastructure. The nice thing about using WCF’ native extensibility points is that you get self-hosting for free.

This is where WIF comes into play. WIF has ready to use infrastructure built-in that just need to be plugged into the corresponding hosting environment:

• Representation of identity based on claims. This is a very natural way of translating a security token (and again I mean this in the widest sense – could be also a username/password) into something our applications can work with.
• Infrastructure to convert tokens into claims (called security token handler)
• Claims transformation
• Claims-based authorization

So much for the theory. In the next post I will show you how to implement that for WCF – including full source code and samples.

(Wanna learn more about federation, WIF, claims, tokens etc.? Click here.)

I spend numerous hours every month answering questions about WIF and identity in general. This made me realize that this is still quite a complicated topic once you go beyond the standard fedutil stuff.

My good friend Brock and I put together a two day training course about WIF that covers everything we think is important. The course includes extensive lab material where you take standard application and apply all kinds of claims and federation techniques and technologies like WS-Federation, WS-Trust, session management, delegation, home realm discovery, multiple identity providers, Access Control Service, REST, SWT and OAuth. The lab also includes the latest version of the thinktecture identityserver and you will learn how to use and customize it.

If you are looking for an open enrollment style of training, have a look here or here. Or contact me directly!

The course outline looks as follows:

Day 1
Intro to Claims-based Identity & the Windows Identity Foundation
WIF introduces important concepts like conversion of security tokens and credentials to claims, claims transformation and claims-based authorization. In this module you will learn the basics of the WIF programming model and how WIF integrates into existing .NET code.

Externalizing Authentication for Web Applications
WIF includes support for the WS-Federation protocol. This protocol allows separating business and authentication logic into separate (distributed) applications. The authentication part is called identity provider or in more general terms - a security token service. This module looks at this scenario both from an application and identity provider point of view and walks you through the necessary concepts to centralize application login logic both using a standard product like Active Directory Federation Services as well as a custom token service using WIF’s API support.

Externalizing Authentication for SOAP Services
One big benefit of WIF is that it unifies the security programming model for ASP.NET and WCF. In the spirit of the preceding modules, we will have a look at how WIF integrates into the (SOAP) web service world. You will learn how to separate authentication into a separate service using the WS-Trust protocol and how WIF can simplify the WCF security model and extensibility API.

Day 2
Advanced Topics:  Security Token Service Architecture, Delegation and Federation
The preceding modules covered the 80/20 cases of WIF in combination with ASP.NET and WCF. In many scenarios this is just the tip of the iceberg. Especially when two business partners decide to federate, you usually have to deal with multiple token services and their implications in application design. Identity delegation is a feature that allows transporting the client identity over a chain of service invocations to make authorization decisions over multiple hops. In addition you will learn about the principal architecture of a STS, how to customize the one that comes with this training course, as well as how to build your own.

Outsourcing Authentication:  Windows Azure & the Azure AppFabric Access Control Service
Microsoft provides a multi-tenant security token service as part of the Azure platform cloud offering. This is an interesting product because it allows to outsource vital infrastructure services to a managed environment that guarantees uptime and scalability. Another advantage of the Access Control Service is, that it allows easy integration of both the “enterprise” protocols like WS-* as well as “web identities” like LiveID, Google or Facebook into your applications. ACS acts as a protocol bridge in this case where the application developer doesn’t need to implement all these protocols, but simply uses a service to make it happen.

Claims & Federation for the Web and Mobile World
Also the web & mobile world moves to a token and claims-based model. While the mechanics are almost identical, other protocols and token types are used to achieve better HTTP (REST) and JavaScript integration for in-browser applications and small footprint devices. Also patterns like how to allow third party applications to work with your data without having to disclose your credentials are important concepts in these application types. The nice thing about WIF and its powerful base APIs and abstractions is that it can shield application logic from these details while you can focus on implementing the actual application.

HTH

ADFS uses SSL extended protection which made observing traffic with Fiddler harder to impossible.

Fortunately, this can be fixed – Eric Lawrence writes about it here.

I just uploaded a new version of the sample relying party. The three changes are:

• Added a session token diagnostics page. This allows to look at cookie sizes, details and the raw contents
• Sample code to switch to session mode
• Sample code to implement sliding expiration

This was already included since 1.0:

• WS-Federation example
• Claims viewer
• Token viewer
• Active sign in via WS-Trust
• Delegation

HTH

To make it short: to switch to SessionMode (cache to server) in ASP.NET, you need to handle an event and set a property. Sounds easy – but you need to set it in the right place.

The most popular blog post about this topic is from Vittorio. He advises to set IsSessionMode in WSFederationAuthenticationModule_SessionSecurityTokenCreated.

Now there were some open questions on forum, like this one. So I decided to try it myself – and indeed it didn’t work for me as well. So I digged a little deeper, and after some trial and error I found the right place (in global.asax):

          
            
              
                void
              
            
            
               WSFederationAuthenticationModule_SecurityTokenValidated(

              
                object
              
               sender, 
              
                SecurityTokenValidatedEventArgs
              
            
          
          
            
               e)

{

    
              
                FederatedAuthentication
              
              .SessionAuthenticationModule.IsSessionMode
= 
              
                true
              
              ; 


              }
            
          
        

Not sure if anything has changed since Vittorio’s post – but this worked for me.

While playing around, I also wrote a little diagnostics tool that allows you to look into the session cookie (for educational purposes). Will post that soon.

HTH

This fell through the cracks over the summer holiday time:

The 2nd edition of the Patterns & Practices “claims guide” has been released. This is excellent!

We added a lot of content around ADFS, Access Control Service, REST and SharePoint. All source code is available as well!

Grab it from: http://msdn.microsoft.com/en-us/library/ff423674.aspx

Or use my vanity URL: http://tinyurl.com/claimsguide

Brian has posted a great walkthrough on how to setup idsrv in conjunction with SharePoint. Thanks!

http://sharepintblog.com/2011/10/23/sharepoint-claims-based-authentication-with-thinktecture-identity-server-walkthrough/

I just uploaded the RC of IdentityServer to Codeplex.

This release is feature complete and if I don’t get any bug reports this is also pretty much the final V1.

Changes from B1

• The configuration data access is now based on EF 4.1 code first. This makes it much easier to use different data stores. For RTM I will also provide a SQL script for SQL Server so you can move the configuration to a separate machine (e.g. for load balancing scenarios).
• I included the ASP.NET Universal Providers in the download. This adds official support for SQL Azure, SQL Server and SQL Compact for the membership, roles and profile features. Unfortunately the Universal Provider use a different schema than the original ASP.NET providers (that sucks btw!) – so I made them optional. If you want to use them go to web.config and uncomment the new provider.
• The relying party registration entries now have added fields to add extra data that you want to couple with the RP. One use case could be to give the UI a hint how the login experience should look like per RP. This allows to have a different look and feel for different relying parties. I also included a small helper API that you can use to retrieve the RP record based on the incoming WS-Federation query string.
• WS-Federation single sign out is now conforming to the spec.
• Certificate based endpoint identities for SSL endpoints are optional now.
• Added a initial configuration “wizard”. This sets up the signing certificate, issuer URI and site title on the first run.

Installation

This is still a “developer” release – that means it ships with source code that you have to build it etc. But from that point it should be a little more straightforward as it used to be:

• Make sure SSL is configured correctly for IIS
• Map the WebSite directory to a vdir in IIS
• Run the web site. This should bring up the initial configuration
• Make sure the worker process account has access to the signing certificate private key
• Make sure all your users are in the “IdentityServerUsers” role in your role store. Administrators need the “IdentityServerAdministrators” role

That should be it. A proper documentation will be hopefully available soon (any volunteers?).

Please provide feedback! thanks!

I got asked today if I could publish a roadmap for thinktecture IdentityServer (idrsv in short).

Well – I got a lot of feedback after B1 and one of the biggest points here was the data access layer. So I made two changes:

• I moved to configuration database access code to EF 4.1 code first. That makes it much easier to change the underlying database. So it is now just a matter of changing the connection string to use real SQL Server instead of SQL Compact. Important when you plan to do scale out.
• I included the ASP.NET Universal Providers in the download. This adds official support for SQL Azure, SQL Server and SQL Compact for the membership, roles and profile features. Unfortunately the Universal Provider use a different schema than the original ASP.NET providers (that sucks btw!) – so I made them optional. If you want to use them go to web.config and uncomment the new provider.

Then there are some other small changes:

• The relying party registration entries now have added fields to add extra data that you want to couple with the RP. One use case could be to give the UI a hint how the login experience should look like per RP. This allows to have a different look and feel for different relying parties. I also included a small helper API that you can use to retrieve the RP record based on the incoming WS-Federation query string.
• WS-Federation single sign out is now conforming to the spec.
• I made certificate based endpoint identities for SSL endpoints optional. This caused some problems with configuration and versioning of existing clients.

I hope I can release the RC in the next days. If there are no major issues, there will be RTM very soon!

Claudio Sanchez has created a little walkthrough for installing IdentityServer. While he uses B1 refresh, I anticipate no changes for RTM (which is sitting here on my hard drive almost ready for publishing).

Thanks Claudio!

• WindowsIdentity, FormsIdentity and GenericIdentity now derive from ClaimsIdentity
• WindowsIdentity.GetCurrent() converts Windows token details (groups for the current Windows versions) to claims.
• Claims for Windows identities now distinguish between user claims and device claims (Windows 8 feature)
• WCF now populates Thread.CurrentPrincipal with a ClaimsPrincipal derived type

• System.Security.Claims has ClaimsIdentity & ClaimsPrincipal
• IClaimsIdentity & IClaimsPrincipal are gone. The classes implement IIdentity & IPrincipal now directly
• All the token handler and low level plumbing is now in System.IdentityModel

There was not a ton of new information about WIF and related technologies at Build, but Samuel Devasahayam did a great talk about claims-based access control that contained some very interesting bits of information with regards to future directions.

From his slides:

Windows 8

• Bring existing identity claims model into the Windows platform
• Domain controller issues groups & claims
• Claims (user and device) sourced from identity attributes in AD
• Claims delivered in Kerberos PAC
• NT Token has a new claims section
• Enhanced SDDL API’s to work with claims
• Enhanced user mode CheckAccess API’s to work with claims
• New ACL-UX
• Target audits with claims-based expressions

WIF & .NET 4.5

• WIF is in the box with .NET Framework 4.5
• Every principal in .NET 4.5 is a ClaimsPrincipal

ADFS 2.1

• ADFS 2.1 is available now as a in-box server role in Windows 8
• Adds support for issuing device claims from Kerberos ticket

I uploaded a sample RP for IdentityServer. It shows some basic things like connecting a web application via WS-Federation and a SOAP service via WS-Trust.

Ingo Rammer
Hardcore Production Debugging
HTML5 - Offline Business Applications for Desktops, Tablets and Phones

Oliver Sturm
Functional Programming in C#
Function Programming in F#

Dominick Baier
Architecting Claims-aware Applications (with the Windows Identity Foundation and Active Directory Federation Services)
Securing REST-Services and Web-APIs

Seems to be radio week this week…

Another interview I did quite a while ago with Michele and Patrick…

http://www.lockdownpodcast.com/default.aspx?ShowNum=4