Eugenio Pace - Cloud Computing Guidance

[sukishan]

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.