Return to HomePage

Making my first Scenario and Solution

by Ward Cunningham

Creating a Scenario and Solution

I joined the team for a day of security problem solving. I picked a problem, the scenario, and the team worked out the solution together. I chose an intranet web application imagining some sort of corporate record keeping application that every employee needs to access.

Background

We reviewed the scenario space before launching into the particular scenario. This table shows how the team had come to think of the major decision points. My problem turned out to be pretty close to scenario 5.

Reviewed common scenarios:

Scenario	AuthN	User Store	AuthZ	Role Store	Scenario Number
Intranet	Win	AD	WindowsIdentityRoleTokenProvider	AD (Windows)	1
	Win	AD	AuthorizationStoreRoleProvider	AD (AzMan)	2
	Win	AD	AuthorizationStoreRoleProvider	ADAM (AzMan)	3
	Win	AD	SQLRoleProvider	SQL	4
Internet	Forms	AD	WindowsIdentity Token	AD (Windows)	5
	Forms	AD	AuthorizationStoreRoleProvider	AD (AzMan)	6
	Forms	AD	AuthorizationStoreRoleProvider	ADAM (AzMan)	7
	Forms	SQL	SQLRoleProvider	SQL	8

Whiteboarding

When walking through the scenario list, the team asked me what type of application I was interested in. I said Intranet to keep it simple and this was my first architectural decision. The decision making process was to progressively develop a deployment diagram of the architecture on a white board.

My next decision was to choose the type of authentication that would be used. I picked Forms Authentication imagining a heterogeneous machine environment where a few stray non-windows machines would need access to the application.
At this point a lot of things unfolded by making these two decisions. Our whiteboard had a picture a client web browser accessing IIS and ASP.NET 2.0 on the Web tier, and an unspecified database.

For example we assumed that we would be running on a Windows 2003 server environment for our application. In order to keep it simple we decided to use a Web to Database architecture running the .NET 2.0 framework.

What we had essentially done was to choose the scenario 5 architecture but imagined it to be on the Intranet instead of the Internet. We continued to make architectural decisions and drew them on the white board as we went. Our decisions were continually driven by my initial choices or proven practices.

Further Unfolding

We continued designing this way. Our design unfolded step by step pretty much as follows:
* User Store is in Active Directory
* Roles will use Active Directory Groups
* The Web Browser will use SSL to encrypt the communication to the Web server
* The Web tier will not encrypt the communication channel to the database server since the application is running in a data center
* ASP.NET will run under a custom account that we will create. This protected us if additional applidcation were put on the server. That way we would not all be using the Network Service Account to access resources.
* The application does not require impersonation
* The database server will use Windows Integrated Authentication to validate requests from the web server
* Because we are storing our roles as groups in Active Directory and we are using Forms Authentication, we cannot use the ASP.NET Role providers
* As we are using Forms authetication we don't have windows token against which we can do the authorization, hence using the new S4U extenstion on Win2K3, create windowsIdentity for aparticular user. set the windowsidentity to httpContext.current.user IsInRole method.
* We sketched the code that wrapped the function for authorization so we could call the IsUserInRole

Observations

The finished design was reasonably complex and it covered a dozen issues in a couple of hours. The reason this was possible is Microsoft Platform Architecture Guidance team had learned .NET 2.0 Framework and could quickly distill the important decisions that needed to be made. In fact the conversation frequently turned to how some decision that had just been made were more attractive in .NET 2.0.

The real purpose of creating this level of guidance is to help any team make good decisions quickly without being security experts. The whole purpose of this exercise was to test the teams readiness to finish the writing of the guidance.