Architecting Cloud Applications for the Enterprise – Part IV - SuperCloudySoftware sketches IssueTracker Enterprise Edition

  • Article

In the previous article, we explored the challenges of building services for an enterprise, illustrating those through a dialogue between VeryBigCorp CIO and a team from SuperCloudySoftware.

VBC requirements can be summarized as:

  1. Identity integration (including Single Sign On and management of access policies)
  2. Management integration (ability to monitor and act on IssueTracker from within VBC’s management environment)
  3. Application integration (ability to call IssueTracker programmatically from other VBC’s applications)

Let’s start with the beginning and explore the Authentication and Authorization aspects of IssueTracker. 

In its current release, IssueTracker’s approach for user AuthN and AuthZ is straightforward username + passwords, and a user profile associated with it. This works ok for very small organizations (or even bigger organizations with a few people using it) but breaks quickly for companies like VeryBigCorp for many reasons:

  1. People forget passwords and VeryBigCorp’s help desks would add a new task of resetting credentials.
  2. People need to be retrained into new procedures. ( “For IssueTracker password reset, please press 23” )
  3. People get fired from VeryBigCorp’s and can the log on to the system from their homes and “creatively edit” the company’s information.
  4. VeryBigCorp’s wants a seamless experience for their users (no pop-up, no login, nothing). It should just work.

Besides, VeryBigCorp already has a user repository (maybe more than one?) and they already have problems provisioning new users on it (them) when they hire new employees, etc. Adding a new repository for just 1 app is not going to happen.

The team @ SuperCloudySoftware considers one option:

  • Synchronizing VBC existing user repository with IssueTracker’s. This certainly can be done but is too ad-hoc, complex, cumbersome, error prone, non-standard. it wouldn’t work with other Customers and SuperCloudySoftware would much rather build one solution for all, and not treat each case as an exception. 

A better solution is to use claims and federated identity. This allows the service to rely on somebody else that it trusts to authenticate users (VeryBigCorp) and deal with an abstracted set of facts (claims) about the requestor that are used for authorization.

Fortunately, the team went to Microsoft PDC last year and learnt about some technologies that would be very appropriate for these scenario: Geneva Framework and .NET Services Access Control Service and do all the heavy lifting of setting up federation and dealing with claims:

image

In this architecture the web site (IssueTracker) defines a set of claims that are required to access its resources, for example perform certain operation such as "Create a Project”, “Delete an Issue”, etc. Whoever brings those claims will be allowed to access the resource (e.g. complete the operation). If you don’t provide the claims, then you would get “access denied”. Claims can be obtained from a  trusted issuer (VeryBigCorp’s identity provider such as Active Directory).

Simple analogy: This is like going to a bar and providing the bartender with a valid ID that will attest to your age. The resource is the beer, the claim is your age, the issuer is the government department that gave you the ID, the rule is “beer is fine if you are > 21 years old” (in the US)

Now, each company will attest to different facts about its users (like their name, which organization they work for, who is their manager, where they are located, etc.). These facts are irrelevant for IssueTracker, so some sort of mapping the original claims to those understood by IssueTracker needs to happen.

The translator allows VeryBigCorp to define rules of access. For example, they might say:

  • “Any employee who is a Program Manager will be able to Create New Projects in IssueTracker”

This implies taking the “being a member of the Program Manager group” claim and transform it into a “Create New Project” claim. Other organizations might have completely different rules and IssueTracker wouldn’t care as long as what it receives is something it understands.

That’s what Access Control Service is used for: convert claims from different issuers into others.

Following the bar analogy: the resource is the beer, the claim is your age, but instead of the bartender having to verify all sorts of different issuers of claims (passports, driving licenses, birth certificates, identity cards, etc), you simply put a guy in the door that verifies that and then gives you a colored bracelet. The rule for the bartender becomes: “anyone with a colored bracelet can have beer”. How you obtain it is someone else’s responsibility (hint: bribe the guy in the door :-) ).

This solution is actually very scalable and has a nice bonus: Access Control Service is already federated with a very popular identity provider like LiveID. So, by implementing this, SuperCloudySoftware has a LiveID enabled website for its smaller Customers for “free”.

The other nice thing is that this works with both Web Sites and Web Services (the so called “passive” and “active” profiles). So If IssueTracker exposes an API instead of a human readable web page, the same principles (and almost the same implementation) applies.

Note: IssueTracker has an API because of requirement #2 of veryBigCorp –> being able to integrate with other systems.

This is exactly what SuperCloudySoftware implemented and if you are curious about the details, then download the code and check for yourself!

I’ll expand on the implementation details in the next articles.

P.S.: if you want to learn more about claims, federation and identity “theory” in general  (including the alcoholic analogy :-)) then you should bookmark and read from il Maestro Vittorio Bertocci.

Updates: fixed a few typos.