Saturday, 17 November 2012

Claims Explained

Service Provider, Relying Party, Identity Provider, Signature, Key-Exchange, Certificate, Token, Claim, Proxy...

Yes, these abstract terms are the lingo to describe the applications and elements involved in Claims Authentication and Authorisation.

Why claims?.. Claims help us reduce the overheads of identity management by providing a central point for user and role administration (Single Sign On). This administration can be shipped to a 3rd party (Facebook, Google and Microsoft) or simplify the centralisation of user provision in the enterprise. Claims is especially important for the web as it enables this process to happen over physical organisational boundaries. This is very relevant, especially as our corporate applications are stretched into the cloud.

To help demystify these terms you need to understand the holistic picture. Claims is, in simple terms an access control mechanism which relies on a 3rd party to provide your application with user access control (authentication) and (potentially) roles (authorisation - claims).

The terms are somewhat obtuse to their use and here is where I attempt to debunk the myths..

Service Provider and Relying Party (Microsoft) are one of the same.. It is *your * 3rd party application. The consumer of the claim (Identity).

Identity Provider (IDP), is where you want to login (authenticate) and receive claims (roles, attributes). This is someone who has a token service (STS) wrapped around the login mechanism.

Tokens?? No, not a buy one get one free. A token is an exchanged set of data in a specific format which occurs from the identity provider and *your* application after authentication. This token may include claims (roles, attributes) and is digitally signed (secure). The most common form of token for federated claims is SAML, a SAML token is the response to an authentication request. SAML is usually wrapped around a protocol such as WS-Trust or WS-Federation.

A claims process starts from one of 2 methods... The first via direct URL browsing to the source site (and subsequent STS redirection), the other to the identity provider proxy address. Once an endpoint is reached, the authentication process starts, this can equate to several browser level redirects (as the IDP is reached) and ultimately a login dialogue from the IDP STS. Once authenticated, the STS will generate a signed token using the public key provided as part of the trusted key-exchange.

Keys - Cryptographic keys are a fundamental part of the claims architecture. In order for applications to secure the process a trust must be established. This is usually achieved by the provision and configuration of cryptographic keys. With these keys exchanged and configured at the STS the digital signature of the token can be reliably validated.

Once you've shared keys, configured endpoints and managed to get the access control mechanism working you should have reliable receipt of claims. So how do you bake this into your application?

There are several online claims based Frameworks and depending on your architectural requirements will depend on choice. Two of the most common in the .NET space are Windows Identity Foundation and DotNetOpenAuth. WIF is more aligned to the MS LDAP ADFS mechanisms and DotNetOpenAuth makes use of OpenID to provide authentication.

Claims is only complex due to the abstract language used to provide a description to terms you've used for years.. The redirection process is somewhat cumbersome and difficult to grasp especially chained trusts, but do not confuse the fact that, at the end of the day your users are receiving authentication and roles from a central place for all applications.

In my next post I will provide a tutorial for configuring ADFS with a WIF enabled application. I will also map custom attributes into the token to ensure backwards compatibility for existing applications moving to an single sign on architecture.

Thursday, 15 November 2012

Windows Clustering in Virtual Environments

Clustering in virtual environments is often something that is misunderstood, virtualisation provides many high-availability benefits out of the box but falls short under some conditions.  When you are next considering high-availability in a virtual environment ask yourself the following:-

  • What happens if I have an OS failure?
  • What happens if I want to do an online upgrade/patch?
  • In the case of SQL 2012, how will you auto failover your availability group?
These kind of things can be often overlooked in an age where the OS is more stable and the NT 4 failures of old become a thing of the past.  SQL 2012 does not support auto failover without a quorum and this will give you a headache in a virtual environment.

Ha, ha I hear you say, I have snapshots!!! A snap-shot will not help you reduce downtime.  Restoring or rolling back a snapshot takes time, this is critical time for 24/7/365 businesses and sometimes is not an option.  Snapshots also have an overhead in the differing management.  When relying on snapshots, in an upgrade scenario, you will need downtime whilst applying that critical update if you do not have a secondary node.  This might not make users happy.

These kinds of questions are still difficult to resolve and are actually harder today than in the bare metal days of the past.  The support of MSCS in a virtual environment is a quagmire of support matricies and conditions.  You will need to ensure that the Hypervisor is limiting its resource interaction and that iSCSI is your quorum disk.  There are other options but this is the most common scenario.  Unless you are on Hyper-V of course..

So don't avoid clusters in a virtual environment, understand the business requirement and leave nothing to chance!  Clustering still has its place today for obvious reasons, don't be told otherwise.

If you are planning clustering on vSphere and rely on MS support, please fully understand that Microsoft support are fussy.  You'll need to have followed the following to the letter of the law.

Me, Me, Me

So I have decided to get back into blogging. It seems in this day and age you need to have more than a CV. With the marketplace becoming more and more competative you need an edge.

This edge can come in multiple ways but generally it should come in capital "real" knowledge in a chosen subject area. This subject area needs to be something you "love", something you are willing to burn the midnight oil for.

For me Technology, Agile and Systems theory is something I love. Especially the application of system theory in software development. Being able to turn an organisation around by applying empirical disciplines and lean thinking is an enlightening journey. Getting senior "buy in" to take that journey to engaged software delivery is something everyone should experience. Once you have worked with good, engaged stakeholders you very rarely will want to go back to formal methods.

Now that I have decided to get back on the blogger band-wagon I will do my upmost to stay on track. This is my commitment to you and in return all I ask for is for you to point out my mistakes, correct my spellings and have fun. At the moment I am working on an Enterprise grade .NET and SharePoint application. We are using OData REST, ASP.NET MVC 4, Knockout.js, Sammy.js, K2 SmartForms and Workflow. This is all hooking into a SharePoint portal. We hope to go live on SharePoint 2013 but those decisions are still to be made.

Thanks for joining me on the start of my blogging journey. Hopefully I will be able to write about things people find of interest and improve my writing style in the process.