• Choose a category
• All
• Classic-Fiction

By Root 5760 0

roles to the current identity object, such as the User object. The module listens for the AuthenticateRequest event and does its job.

The Role Provider

For its I/O activity, the role manager uses the provider model and a provider component. The role provider is a class that inherits the RoleProvider class. The schema of a role provider is not much different from that of a membership provider. Table 19-14 details the members of the RoleProvider class.

Table 19-14. Methods of the RoleProvider Class

Method

Description

AddUsersToRoles

Adds an array of users to multiple roles.

CreateRole

Creates a new role.

DeleteRole

Deletes the specified role.

FindUsersInRole

Returns the name of users in a role matching a given user name pattern.

GetAllRoles

Returns the list of all available roles.

GetRolesForUser

Gets all the roles a user belongs to.

GetUsersInRole

Gets all the users who participate in the given role.

IsUserInRole

Indicates whether the user belongs to the role.

RemoveUsersFromRoles

Removes an array of users from multiple roles.

RoleExists

Indicates whether a given role exists.

You can see the similarity between some of these methods and the programming interface of the Roles class. As you saw for membership, this is not just coincidental.

ASP.NET ships with a few built-in role providers—SqlRoleProvider (default), WindowsTokenRoleProvider, and AuthorizationStoreRoleProvider. The SqlStoreProvider class stores role information in the same MDF file in SQL Server Express as the default membership provider. For WindowsTokenRoleProvider, role information is obtained based on the settings defined for the Windows domain (or Active Directory) the user is authenticating against. This provider does not allow for adding or removing roles. The AuthorizationStoreRoleProvider class manages storage of role information for an authorization manager (AzMan) policy store. AzMan is a Windows download that enables you to group individual operations together to form tasks. You can then authorize roles to perform specific tasks, individual operations, or both. AzMan provides an MMC snap-in to manage roles, tasks, operations, and users. Role information is stored in a proper policy store, which can be an XML file, an Active Directory, or an ADAM server.

Custom role providers can be created deriving from RoleProvider and registered using the child section in the section. Note that the process for doing this is nearly identical to the process you saw for the custom membership provider we explored previously.

Quick Tour of Claims-Based Identity

Unlike many other aspects of programming, authentication has always been devoid of any level of indirection. This means that developers have always taken care of any details of the authentication API at quite a low level of abstraction and with deep knowledge of the technical aspects.

A key challenge, then, is carrying the world of security toward a different model, where the concept of outsourcing is central and development teams can focus on selecting the best provider for authentication. The new model is centered on Windows Identity Foundation (WIF) and uses claims instead of direct management of user credentials to implement authentication-based features.

Claims-Based Identity

Classic authentication is based on two steps: getting the user credentials and validating them against some known values. If the provided information matches the stored information, the user is recognized and authenticated and can gain access to specific features of the application.

Getting user credentials, however, often requires dealing with different technologies and possessing a wide range of skills. You can use, for example, certificate, Forms, or Windows authentication. In any of these cases, you must be familiar with technical details. As a result, your application recognizes the identity of a user from provided credentials that hopefully have been validated successfully.

Claims-based identity is something different.

Claims