Asp Net 2.0 Security Membership And Role Management

Chapter 15

The reason that there is no special FileIOPermission behavior for partially trusted non-ASP.NET applications is the base requirement for unmanaged code permissions. After an application or a piece of code has that permission, checking the FileIOPermission is pointless. Unmanaged code permission means the application can just use Win32 or COM calls to directly manipulate the file system, so checking for FileIOPermission wouldn’t prove anything about the trust level for the application.

Using Membership and Role Manager

Together

The previous samples have been exclusively using a username in a UPN format — demouser98@corsair

.com. Even though the full configuration for the samples was not shown, they were using the ActiveDirectoryMembershipProvider configuration shown in Chapter 12. This allowed me to first login with forms authentication against the directory, and then AuthorizationStoreRoleProvider initialized its client context with the same UPN. The nice thing about the UPN format is that using both the Membership and Role Manager providers together works.

Logging in with a UPN places that value in the forms authentication ticket. When it comes time for AuthorizationStoreRoleProvider to fetch role information for the user, it calls

InitializeClientContextFromName to set up the client context. This method accepts and parses usernames following the same rules defined in the Win32 API method LookupAccountName. UPNs provide unambiguous identification of a user account, which is why UPN style usernames work well with both providers.

Problems can arise though if your Membership provider is configured to use the sAMAccountName attribute. Because ActiveDirectoryMembershipProvider already knows the domain that it operates in, the provider does not allow the username parameter to include the DOMAIN portion. As a result, if you validate a forms authentication login with ActiveDirectoryMembershipProvider, the username that ends up in FormsAuthenticationTicket will lack the domain name. When

AuthorizationStoreRoleProvider subsequently attempts to initialize a context from that username, it goes through a lengthier process trying to determine the correct user. The problem is that in even moderately complex domain environments you can have duplicate sAMAccountName(s) in different domains. For that matter the same username can show up in a machine’s local account SAM and in the domain. These cases can lead to ambiguity for AzMan and in the worst case can cause the wrong user account to be selected and used for authorization purposes.

The solution to the SAM account name problem is to layer support for NT4 style account names on top of ActiveDirectoryMembershipProvider. This allows users to login with the older DOMAIN\ USERNAME syntax, which in turn means AuthorizationStoreRoleProvider will find the correct user when it looks for it in the directory. The inclusion of the DOMAIN portion of the username means that in multidomain environments you will be able to use forms authentication with both

ActiveDirectoryMembershipProvider and AuthorizationStoreRoleProvider without having to worry about duplicate usernames in different domains confusing AzMan.

You can use the familiar approach of just deriving from ActiveDirectoryMembershipProvider to create a custom provider with the necessary functionality. The custom provider will add in some basic validation logic that ensures the username parameter supplied to any method has the correct domain

592

AuthorizationStoreRoleProvider

name. You set the domain name that the custom Membership provider expects in the applicationName configuration attribute. Because this attribute is not used by ActiveDirectoryMembershipProvider, it is a convenient place to store the expected DOMAIN prefix for a username.

public class NTUsernameProvider : ActiveDirectoryMembershipProvider

{

private string StripOffDomainValue(string username)

{

string[] userParts = username.Split(new char[] {‘\\’}); if (userParts.Length == 1)

throw new ArgumentException(

“You must supply a domain name in the form DOMAIN\\USERNAME.”);

string domain = userParts[0]; string user = userParts[1];

if (String.Compare(domain,this.ApplicationName, StringComparison.OrdinalIgnoreCase) != 0)

throw new

ArgumentException(“The supplied username is in an incorrect format.”);

return user;

}

public override bool ValidateUser(string username, string password)

{

string user; try

{

user = StripOffDomainValue(username);

}

catch (ArgumentException ae)

{

return false;

}

return base.ValidateUser(user, password);

}

public override MembershipUser GetUser(string username, bool userIsOnline)

{

string user = StripOffDomainValue(username); return base.GetUser(user, userIsOnline);

}

//Override additional methods as needed.

}

The code to accomplish this is pretty simple. The private helper method StripOffDomainValue splits apart a username parameter into the domain name and the plain user name. It then verifies that the username did contain a domain identifier and that the domain portion of the username matches the domain name specified in the provider’s applicationName configuration attribute. If these validation checks succeed, the helper method returns just the username portion of an NT4 style username.

593

Chapter 15

The custom provider uses this helper method in its overrides of ActiveDirectoryMembershipProvider. Prior to calling into the base class the custom provider strips the domain portion of the username.

This allows the underlying provider to function as it expects when usernames are mapped to the sAMAccountName attribute. However, from an application perspective, a user is always known by a full NT4 style username. To use the custom provider, you change the Membership configuration to point at it:

<add name=”appprovider” type=”NTUsernameProvider” attributeMapUsername=”sAMAccountName” connectionStringName=”DirectoryConnection” applicationName=”CORSAIR”/>

Notice how the applicationName attribute now contains the old NT4-style name of the domain. With the Membership feature configured to use the custom provider, you can now log in using NT4-style credentials like CORSAIR\testuserpopa (this was an account created in Chapter 12). After logging

in with these credentials, you can then retrieve the role information for this user with the usual Role Manager API calls. These calls will work because the username retrieved from User.Identity.Name will always be CORSAIR\testuserpopa. Because this username includes the domain of the user, when AuthorizationStoreRoleProvider initializes a client context, AzMan has all of the information it needs to correctly identify the domain and the specific user in that domain that it should work with.

Summar y

AuthorizationStoreRoleProvider maps most RoleProvider functionality (with the exception of the FindUsersInRole method) onto the Authorization Manager (AzMan) feature of Windows Server 2003 domains. The provider works with AzMan policy stores located in Active Directory, ADAM or filebased policy stores. You can use the provider in both ASP.NET and non-ASP.NET applications. If you want the use the provider in partially trusted applications though, there are a number of restrictions around using file-based and directory-based policy stores.

Using either a file-based or directory-based AzMan policy store with the provider is straightforward. After the AzMan policy store has been created and populated, you need to grant access to the store. With the appropriate access rights (NTFS rights for the file-based policy store and AzMan-specific roles for directory based policy stores), AuthorizationStoreRoleProvider can then connect to the AzMan policy store. The provider carries out its operations in the context of either a specific AzMan application or in the context of an AzMan scope.

Even though the RoleProvider class doesn’t expose the concept of role nesting, if you have structured your AzMan policy store with any of its nesting features, the GetRolesForUser and IsUserInRole methods will correctly reflect the results of any these relationships. The advanced LDAP query group functionality also works with both of these methods. Remember that if you are working in a domain environment that uses SAM account names for its users and your application is using forms authentication with ActiveDirectoryMembershipProvider, you will need to write a simple wrapper around the Membership provider in order to accommodate NT4-style account names. When using SAM account names, AuthorizationStoreRoleProvider will only work reliably if the full NT4-style username is available from the HttpContext.

594

AddUsersToRoles method

596

597

code

598

599

DefaultHttpHandler (continued)

600

601