What are the key steps to designing an effective authentication and authorization strategy?  The keys are knowing your user stores, role stores, and who need to access what or perform which operations.   In this post, I share the approaches we've used in two of our patterns & practices guides.  These are the approaches we've used to help customers design successfully design their authentication and authorization approaches.

Designing an Authentication and Authorization Strategy - v1
When we first wrote Building Secure ASP.NET Applications, here's the meta-process we came up with for working through your authentication and authorization strategies:

1. Identify resources
2. Choose an authorization strategy
3. Choose the identities used for resource access
4. Consider identity flow
5. Choose an authentication approach
6. Decide how to flow identity

For elaboration, see Authentication and Authorization.

Designing an Authentication and Authorization Strategy - v2
When we recently wrote Improving Web Application Security, we made some revisions:

1. Identify your user stores.
2. Identify your role stores.
3. Identify resources you need to access and operations you need to perform.
4. Identify which identities need to access the resources and perform the operations.
5. Choose your authentication and authorization strategies.

Personally, I've found it really cuts to the chase if you start with your user stores and role stores, since they tend to be somewhat fixed. 

Identities
When you think through the identities, I've found it helpful to think in terms of who needs to access which resources or perform which actions.  Consider the following:

• Original caller
• Process identity
• Service account
• Custom identity
• Role

Resource Types
When you think through the resource types, I find it helpful to think in terms of:

• System
• Application
• User

Authorization Strategies
When thinking through the authorization strategies, I find it helpful to consider:

• Role-based
• Resource-based
• Operation-based

Resource Access Patterns
When thinking through the resource access patterns, I find it helpful to consider:

• Trusted subsystem model
• Impersonation/delegation model

Designing authentication and authorization can be a gnarly topic.  I hope the scaffolding above helps you find a path that works for you.