Authentication and authorization
This chapter
Design authentication and authorization mechanism for distributed web applications is a challenging task, and there are many options you have to make almost every component of the application you develop. The use of suitable authentication and authorization design helps to reduce many of the main security risks. Early phase of application development is much easier than attempting to improve existing or partially built applications.
This chapter describes authentication and authorization mechanisms available when developing distributed ASP.NET web applications. Also describing a process you can use to help choose the most appropriate authentication and authorization mechanism for your application.
aims
Use this chapter to come:
• Understand various options for flow identity through multiple application layers. • Determine the appropriate authentication and authorization mechanisms used in distributed web applications. • Comparison and comparison in distributed .NET Web applications for authentication and authorized "simulation / delegation" (that is, "Original Model") and "Trusted Subsystem" mode. • Comparison and comparison based on role and resource-based authorization.
Applicable to:
This chapter is suitable for the following products and technologies:
• Microsoft Windows XP or Windows 2000 Server (with Service Pack 3), as well as a higher version of the operating system. • Microsoft Internet Information Services (IIS) 5.0 and later • Microsoft Active Directory Directory Services • .NET Framework 1.0 (with Service Pack 2) and later • SQL ServerTM 2000 (with Service Pack 2) and later
How to use this chapter
This chapter describes the process of determining the appropriate authentication and authorization mechanism as a distributed web application. The soon the application's authentication and authorization requirements, the more you can achieve, the more you can also be safer. If you want to get the biggest value from this chapter, you should:
• Read "Build a Security ASP.NET Application Introduction" in this chapter. It defines "authentication" and "authorization" terms related to distributed web applications. • Read "Safety Mode for ASP.NET Applications" in this chapter. It outlines the architecture and techniques for creating distributed ASP.NET web applications. It introduces this chapter to discuss the authentication and authorization mechanisms of the discussion, and define the core content of the authorization topic - the concept of gateway and gateway guard. • Read the following sections, and they argue in the implementation of authentication and authorization technology discussed in this chapter:
• "How to create a custom account to run asp.net". • "How to Use form Authentication with Active Directory". • "How to Use Form Authentication with SQL Server 2000". • "How to Use form Authentication with Generic Principal Objects". • "How to Implement Kerberos Delegation for Windows 2000". • "How to Implement IPrIncipal". • "How to Use Role-Based Security With Enterprise Services". • "How to Call A Web Service Using Client Certificate from ASP.NET". • "How to setup client certificates".
This page
Preparation Design Authentication and Authorization Policy Authorization Method Transfer Identity Based on Role Authorization Select Authentication Mechanism Summary
Ready to work
Designing an authentication and authorization strategy for distributed web applications is a challenging task. It is gratifying that the correct design of authentication and authorization will help reduce the main risks of many security in the early stages of application development. This chapter will help you design the appropriate authorization policy for your application, and will help you answer the following key questions:
• What should be performed in what the authorization should be performed? • What authentication mechanism should I use? • You should use the Active Directory directory service to authenticate or you should verify the credentials against custom data storage? • What do you mean by using heterogeneous and similar platforms? What do you need to pay attention to in design? • How should I indicate the user who does not use a Windows operating system? • How should I pass a user identity between the various layers of the application? In this case, use the operating system level simulation / delegation?
When you consider authorization, you must consider authentication. The two processes are carried out simultaneously, this has two reasons:
• First, any meaningful authorization policy requires users who have verified identity. • Secondly, verify the way the user's identity (specifically, how to indicate the user identity that has been verified in the application) will determine the gateway guard you dispatched. Some gateway guards, (such as ASP.NET file authorization, Enterprise Services (COM ) role, and Windows ACLs require a Windows identity through authentication (existing in the form of WindowsIdentity objects, it encapsulates a definition caller security The context's Windows Access Token.) And other gateway guards, such as the ASP.NET URL authorization and .NET role), there is no requirement. They only need to be verified by verification, and do not need to be represented by a Windows Access Token.
Back to top
Design authentication and authorization strategy
The following steps determine the process of helping you develop authentication and authorization policies for your application:
• Identify resources. • Select an authorization policy. • Select the identity for resource access. • Consider identity delivery. • Select the authentication method. • Decide how to pass identity.
Determine resource
Determine the application that the application needs to be disclosed to the client. Typical resources include:
• Web Server resource, such as web pages, web services, static resources (HTML pages, and images). • Database resources, such as data per user data or application range. • Network resources, such as remote file system resources, and data from directory storage (such as Active Directory).
You must also determine system resources that the application needs access. These resources are opposite to resources disclosed to the client. They include registry, event log, and profile.
Select an authorization policy
There are two basic authorization strategies:
• Based on roles. Access to operations (usually methods) is protected based on the caller's role member. Use the role to divide the user group of the application into a user group sharing the same safe privilege within the application; for example, "Advanced Manager", "Manager" and "Staff". The user is mapped to the role, and if the user has the right to request, the application will use a fixed identity to access the resource. These identities are trusted by their respective resource managers (such as databases, file systems, etc.). • Based on resources. Use the Windows ACL to protect each resource separately. The application simulates them before the caller access resources, so that the operating system can perform standard access checks. All resource access is performed through the safe context of the original call. This simulation method has seriously affects the scalability of the application, as this means that the connection pool cannot be used effectively in the intermediate layer of the application.
In the vast majority of .NET web applications, role authorization methods are the best choices. Some smaller intranet applications extract a single user information from various resources (such as files). When each user accesses these resources, these resources are protected by Windows ACL, so it is more suitable for resource-based Authorization method. When performing role-based authorization, recommendations and common practices are:
• Verify the user's identity in the front-end web application. • Map the user to the role. • Access to operations (rather than direct resources) based on role members. • Use a fixed service identity to access the necessary backend resources (used to support the requested and authorized operation). The backend resource manager (for example, a database) trust application can authorize the caller and willing to grant permissions to trusted service identity. For example, a database administrator may only grant access to a particular human resource application (rather than individual users). Note The role-based authority based on the application level still needs to use resource-based authorization to protect system-level resources, such as profiles, registry entries, and more.
More information
• For more information on these two distinct authorization, please refer to "Authorization Method" later in this chapter. • For more information on role authorization and various roles that can be used, please refer to "Role Authorization" later in this chapter.
Choose the identity for resource access
Please answer this question: "Who will visit resources?"
Select the identity used to access resources in each layer of the application. These resources can be accessed by web-based applications, and can also be accessed by Web services, Enterprise Service, and .NET remote processing components. Generally speaking, the identity for resource access can be the following categories:
• The identity of the original adjustment. It uses an analog / delegation model that can be used to get the original modulus, and then pass this identity between each layer of the system. Delegate is an important criterion for determining authentication mechanisms. • Process identity. This is the default (there is no specific simulation). Use the current process identity to access local resources and downstream calls. Whether this method reliably depends on the boundaries across the boundary because the processes must be identified by the target system. This means calling with one of the following methods:
• Use a duplicate username and password in the same Windows security domain (using trust and domain accounts, if there is no trust relationship, use duplicate username and password) • Service account. This method uses a (fixed) service account. E.g:
• For database access, it can be a fixed SQL username and password provided with a database connection. • When you need a fixed Windows identity, you can use the Enterprise Services server application. • Customize the identity. When there is no available Windows account, you can construct your identity (using iPrincipal and IIDENTITY simulation), which will contain specific contents of the security context you specify. For example, it can contain role lists, unique identifiers, or any other type of custom information. You can benefit from the built-in gateway guards (such as .NET role and principalperterial command) from the current Web context (using httpcontext.user).
Consider identity
To support each user authorization, audit, and each user data retrieval, you may need to transfer the caller identity between different application layers and different computers. For example, if a backend resource manager needs to perform each user authorization, the caller identity must be passed to the resource manager. You have to determine the identity that needs to be passed in the application based on the system's resource manager authorization requirements and audit requirements.
Select authentication method
There are two key factors that affect authentication methods: First, it is also the most important thing, it is, the application's user group features (which browser they use, and if they have a Windows account); the second is, application Simulation / delegation and audit requirements.
More information
For more specific considerations for helping you choose an authentication mechanism for your application, please refer to the "Select Authentication Mechanism" later in this chapter.
Decide how to pass identity
You can pass identity (to provide security context) in the application level, or you can pass identity and security context in the operating system level.
To deliver your identity level, use the method and store procedure parameters. Application ID support:
• Retrieve each user data using trusted query parameters SELECT X, Y from Sometable where username = "bob"
• Customize audits in any application layer
Operating system ID support:
• Platform-level audit (for example, Windows review and SQL Server review) • Each user-based authorization based on Windows identity
In order to pass identity at the operating system level, you can use analog / delegate mode. In some environments, you can use the Kerberos delegation, while in other environments (more environments that do not support Kerberos), you may need to use other methods, such as using basic authentication. Under basic authentication, user credentials can be used by server applications, and can also be used to access downstream network resources.
More information
For more information on identity delivery and how to get analog tokens (ie, support delegation), please refer to "Pass Identity" later in this chapter.
Back to top
Authorization method
There are two basic licensing methods:
• Based on roles. Users are divided into logical roles defined by the application. In the application, members of a particular role will share the same privilege. Access to the operation (usually by method call represented) is authorized by the caller member of the caller. You can access resources with fixed identity (such as web application identity or web service process). The resource manager trust application can authorize the user correctly, and they grant the permissions to trusted identity. • Based on resources. Each resource is protected by Windows ACL. ACL will decide which users allow access to resources and determine which type of operation (read, write, deletion, etc.) per user is allowed. You can access resources using the original adjustment of the identity (using analog).
Role authorization
In a role (or operation)-based security method, access to operations (rather than backend resources) is authorized according to the caller member of the caller. (Analysis and Definition of Application Design) The role is used as a logical container, which will combine the user of the same security privilege (or function) in the application. The user is mapped to the role in the application, and the role member is used to control access to a particular operation (method) disclosed by the application.
What location mapping role in the application is a key factor in the design needs to be considered; for example:
• In an extreme case, the role can be mapped in a backend resource manager (e.g., a database). It requires the original adjuster's security context to pass through each layer of the application to the backend database. • Another extreme case is mapping roles in the front-end web application. In this approach, the downstream resource manager is accessed by securing and trust by each resource manager. • The third case is a role map between a position between the front end and the rear end layer; for example, in the intermediate layer Enterprise Services application. In multi-layer Web applications, use trusted identity access to the backend resource manager to provide a larger scalable space for the application (this is attributed to the connection pool). In addition, the use of trusted identities reduces the need to pass the original caller security context in the operating system level, which is difficult to implement (even if it is not impossible in some cases).
Resource-based authorization
Resource-based licensing methods depends on the basic access control mechanism of Windows ACL and operating system. Application Simulation caller, leaves tasks that perform access checks to an operating system associated with a particular resource manager (file system, database, etc.).
This approach is best suited for such applications, ie, access to resources that can be protected by Windows ACL, such as file resources. FTP applications or simple data-driven web applications belong to such applications. If the data in the requested resource needs to be obtained from multiple different sources (eg, multiple databases, database tables, external applications or web services), this method is not from the heart.
Resource-based approach also depends on the original adjuster security context that is passed to the rear-end resource manager. This method is complicated and greatly reduces the ability to increase interviews in multi-storey applications, because use this method, you cannot use the set function (for example, database connection collection) in the application intermediate layer (for example, database connection collection).
Resource access mode
By studying the two resource access security patterns of .NET web applications (and generally distributed multi-layer applications), we can see two distinct authorization methods. They are:
• Trusted subsystem mode • Simulation / delegation mode
There are advantages and disadvantages in both security and scalability. These modes will be described below.
Trusted subsystem mode
In this mode, the intermediate layer service uses fixed identity to access downstream services and resources. Original adjuster safety context is not passed through service level through service, but the application can choose to pass the original caller identity in the application level. It may be necessary to do this to support the rear end audit request, or to support each user data access and authorization.
The name of this mode is derived from the downstream service (which may be a database) trust upstream services when authorizing the caller. Figure 1 shows this mode. Please pay special attention to trust boundaries. In this example, the database trust the intermediate layer can authorize the caller and only allows authorized caller to access the database through trusted identity.
In a trusted subsystem mode, the access steps of the resource are as follows:
• Verify user identity • Map users to roles • Role member authorization • Use fixed trusted identity to access downstream resource manager
Fixed identity
The fixed identity for accessing the downstream system and the resource manager is usually provided by the pre-configured Windows account (also known as a service account). In Microsoft SQL Server Explorer, this means using Windows authentication for SQL Server.
In addition, some applications access SQL Server using the specified SQL account (specified by the username and password in the connection string). In this case, SQL authentication must be configured for the database.
For more information on the relative advantages and disadvantages of Windows and SQL authentication, please refer to "Data Access Security" in communication with SQL Server communication.
Use multiple trusted identities
Some resource managers may need to perform further subdivision authorizations based on the caller of the caller. For example, you may have two groups of users, and a group should be authorized to perform read / write operations, and another group should authorize the read-only operation.
Please see the SQL Server method below:
• Create two Windows accounts, one for reading, and another for read / write operations. More commonly, use different account mapping applications specific roles. For example, you might want an Internet user using an account, allowing internal operators and / or administrators using another account. • Map each account into a database role defined by the SQL Server user and establish the necessary database permissions for each role. • Map the user to the role in the application and use role members to determine the account that is connected to the database before the role member.
This method is shown in Figure 2.
Figure 2. Using multiple identity access to the database to support more subdivided authorization
Simulation / delegation mode
In this mode, the service or components simulate the client's identity before the client accesss the next downstream service (usually somewhere in the logical service layer) (using the operating system level simulation). If the next service is in the same computer, the simulation is sufficient. If the downstream service is located on a remote computer, it is also necessary to delegate.
The result of the delegate is that the security context used for downstream resource access is the security context of the client. Use this mode usually there are two reasons:
• It allows the downstream service to execute each caller authorization through the original regulator. • It allows the downstream service to use the operating system level audit function.
As a specific example of this technique, the intermediate layer Enterprise Services component can simulate it before the caller accesses a database. Use database connections that depend on the original adjuster security context to access the database. In this mode, the database authenticates each caller and performs an authorization decision based on the authority assigned to the identity of each caller (or the called WINDOWS group member). The simulation / delegation mode is shown in Figure 3.
Figure 3. Simulation / delegation mode
Select Resource Access Mode
Trusted subsystem mode For most Internet applications and large-scale intranet applications, this is mainly considered for scalability factors. The simulation mode is often used for small-scale applications and applications that are key issues (due to non-refused reasons) for scalability.
Advantages of simulation / delegation model
The main advantages of the simulation / delegation model are review (close to the data). Audit allows administrators to track users attempting to access specific resources. Generally, if the audit is the exact time of resource access, the same routine of the access resource is generated, and the audit is considered to be the most authoritative.
The simulation / delegation model supports this by maintaining user security context accessible to the downstream resource. This makes the backend system authority to record the user and the requested access.
Disadvantages of simulation / delegation model
The disadvantages of the simulation / delegation model include:
• Technical challenges. Most secure service providers do not support delegation, Kerberos is a famous exception. Performing analog process requires higher privilege (specifically, the execution privilege as part of the operating system). (This limits for Windows 2000, not for Windows .NET Server). • Scalability. The simulation / delegation model means you can't effectively use the database connection pool because the connection of the database access relies on the different security context of the original call. This seriously limits the application to extension to a large number of users. • More management work. Maintaining the ACL in the backend resource needs to grant each user's proper access level. When the number of backend resources increases (and the number of users increase), you need to put a lot of management energy on the management ACL. Advantages of trusted subsystem mode
The trusted subsystem model has the following advantages:
• Scalability. The trusted subsystem mode supports the connection pool, which is the basic requirement of application scalability. The connection pool allows multiple clients to reuse the available pool connections. It is very applicable to this mode because all backend resource access is safe context using service accounts regardless of the caller identity. • The backend ACL management is minimized. Only the service account accesses the backend resource (for example, the database). ACL is only configured for this identity. • Users cannot access data directly. In trusted subsystem modes, only the intermediate service account is authorized to access backend resources. Therefore, users cannot directly access backend data if they do not pass applications (and as approved by application authorization).
Disadvantages of trusted subsystem mode
There are two disadvantages of trusted subsystem model:
• Audit. In order to perform an audit in the back end, it can be explicitly (at the application level) to the rear end and the audit is performed in that. The intermediate layer must be trusted and there is a potential rejection risk. Another option is to generate an audit record in the intermediate layer and then associate it with the backend audit record (for this, you must ensure that the server clock is synchronized). • Increase server attack danger. In a trusted subsystem mode, the intermediate layer service is authorized to access a wide range of backend resources. Therefore, security threatened intermediate layer services may make attackers easier to get extensive access to backend resources.
Back to top
Pass identity
Distributed applications can be divided into multiple security subsystems. For example, front-end web applications, intermediate web services, remote components, and databases represent four different security subsystems. Each is performed authentication and authorization.
You must identify the subsystem that must pass the caller identity (and related security context) to the downstream subsystem, so that authorization for the original adjuster can be supported.
Application and operating system authentication comparison
Identity transfer strategy includes delegation capabilities using the operating system or pass tickets and / or vouchers in the application level. E.g:
• In order to pass the identity, generally use method parameters or stored procedure parameters transfer credentials (or tickets). Note: GenericPrincipal objects carrying authenticated caller identities do not automatically pass during processes. This requires custom code. You can pass to store procedure to allow you to retrieve and process parameters for user-specific data. For example: Select CreditLimit from Table Where UserName = "BOB"
This method is sometimes referred to as a trusted query parameter method. • Operating system communication requires an emulation of an extension (called delegation).
Simulation and delegation
In a typical case, the thread in the server application uses the security context of the server process. The properties of the process security context are maintained by the process of login session, and is disclosed by the process-level Windows Access token. All local and remote resource access are performed through process-level security context, and the security context is determined by the Windows account used to run the server process. simulation
When analog simulation is configured for the server application, the analog token is attached to the thread used to process the request. The analog token represents the security context of the calibrator (or anonymous user). Any local resource access is performed by thread analog tokens that cause the caller security context.
Delegation
If the server application thread is trying to access the remote resource, you will need to delegate. Specifically, the token of the simulated caller must have a network credential. If not, all remote resource access is performed with anonymity user (Authority / A No NYMOS LOGON)).
Many factors can determine if they can delegate security context. Table 1 shows various IIS authentication types and indicate whether each type indicates whether you can delegate the security context of the caller of authentication.
Table 1: IIS Authentication Type Authentication Type Can delegate anonymity If an anonymous account (default is IUSR_MACHINE) is configured as a local account in IIS, then unless the local (web server) and the remote computer are the same Local account (with matching username and password), otherwise it cannot be delegated. If an anonymous account is a domain account, you can delegate it. Basically, if you use basic authentication to your local account, you can delegate it as long as the local account of the local and remote computers is consistent. You can also delegate an area account. Profile No - Integration Windows approach to integrated Windows authentication results in NTLM or Kerberos (depending on the client and server version). NTLM does not support delegation. Kerberos supports delegation for proper configuration. For more information, please refer to "How to Implement Kerberos Delegation for Windows 2000". The client certificate will be delegated if you use it with the IIS certificate mapping, and the certificate is mapped to a local account replicated on a remote computer or mapped to domain accounts. This feasible reason is that the voucher of the map account is stored on the local server and is used to create (with network credentials) interactive login sessions. The Active Directory certificate mapping does not support delegation.
Important: The Kerberos delegation under Windows 2000 is unrestricted. In other words, the user may be able to manufacture multiple network hops between multiple remote computers. In order to eliminate this potential security risks, the access range of the domain account should be restricted, and the method is to remove this account from the Domain User group and only allow you to log in to a specific computer using this account.
Back to top
Role authorization
Most .NET web applications use roles based on role. You need to consider a variety of roles, choose the method that best suits your application solution. You have the following options:
• .NET Role • Enterprise Services (COM ) Role • SQL Server User-defined Database Role • SQL Server Applications
.NET role
The .NET role is very flexible, it is expanded around the IPrincipal object, which contains a list of roles belonging through the identity authentication. The .NET role can be used for web applications, web services, or remote components that reside in ASP.NET (with HTTPChannel Access).
Authorization can be carried out in two ways by the .NET role: one with a PrincipalPerMission command in a declaration, a programming method, a mandatory principalPermission command or iprincipal.isinrole method in the code. .NET role in Windows authentication
If your application uses Windows authentication, ASP.NET automatically builds a WindowsPrincipal and attached to the context of the current web request (using httpContext.user). The authentication process is completed, and ASP.NET is attached to the current request, it can be used for all subsequent .NET role authorization.
The WINDOWS group member of the caller is used to determine the role set. Under Windows Authentication, .NET roles are the same as the Windows group.
Non-Windows authentication .NET role
If your application uses a non-Windows authentication mechanism (such as form or passport), then you must write code to create the genericprincipal object (or customize the iPrincipal object) and use it from custom authentication data storage (such as SQL Server database) Get the character set.
Customize IPrIncipal object
The security mechanism based on .NET role is scalable. You can develop a self-class that implements iPrincipal and IIDENTITY and provides your own role-based extension authorization.
The basic role check function is guaranteed as long as the Customize the iPrInCIPAL object (including the role obtained from the custom data store) (via httpcontext.user) is attached to the current request.
By implementing an iPrincipal interface, you can ensure that the PrincipalPermission command in the form of declaration and commands is available for your custom identity. Alternatively, you can implement extended role semantics; for example, other methods of allowing you to test and assert a plurality of roles, such as Isinmultipleroles (String [] Roles).
More information
• For more information on .NET role, please refer to the "ASP.NET Security" chapter. • For more information on creating genericprincipal objects, please refer to the "HOW TO CREATE GenericPrincipal Objects With Form Authentication" chapter.
Enterprise Services (COM ) role
Use the Enterprise Services (COM ) role to deliver access check to the intermediate layer and allow you to use the database connection pool when connecting to the backend database. However, for the meaningful Enterprise Services (COM ) role, the front-end web application must simulate the identity of the original call, and pass it to the Enterprise Services application (via the Windows Access Token). To do this, you must put the following items in the web.config file of the web application.
If the method level is used (to determine which methods can be called), you can use the Component Services management tool to deploy the application and update role members.
If you need to use the method code in programming, you will lose some of the management and deployment advantages of the Enterprise Services (COM ) role because role logic is hardcoded.
SQL Server user-defined database role
In this method, you create a role in the database, assign permissions according to role and map Windows groups and user accounts to roles. This method requires you to pass the caller as a backend (if you use the preferred Windows authentication using the SQL Server).
SQL Server application role
In this method, the permissions grant the role in the database, but the SQL Server application role does not include a user and group account. Therefore, you will lose the particle size of the original call.
In the application role, you are authorized to access specific applications (relative to a group of users). This application uses a built-in stored procedure for accepting role names and password activation roles. One of this approach is that it requires the application to securely manage credentials (role names and related passwords).
More information
For more information on database roles and application roles defined by SQL Server users, please refer to "Data Access Security" chapter.
Comparison of .NET roles and Enterprise Services (COM ) roles
The following table lists the functionality of the .NET role and Enterprise Services (COM ) roles.
Table 2: Enterprise Services Role with .NET Role Contrast Features Enterprise Services Roles .NET Role Management Component Services Administrative Custom Data Storage COM Directory Custom Data Storage (such as SQL Server or Active Directory) declaration is whether ordered Class, interface, and method level granularity are extensible (using custom iPrincipal implementation) available for all .NET components to use components that are only derived from the serviceDComponent base class is the role member role contains a Windows group or user account. When WindowsPrincipal, the role is a Windows group - no additional abstract level requires explicitly implement interfaces, you must explicitly define and implement an interface if you want to get an authorization of the method level.
Use the .NET role
You can use the .NET role to protect the following security:
• File • Folder • Web page (.aspx file) • Web service (.asmx file) • Object • Method and property • Code block in the method
You can use the .NET role protection (execution) and the facts of the method and attributes, which means you can protect access to the local and remote resources accessed by the application.
Note The first four (files, folders, web pages, and web services) in the previous list are protected by UrlauthorizationModule, which can be authorized to use the caller's role member (and caller identity).
If you use Windows authentication, the system will do most of the work required to use .NET roles. ASP.NET builds a WindowsPrincipal object and determines the associated role set by the user's Windows group member.
To use the .NET role in a non-Windows authentication mechanism, you must write code to do the following:
• Capture user credentials. • Test the credentials that users access custom data storage (such as SQL Server database). • Retrieve a list of roles to build the genericprincipal object and associate it with the current web request. The genericprincipal object represents the authenticated user and is used for subsequent .NET role checks, such as declared PrincipalPermission commands, and programming IPrincipal.Inrole checks. More information
For more information on the process involved for the process of creating the generatorPrincipal object for the form, please refer to the "ASP.NET Security" chapter.
Check role
The following types of .NET roles can be used:
Important: .NET role checks dependent on whether IPrInCIPAL objects (indicating users via authentication) is associated with the current request. For ASP.NET web applications, the iPrincipal object must be attached to httpContext.user. For Windows Forms applications, the iPrincipal object must be attached to Thread.currentPrincipal.
• Manual role check. For subdivision authorization, you can call the iprincipal.isinrole method, authorize access to a particular code block based on the caller's role member. And and OR logic can be used when checking role members. • Declarative role check (method inlet). You can use the PrincipalPermissionAttribute class (you can write to PrincipalPermission) to comment on the method to declare a manner. These checks only support OR logic. For example, you can ask a caller to be at least a specific role (for example, the caller must be an advertiser or a manager). You cannot use a declarative inspection to specify a caller must be both a manager and a cashier. • Command character check (check in the method). You can call PrincipalPermission.Demand in your code to perform subdivision authorization logic. Support logical and OR operations.
Role check example
The following code snippet shows some role checks for programming, declarative, and commanding methods.
Authorized BOB execution operation:
Note Although individual users can be authorized, they should usually be licensed based on role members, which allows you to authorize users groups that share the same privileges in the application.
• Direct User Name Check GenericIdentity UserIdentity = New GenericIdentity ("Bob");
IF (useridentity.name == "bob")
{
}
• Declarative check [PrincipalPermissionattribute (SecurityAction.Demand, user = "bob")]
Public void doprivilegedMethod ()
{
}
• Commander Check PrincipalPermission PermCheckUser = New PrincipalPerMission
"Bob", NULL;
PermCheckUser.Demand ();
Authorized sanner execution operation:
• Direct role name Check genericIdentity Useridentity = New GenericIdentity ("Bob");
// Role Names Would Be Retrieved from a Custom Data Store
String [] roles = new string [] {"manager", "teller"}; genericprincipal userprincipal = new genericprincipal (userident,
Roles);
UserPrincipal.isinRole ("Teller"))
{
}
• Declarative check [PrincipalPermissionattribute (SecurityAction.Demand, role = "teller")]
Void SometelleronlyMethod ()
{
}
• Commander Check PUBLIC SomeMethod ()
{
PrincipalPermission PermCheck = New PrincipalPerMission
NULL, "Teller");
PermCheck.demand ();
// only tellers can Execute The Following Code
// N Members of The Teller Role Result in a security exception
.
}
Authorized manager or invoice execution operation:
• Direct role check if (Thread.currentPrincipal.Isinrole ("teller") ||
Thread.currentPrincipal.Isinrole ("Manager"))
{
// perform privileged operations
}
• Declarative check [PrincipalPermissionattribute (SecurityAction.Demand, role = "teller"),
PrincipalPermissionAttribute (SecurityAction.Demand, role = "manager")]]]
Public void doprivilegedMethod ()
{
}
• Commander Check PrincipalPermission PermCheckTellers = New PrincipalPerMission
NULL, "Teller");
PrincipalPermission Permcheckmanagers = New PrincipalPerMission
NULL, "Manager");
PermcheckTellers.Union (PermCheckmanagers)). Demand ();
Authorized those users who are both managers and cashiers:
• Direct role check IF (Thread.currentPrincipal.Insinrole ("Teller" &&
Thread.currentPrincipal.Isinrole ("Manager"))
{
// perform privileged operation
}
• Declarative checks cannot be used to declare the AND check in declaration. The PrincipalPerMission command is superimposed together to use the logic OR. • Commander Check PrincipalPermission PermCheckTellers = New PrincipalPerMission
NULL, "Teller");
PermCheckTellers.Demand ();
PrincipalPermission Permcheckmanagers = New PrincipalPerMission
NULL, "Manager");
PermCheckmanagers.Demand ();
Back to top
Select authentication mechanism
This section provides guidance information to help you choose a common application solution authentication mechanism. You should consider starting from the following issues:
• Identity. Only when the application user's Windows account can be authenticated by trusted agencies, and the application's web server can access the agency to use the Windows authentication mechanism. • Document management. One main advantage of Windows authentication is that it allows you to hand over the credential management to the operating system. With non-Windows methods (such as table single authentication), you must carefully consider the storage location and method of user credentials. Two most common methods are used:
• SQL Server Database • User Objects in Active Directory For more information on safety considerations for SQL Server as credential storage, please refer to Chapter of Data Access Security. For more information on using table single authentication in custom data storage, including Active Directory, refer to "ASP.NET Security" chapter. • Identity. Do you need to implement analog / delegate mode, and deliver the security context of the original caller between the various layers of the operating system level? For example, in order to support audits or per user (particle size) authorization. If you need, you need to simulate the caller, and assign them to the next sub-system to the next sub-system, as described in the "Delegate" topic in the "Delivery" section in front of this chapter. • The browser type. Does your users have Internet Explorer? Or do you need to support user bases with a hybrid browser type? Table 3 illustrates which authentication mechanisms require Internet Explorer browser and which supports a variety of common browser types.
Table 3: Authentication browser requires the authentication type requires Internet Explorer Remarks Toms - Passport No - Integration Windows (Kerberos or NTLM) is Kerberos also requires client and server using Windows 2000 or higher operating system, and In order to delegate the account. To learn more, please refer to "How To Implement Kerberos Delegation for Windows 2000". Basically No Basic authentication is part of the HTTP 1.1 protocol supported by almost all browsers - Certificate No Client Requirements X.509 Certificate
Internet solution
Basic assumptions for the Internet program are:
• The user does not have a Windows account in the trusted domain of the server domain or the servers. • The user does not have a client certificate.
Figure 4 shows a decision tree for choosing an authentication mechanism for the Internet solution.
Figure 4. Select the authentication mechanism for the Internet application
For more information on the Web Service Security and WS Security Specification (Part of the World XML Architecture (GXA) initiative, please refer to the "Web Services Security" chapter.
Form / Passport comparison
This part summarizes the relative advantages of forms and Passport authentication.
The advantage of formal authentication
• Support for authentication of customized data storage (usually SQL Server Database or Active Directory). • Support role authorization (including lookup roles from data storage). • Integrate with the web user interface. • ASP.NET provides most of the structure. Compared with traditional ASP, the custom code required is relatively small.
PASSPORT authentication advantages
• Passport is a centralized solution. • It does not require application for credential management. • Can be used with a role authorization program. • Very secure because it is built on the encryption technology. More information
• For more information on Web Services authentication methods, please refer to the "Web Services Security" chapter. • For more information on using table single authentication in SQL Server, please refer to the "HOW TO USE Form Authentication with SQL Server 2000".
Intranet / Extranet solution
Figure 5 shows a decision tree that can be used to help select an authentication mechanism for the Intranet and Extranet application.
Figure 5. Select an authentication mechanism for the Intranet and Extranet applications
Comparison of authentication mechanisms
The following table shows the comparison of the available authentication mechanism.
Table 4: Available Authentication Method-BasicDigestNTLMKERBEROSCERTSFORMSPASSPORT users When you need a Windows account in the server's domain, whether you support delegated * whether it is whether you need a Win2K client and whether the server does not pass whether or not to pass a document in a clear text (Require SSL) No No No IE is supported whether the non IE browser is not yet
* For details, refer to the "delegate" topic in the "Delivery" section in front of this chapter.
Back to top
summary
The identity verification and authorization method for designing distributed applications is a challenging task. In the early stages of application development, proper design authentication and authorization help to reduce many of the main security risks. The following summarizes the information in this chapter:
• Use the trusted subsystem resource access mode to get the benefits of using the database connection pool. • If your application does not use Windows authentication, use the .NET role check to provide authorization. Retrieve the role list and create genericprincipal objects for custom data storage inspection credentials. Associate it with the current web request (httpContext.user). • If your application uses Windows authentication, but does not use Enterprise Services, use the .NET role. Remember, for Windows authentication, .NET roles are Windows groups. • If your application uses Windows Authentication and Enterprise Services, consider using Enterprise Services (COM ) roles. • For a meaningful role-based authorization using Enterprise Services (COM ) roles, the original call must be passed to Enterprise Services applications. If the Enterprise Services app is called from the ASP.NET web application, it means that the web application must use Windows authentication and configured to use analog. • Note the method with the PrincipalPermission property to declare the manner. If the caller is not in the specified role, the method is not called and a safe exception is generated. • Call PrincipalPermission.Demand (or use iPrincipal.Isinrole) in the method code to obtain subdivision of authorization decisions. • Consider implementing a custom iPrincipal object to get other roles to check semantics.
