WCF 第八章 安全 确定替代身份(中)-使用AzMan认证

Windows 认证管理器(AzMan)是一个向应用程序提供基于中央(因此容易维护)角色授权服务的系统，包括WCF，基于定义在认证中心的权限。AzMan使用一个基于MMC实例来管理认证中心和相关访问级别。认证管理器运行时是与物理授权中心独立的，物理授权中心可能基于SQL Server, 活动目录，ADAM或者XML,取决于操作系统使用的类型。

  在这一部分，我们将使用一个简单的XML认证中心来配置基于角色的访问我们先前服务的例子。为了与认证管理器一起工作,我们使用微软管理控制台(MMC)并保证认证管理器通过文件被添加，添加/移除管理选项。

  为了创建一个认证中心，你必须在开发者模式(相对管理模式)，允许访问所有特性。从操作菜单，选择选项，然后选择开发者模式。在开发者模式，右键认证管理器节点然后选择新建认证中心，这将打开一个类似于图片8.3的对话框。

  对我们的例子来说，选择XML文件，保留元数据版本为1.0，给存储中心设定名字和描述。注意，取决于操作系统的不同，你可能也会使用活动目录，ADAM或者SQL Server.

  创建完认证中心，确保XML文件是高亮的，然后右键并选择新建应用。将应用命名为AzManDemo然后点击OK。

  为了定义我们将绑定用户权限的角色，在左边面板展开AzManDemo,然后展开定义。右键角色定义并选择新的角色定义。我们将创建两种角色，Member角色和Admin角色；然而，为了以后需要，在新建角色定义会话框点击添加并选择Member角色来将角色作为Admin角色定义的一部分，如图8.4显示。

  为了将用户绑定到角色，右键角色绑定节点并选择新建角色绑定。Admin和Member角色应该出现在角色绑定下面。右键每个角色然后选择绑定用户和组，然后是Windows和活动目录。添加示例"Peter"帐户到Admin 角色并添加"Jessica"到Member 角色。最后配置应该与图片8.5类似。

  现在认证管理器已经使用一个角色和用户绑定配置，我们可以告诉WCF来使用AzMan认证。WCF的灵活性与兼容性通过AzRoles程序集访问AzMan运行时给我们很大的选择。例如，我们可以创建一个自定义ServiceAuthorizationManager并手动调用AzRoles程序集来进行角色和操作认证。然而，通过使用现有的ASP.NET 2.0 功能，我们可以将AzMan认证与WCF集成到一起并实现较小的损耗。

  ASP.NET 的机遇角色的提供系统在这里对我们很有用因为WCF可以自动与它的服务集成因为有一个原来的AuthorizationStoreRoleProvider我们可以用来与我们的AzMan创建的认证中心通信。

  为了使用认证管理器，在SampleHost工程的App.config文件中，我们需要在<system.web>下添加<roleManager>节点.服务的行为需要包含<serviceAutorization>来允许使用ASP.NET 角色和AuthorizationStoreProleProvider.我们也需要在<connectionStrings>节点中确定到XML认证中心的路径。这些设置在列表8.23中显示。

列表8.23 TCP授权集成管理中心的服务配置

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings>
    <add name="AuthorizationStore" connectionString="msxml://C:\AzManSample\XMLAuthorizationStore.xml"/>
  </connectionStrings>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="ServiceBehavior">
                    <serviceAuthorization principalPermissionMode="UseAspNetRoles"
                        roleProviderName="AuthorizationStoreRoleProvider" />
                    <serviceMetadata httpGetEnabled="true" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <services>
            <service behaviorConfiguration="ServiceBehavior" name="SampleService.Samples">
                <endpoint address="" binding="netTcpBinding" bindingConfiguration=""
                    name="netTcp" contract="SampleService.ISamples" />
                <endpoint address="mex" binding="mexHttpBinding" bindingConfiguration=""
                    name="mex" contract="IMetadataExchange" />
                <host>
                    <baseAddresses>
                        <add baseAddress="http://localhost:8080/Samples" />
                        <add baseAddress="net.tcp://localhost:8090/Samples" />
                    </baseAddresses>
                </host>
            </service>
        </services>
    </system.serviceModel>
  <system.web>
    <roleManager 
      defaultProvider="AuthorizationStoreRoleProvider" 
      enabled="true" cacheRolesInCookie="true" 
      cookieName=".ASPROLES" cookiePath="/" 
      cookieProtection="All" cookieRequireSSL="false" 
      cookieSlidingExpiration="true" cookieTimeout="30">
      <providers>
        <clear/>
        <add name="AuthorizationStoreRoleProvider" 
             type="System.Web.Security.AuthorizationStoreRoleProvider"
             connectionStringName="AuthorizationStore"
             applicationName="AzManDemo" />
      </providers>
    </roleManager>
  </system.web>
</configuration>

  最后，为了将操作绑定到具体授权管理组，需要将PrincipalPermissionAttribute修改成引用包含在授权中心的角色定义。在之前的Windows组例子基础上修改，将角色名字从Sample Admins和Sample Members改为Admin Role 和Member Role,对应的，通过AzMan实例使给定的名字匹配。

再次为每个用户(Peter 和 Jessica)运行这个应用程序，结果应该也是Peter 有无限制访问而Jessica不能调用GetSecretCode方法。然而，现在AzMan已经配置位可以访问，我们可以使用这个方便的工具和认证中心来为向我们的服务本身做很少的改动并为我们的应用程序维护角色，用户，任务和操作。