MCAD/MCSD Training Guide (70-310): Developing XML Web Services and Server Components with Visual Basic(R) .NET and the .NET Framework

   

Configure security for a Windows service, a serviced component, a .NET Remoting object, and an XML Web service: Configure and control authorization. Authorization methods include file-based authorization and URL-based authorization.

After your application has authenticated users, you can proceed to authorize their access to resources. But there's a question to answer first: Just who is the user to whom you are granting access? It turns out that there are different answers to that question, depending on whether you implement impersonation. With impersonation, the ASP.NET process can actually take on the identity of the authenticated user .

Impersonation only applies to applications that use ASP.NET to communicate with the server. For other server applications (such as services and serviced components ), impersonation doesn't come into the picture.

Once a user has been authenticated and you've decided whether to use impersonation, you can proceed to grant access to resources. You can use the role-based authorization features of the .NET Framework for this purpose.

In this section, I'll discuss both impersonation and role-based authorization.

Implementing Impersonation

Configure security for a Windows service, a serviced component, a .NET Remoting object, and an XML Web service: Configure and implement Identity management.

ASP.NET impersonation is controlled by entries in the applicable web.config file. The default setting is no impersonation. You can also explicitly specify this setting by including this element in the file:

<identity impersonate="false"/>

With this setting, ASP.NET does not perform user impersonation. What does that mean? It means that ASP.NET will always run with its own privileges. By default, ASP.NET runs as an unprivileged account named ASPNET . You can change this by making a setting in the processModel section of the machine.config file. This setting can only be changed in machine.config , so any change automatically applies to every site on the server (and no site can have a setting different from that of the server). To use a high-privilege system account instead of a low-privilege account, set the userName attribute of the processModel element to SYSTEM .

WARNING

SYSTEM Is Dangerous Don't run ASP.NET under the SYSTEM account unless you absolutely need to. Because this is a high-privilege account, it opens your server to disastrous changes should a security hole in ASP.NET ever be discovered and exploited.

So when impersonation is disabled, all requests will run in the context of the account running ASP.NETeither the ASPNET account or the system account. This is true whether you're using anonymous access or authenticating users in some fashion.

The second possible setting is to turn on impersonation:

<identity impersonate="true"/>

In this case, ASP.NET takes on the identity passed to it by IIS. If you're allowing anonymous access in IIS, this means that ASP.NET will impersonate the IUSR_ ComputerName account that IIS itself uses. If you're not allowing anonymous access, ASP.NET will take on the credentials of the authenticated user and make requests for resources as if it were that user.

Finally, you can specify a particular identity to use for all authenticated requests:

<identity impersonate="true" name="DOMAIN\username" password="password"/>

With this setting, all requests are made as the specified user ( assuming that the password is correct in the configuration file).

Step by Step 11.6 will give you some practice in configuring impersonation.

STEP BY STEP

