Disclaimer: this post and the next ones are early drafts to share with you the direction we are taking. They might (and I hope they will) change quite a bit in the actual Guide! We might end up not covering one of these scenarios in the book. These posts represent my ideas and not those of my employer, my colleagues, friends, enemies, associates, pets. Read this at your own risk, got it? :-).
The themes for our first “enterprise” scenario are:
- Intranet and extranet Web SSO
- Using claims for user profile information
- RBAC with Claims
- Single Sign Off
- Single company
- No federation
Variations in the scenario:
- Hosting on Windows Azure
The introduction
Adatum is a medium company that uses Active Directory to authenticate its employees.
John, is a salesman @ Adatum. He uses a-Order, Adatum’s order processing system to enter, process, track and manage customer orders. John also uses a-Expense, an expense tracking and reimbursement system to enter his business related expenses.
Both are built with ASP.NET 3.5 and deployed in Adatum’s datacenter.
a-Order uses Windows integrated authentication. When John uses a Windows domain joined machine, a-Order recognizes the same credentials he used for login on his PC. He’s never prompted for username and password. a-Order user roles are stored in the company’s Active Directory.
a-Expense on the other hand uses a custom authentication, authorization and user profile information. All these data is stored in custom tables in a SQL Server database. John is normally prompted for username and password whenever he uses this application.
a-Expense AuthZ rules are tied to a user name and it’s deeply integrated into the application business logic at all levels (e.g. inside pages, code, stored procedures, etc). It is also something that belongs to the app itself. That is, the roles and information stored in a-Expense doesn’t exist anywhere else in Adatum.
a-Expense was initially used by a handful of employees and over the years, as Adatum grew, it was used by more and more employees. Maintaining the user database (e.g new hires, retiring users, etc) is a cumbersome process and it is not well integrated into Adatum’s existing processes for managing employee accounts.
Some information about the employees using a-Expense does exist somewhere else and needs to the replicated. For example: the “Cost Center” an employee belongs to, is already stored in the corporate AD. Updating Cost Center information in a-Expense is a difficult, error prone process as it is completely manual (each employee has to update its own Cost Center in his profile). Other user preferences (e.g. the reimbursement method: check, direct deposit, cash, etc) is something private to a-Expense.
John as most sales people in Adatum are mobile, often on the road visiting customers. Adatum wants to offer all sales staff the ability to use both applications from anywhere they are, not just its Corpnet (e.g. working from Home, connecting through WiFi access points, etc).
Adatum has many other departmental applications like a-Expense (e.g. a-Vacation, a-Facilities) that are not part of core corporate IT (e.g they have their own user, role and profile databases). Some of these applications are Windows based and others are not. Small applications like this appear all the time.
These apps might not be critical in isolation, but together they add up.
Adatum IT Dept is considering moving some of these applications to “the cloud” to decrease CAPEX and simplify management.
Adatum has also received requests from partners to access their systems. Especially a-Order. Adatum’s customers want to be able to track their orders on Adatum’s system.
What does Adatum want?
Adatum wants to avoid keeping a username/password just for a-Expense. They want their employees to use the same credentials they use to log on on their desktops.
Adatum also wants a standards based solution that works with multiple platforms and vendors.
Adatum also wants to eliminate common user profile information that needs to be replicated and maintained between multiple repositories (e.g. the Cost Center) where possible
Adatum wants secure internet access for its employees to their systems.
Adatum has big plans in the future. They want to lay the foundation for more advanced scenarios (like providing access to their Customers to other systems, like a-Order).
They also want an architecture that would allow them to easily move some applications to “the cloud” (Windows Azure in particular), and decrease management and CAPEX costs.
What is conceptual solution we propose?
We’ll do some forward looking in this scenario, and we’ll make some decisions considering the things we want to achieve in the future
We’ll solve these in multiple steps.
First we’ll introduce an Identity Provider (IP) in the organization. In general we want applications to trust this IP to authenticate its users. In Adatum, an “employee” is a “corporate asset”. No application should keep a custom employee database. It might not be realistic to move all applications initially to use an IP, but for now we just care about a-Expense and a-Order.
This IP will authenticate users and also return common, company wide user information such as the name, the e-mail, the employee cost center, the office number, his phone, etc.
This information is already in AD. We are not requiring (or even suggesting) to change the schema of AD for the needs of any specific application. We are just reusing what’s in there already.
Therefore, some applications will still keep other user profile information that will not be moved to the corporate IP. We want to avoid polluting AD with app specific attributes, we want to keep management decentralized, etc.
We’ll modify a-Order to use IClaimsPrincipal as opposed to IPrincipal and simply return the AD groups as claims. This is in preparation for opening a-Order to external Partners of Adatum later.
a-Expense will continue to use its own application specific roles database associated with the users, but will discontinue to use the user database as authentication is moved to the IP.
Aha! I got you!
At this point, the smart reader could say: what a minute! why all this? Shouldn’t I just enable Windows Authentication in a-Expense? That will give me SSO and it is much much simpler than deploying an IP, issuing claims, configuring the application, etc.
The answer is yes! If that’s all you need, by all means do that. But consider these:
- This is our first step in a longer journey. We are simplifying things and slightly (we hope) over-complicating others in preparation for other requirements. An investment so to say. (e.g. Customers using a-Order later on)
- Even now, we want more than just SSO. We want also the ability to move a-Expense to Windows Azure for instance. Windows Authentication is not an option there. |
In this first stage then we propose:
Adatum wanted to enable John to work from home. One option is to simply publish the apps and the IP on the internet (probably with some firewall rules + proxy). Because there’s no Kerberos authentication happening, the IP will prompt John for Username & Password (the same he uses to login into Adatum network), then it will issue the same token with John claims, and finally he will be redirected to the app:
Adatum could choose to add other authentication factors when connecting from the internet (smart card, pin, etc). But whatever they do, the applications don’t care! They are still receiving the same set of claims. Here you see one advantage of factoring out authentication from the application.
The last stage is moving a-Expense to Windows Azure. Can we do that? Sure!
Isn’t this beautiful?
Feedback is very much welcome of course.
Update: fixed images size.
