|
|
Designing an authentication and authorization strategy for distributed Web applications is a challenging task. The good news is that proper authentication and authorization design during the early phases of your application development helps to mitigate many top security risks.
This chapter will help you design an appropriate authorization strategy for your application and will also help answer the following key questions:
Where should I perform authorization and what mechanisms should I use?
What authentication mechanism should I use?
Should I use Active Directory® directory service for authentication or should I validate credentials against a custom data store?
What are the implications and design considerations for heterogeneous and homogenous platforms?
How should I represent users who do not use the Microsoft® Windows® operating system within my application?
How should I flow user identity throughout the tiers of my application? When should I use operating system level impersonation/delegation?
When you consider authorization, you must also consider authentication. The two processes go hand in hand for two reasons:
First, any meaningful authorization policy requires authenticated users.
Second, the way in which you authenticate users (and specifically the way in which the authenticated user identity is represented within your application) determines the available gatekeepers at your disposal.
Some gatekeepers such as ASP.NET file authorization, Enterprise Services (COM+) roles, and Windows ACLs, require an authenticated Windows identity (in the form of a WindowsIdentity object that encapsulates a Windows access token, which defines the caller’s security context). Other gatekeepers, such as ASP.NET URL authorization and .NET roles, do not. They simply require an authenticated identity; one that is not necessarily represented by a Windows access token.
|
|