11.6 Using Impersonation

  1. In Windows, select Start, Programs, Administrative Tools, Internet Services Manager.

  2. In Internet Services Manager, drill-down into the tree view until you find the node that corresponds to your Visual Basic ASP.NET application. This node will have the same name as the application and will be located beneath the Default Web Site node. Right-click the application node and select Properties.

  3. In the Properties dialog box, click the Directory Security tab. Click the Edit button in the anonymous access and authentication methods section to open the Authentication Methods dialog box.

  4. Uncheck the Anonymous Access check box. Check the Basic authentication check box.

  5. Click Yes if you receive a security warning, and then click OK twice to save your changes.

  6. Add a new Web Form to your Visual Basic ASP.NET application. Name the new form StepByStep11-6.aspx .

  7. Place a TextBox control with the ID of txtAuthenticatedUser on the form.

  8. Double-click the form to open its module. Add a reference at the top of the module:

    Imports System.Security.Principal

  9. Add this code to run when the page is loaded (you'll learn about the Identity and Principal objects in the next section of the chapter):

    Private Sub Page_Load(_ ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Dim wi As WindowsIdentity = _ WindowsIdentity.GetCurrent() txtAuthenticatedUser.Text = wi.Name End Sub

  10. Edit the web.config file to replace both the authentication and authorization sections as follows :

    <authentication mode="Windows"> </authentication> <authorization> <allow users="*" /> </authorization>

  11. Set the new Web Form as the start page for the project.

  12. Run the project. When prompted by your browser, log in using a Windows username and password. (Depending on your network configuration, you might not receive a login prompt at this point.) The form will display the name of the ASP.NET user (which will be something like DOMAIN\ASPNET ). That's because you don't have impersonation turned on at this point.

  13. Stop the project. Edit the web.config file to include impersonation:

    <authentication mode="Windows"> </authentication> <identity impersonate="true" /> <authorization> <allow users="*" /> </authorization>

  14. Run the project again. Log in using a Windows username and password. The form will display the username and domain that you supplied to authenticate, indicating that the ASP.NET process has taken on the identity of the authenticated user.

Identity and Principal Objects

Within a Visual Basic .NET application, authorization is handled by the role-based security system. Role-based security revolves around two interfaces: IIdentity and IPrincipal. For applications that use Windows accounts in role-based security, these interfaces are implemented by the WindowsIdentity and WindowsPrincipal objects, respectively.

NOTE

Custom Authorization If for some reason you want to develop a custom authorization scheme, you can implement IIdentity and IPrincipal in your own classes. In use, these classes will function very much like the Windows-based classes that I'll demonstrate in this chapter.

The WindowsIdentity object represents the Windows user who is running the current code. The properties of this object allow you to retrieve such information as the username and authentication method.

The WindowsPrincipal object adds functionality to the WindowsIdentity object. The WindowsPrincipal object represents the entire security context of the user who is running the current code, including any roles to which the user belongs. When the Common Language Runtime decides which role-based permissions to assign to your code, it inspects the WindowsPrincipal object.

Step by Step 11.7 demonstrates the use of the WindowsIdentity and WindowsPrincipal objects.

STEP BY STEP

11.7 WindowsIdentity and WindowsPrincipal

  1. Add a new form named StepByStep11-7.vb to the 310C11 Visual Basic .NET Windows application.

  2. Place a ListBox control named lbProperties and a Button control named btnGetProperties on the form.

  3. Double-click the Button control to open the form's module. Add this statement to the top of the module:

    Imports System.Security.Principal

  4. Add this code to retrieve properties when you click the Button control. In the last line of code, change the domain name DOMAIN to your own domain name, or omit it entirely if you aren't in a domain:

    Private Sub btnGetProperties_Click(_ ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles btnGetProperties.Click ' Tell the CLR which ' principal policy is in use AppDomain.CurrentDomain.SetPrincipalPolicy(_ PrincipalPolicy.WindowsPrincipal) lbProperties.Items.Clear() ' Get the current identity Dim wi As WindowsIdentity = _ WindowsIdentity.GetCurrent() ' Dump its properties to the listbox With lbProperties.Items .Add("WindowsIdentity:") .Add(" Authentication type: " & _ wi.AuthenticationType) .Add(" Is Anonymous: " & wi.IsAnonymous) .Add(" Is Authenticated: " & _ wi.IsAuthenticated) .Add(" Is Guest: " & wi.IsGuest) .Add(" Is System: " & wi.IsSystem) .Add(" Name: " & wi.Name) .Add(" Token: " & wi.Token.ToString) End With ' Get the current principal Dim prin As WindowsPrincipal = _ New WindowsPrincipal(wi) ' Dump its properties to the listbox With lbProperties.Items .Add(" Authentication Type: " & _ prin.Identity.AuthenticationType) .Add(" Is Authenticated: " & _ prin.Identity.IsAuthenticated) .Add(" Name: " & prin.Identity.Name) .Add(" Member of Domain Users: " & _ prin.IsInRole("DOMAIN\Domain Users")) End With End Sub

  5. Set the form as the startup object for the project.

  6. Run the project and click the button. You'll see output similar to that in Figure 11.8.

    Figure 11.8. The WindowsIdentity and WindowsPrincipal properties.

This code first tells the Common Language Runtime that you're using the standard Windows authentication method by calling the SetPrincipalPolicy method of the current AppDomain. It then retrieves the WindowsIdentity of the current user through the static GetCurrent method of the WindowsIdentity object. After displaying some of the properties of the WindowsIdentity object, it gets the corresponding WindowsPrincipal object by passing the WindowsIdentity object to the constructor of the WindowsPrincipal class.

WARNING

Modify the Domain Name This code contains a reference to a specific domain named LARKGROUP in its call to the IsInRole method. You should change that to the name of your own domain to test this code.

Note that the properties of the WindowsIdentity object are somewhat richer than those of the WindowsPrincipal object, but that the WindowsPrincipal object lets you evaluate role membership for the current user. If you only want to work with the WindowsPrincipal object, you can also retrieve it from the Thread.CurrentPrincipal static method.

Verifying Role Membership

One way to manage role-based security is to use the IsInRole method of the WindowsPrincipal object to determine whether the current user is in a specific Windows group (see Step By Step 11.8). The results of this method call can be used to modify your application's user interface or to perform other tasks .

STEP BY STEP

11.8 Verifying Role Membership

  1. Add a new form named StepByStep11-8.vb to your Visual Basic .NET application.

  2. Place a Label control named lblMembership on the form.

  3. Double-click the form to open its module. Add these statements to the top of the module:

    Imports System.Security.Principal Imports System.Threading

  4. Add this code to run when you load the form:

    Private Sub StepByStep11_8_Load(_ ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load ' Tell the CLR to use Windows security AppDomain.CurrentDomain.SetPrincipalPolicy(_ PrincipalPolicy.WindowsPrincipal) ' Get the current principal object Dim prin As WindowsPrincipal = _ Thread.CurrentPrincipal ' Determine whether the user is an admin Dim fAdmin As Boolean = prin.IsInRole(_ WindowsBuiltInRole.Administrator) ' Display the results on the UI If fAdmin Then lblMembership.Text = _ "You are in the Administrators group" Else lblMembership.Text = _ "You are not in the Administrators group" End If End Sub

  5. Set the form as the startup object for the project.

  6. Run the project. The form will tell you whether you're in the Administrators group or not.

Three overloaded forms of the IsInRole method are available:

Using the PrincipalPermission Class

An alternative way to manage identities is to perform imperative or declarative security checking with role-based security by using the PrincipalPermission class, as in Step By Step 11.9, or the PrincipalPermissionAttribute attribute.

STEP BY STEP

11.9 Using the PrincipalPermission Class

  1. Add a new form to your Visual Basic .NET application.

  2. Double-click the form to open its module. Add these statements to the top of the module:

    Imports System Imports System.Security.Permissions Imports System.Security.Principal

  3. Add this code to run when you load the form:

    Private Sub StepByStep11_9_Load(_ ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load ' Tell the CLR to use Windows security AppDomain.CurrentDomain.SetPrincipalPolicy(_ PrincipalPolicy.WindowsPrincipal) ' Create a new PrincipalPermission object ' This object matches any user ' in a group named Developers Dim pp As PrincipalPermission = _ New PrincipalPermission(_ Nothing, "Developers") ' See if the user is in the group Try pp.Demand() MessageBox.Show(_ "You are in the Developers group") Catch ex As Exception MessageBox.Show("Exception: " & ex.Message) End Try End Sub

  4. Set the form as the startup object for the project.

  5. Run the project. If you're a member of a group named Developers, you'll see a message box telling you so. If not, you'll see a Security Exception message from the PrincipalPermission class, telling you that the requested permission could not be granted.

Checking permissions with role-based security is similar to checking permissions with code access security. The difference lies in what you are checking. The constructor for the PrincipalPermission class accepts both a name and a group name, so you can also use it to check whether a specific user is running the code.

REVIEW BREAK

  • The .NET Framework supports both authentication and authorization. Authentication refers to verifying a user's identity. Authorization refers to granting rights based on that identity.

  • Users must satisfy any IIS authentication requirements before ASP.NET authentication takes over.

  • ASP.NET authentication uses interchangeable authentication providers. You can choose Windows authentication, Passport authentication, or forms-based authentication.

  • Identity impersonation lets the ASP.NET process act as the authenticated user.

  • The WindowsPrincipal and WindowsIdentity classes let you check the authentication status of the current user.

  • You can use the IsInRole method of the WindowsPrincipal object to check for membership in Windows groups.

  • The PrincipalPermission class allows you to perform declarative or imperative role-based security operations.

   
Top
Related

Категории