Identity thoughts #2: Level 2 Authorization

In my last post I talked about an identity roadmap and how we are helping companies to achieve Level 1: Externalizing Authentication. In this first level, we only care about checking the credentials of a user in a Security Token Service and issue a token with a couple of claims. That token will be enough to prove access to the application.

Reaching the Level 1 will make a great difference to the IT department of a given company. By having a central login place they will be able to answer to questions like “when someone logged in to a certain application?”, “which applications someone used in this timeframe?”, etc. In terms of governance, having a single way to implement login will allow the architecture department (if any) to decrease security threats because there is a single well thought piece of infrastructure to perform user authentication across all apps. As a side effect it will also reduce costs of development and maintenance.

Level 2 talks about the authorization process. The authorization decision happens near the application or the service because it knows about the resource (each application has a different domain model).

Geneva Server – Level 1 Authentication

  • SSO & Federation – unified login experience and federation with partners
  • Centralized Claim Mapping management
  • Externalize authentication
  • Near the identity provider
  • Questions it will answer
    • When a subject logged in to an app?
    • What claims the subject presented to the app?

Policy Server  - Level 2 Authorization

  • Policy Enforcement
  • Centralized Policy Rules management
  • Externalize authorization
  • Near the application
  • Questions it will answer
    • What permissions did the subject requested?
    • What permissions where denied?

The following figure shows a very high level architecture of the components and its interactions



[Geneva Server]

Published: June 17 2009

blog comments powered by Disqus