配色: 字号:
谈谈WCF的客户端认证(用户名、密码认证)
2016-09-29 | 阅:  转:  |  分享 
  
谈谈WCF的客户端认证[用户名/密码认证]

对于基于Internet的应用,基于用户名和密码的认证方式是最为常用的,而WCF为你提供了不同模式的用户名认证方式。首先还是从用户凭证的表示说起。



一、用户名/密码认证的三种模式

基于用户名/密码的用户凭证通过类型UserNamePasswordClientCredential表示。而在ClientCredentials中,只读属性UserName表示这样一个用户凭证。你可以按照Windows凭证的方式为ChannelFactory或者ClientBase基于用户名/密码凭证。



1:publicclassClientCredentials

2:{

3://其他成员

4:publicUserNamePasswordClientCredentialUserName{get;}

5:}

6:publicsealedclassUserNamePasswordClientCredential

7:{

8://其他成员

9:publicstringPassword{get;set;}

10:publicstringUserName{get;set;}

11:}

用户名/密码凭证在客户端的设置很容易,但是我们关心的是服务端采用怎样的机制来验证这个凭证。WCF为你提供了如下三种方式来验证凭证中用户名是否和密码相符:



Windows:将用户名和密码映射为Windows帐号和密码,采用Windows认证;

MembershipProvider:利用配置的MembershipProvider验证用户名和密码;

自定义:通过继承抽象类UsernamePasswordValidator,自定义用户名/密码验证器进行验证。

WCF通过枚举UserNamePasswordValidationMode定了上述三种用户名/密码认证模式。该枚举定义如下,其中Windows是默认选项。



1:publicenumUserNamePasswordValidationMode

2:{

3:Windows,

4:MembershipProvider,

5:Custom

6:}

上述三种认证模式的设置最终通过之前提到过的ServiceCredentials这一服务行为进行设置的。从下面的定义我们可以看出,ServiceCredentials定义了只读属性UserNameAuthentication用于基于用户名/密码认证的相关设置。属性的类型为UserNamePasswordServiceCredential,定义其中的UserNamePasswordValidationMode属性表示采用的认证模式。如果选择了需要通过属性MembershipProvider设置采用的MembershipProvider。如果选择了Custom,则需要通过CustomUserNamePasswordValidator属性指定你自定义的UserNamePasswordValidator对象。



1:publicclassServiceCredentials:SecurityCredentialsManager,IServiceBehavior

2:{

3://其他成员

4:publicUserNamePasswordServiceCredentialUserNameAuthentication{get;}

5:}

6:publicsealedclassUserNamePasswordServiceCredential

7:{

8://其他成员

9:publicUserNamePasswordValidatorCustomUserNamePasswordValidator{get;set;}

10:publicMembershipProviderMembershipProvider{get;set;}

11:publicUserNamePasswordValidationModeUserNamePasswordValidationMode{get;set;}

12:}

接下来我们通过实例演示的方式来如何通过MembershipProvider进行基于用户名/密码认证,而对于自定义UserNamePasswordValidator的实例我会在介绍安全会话的时候进行演示。



二、实例演示:通过MembershipProvider进行用户名/密码的认证

Membership是ASP.NET中一个重要的模块,旨在进行基于用户名/密码的认证和对应的帐号管理。Membership采用策略设计模式,所有的API通过几个静态Membership类暴露出来,而相应的功能实现在具体的Membership提供者中。所有的提供者继承自同一个抽象类MembershipProvider。ASP.NET提供了两种类型的提供者:SqlMembershipProvider和ActiveDirectoryMembershipProvider。前者将用户存储于SQLServer数据库中,而后者则直接建立在AD之上,本实例采用SqlMembershipProvider,在前面一个实例演示中,我们创建了以计算服务为场景的解决方案,现在我们直接沿用它。



我们首要的任务是在用于存储帐户信息的SQLServer数据库,为此你可以先在本地SQLServer创建一个空的数据库(假设起名为AspNetDb)。你接着需要在该数据库中创建SqlMembershipProvider所需的数据表和相应的存储过程。这些数据库对象的创建,需要借助aspnet_regsql.exe这个工具。你只需要以命令行的方式执行如下aspnet_regsql.exe(无需任何参数),相应的向导就会出现。



在向导弹出的前两个窗体中保持默认设置,直接点击“下一步”后,会出现一个数据库选择窗体。此时你需要选择我们刚刚创建的数据库,点击“确认”后,相关的数据库对象会为你创建出来。



这些创建出来的数据表可以同时服务于多个应用,所有每一个表中都具有一个名称为ApplicationId的字段来明确该条记录对应的应用。而所有应用记录维护在aspnet_Applications这么一个表中。现在我们需要通过执行下面一段SQL脚本在该表中添加一条表示我们应用的记录。我们应用起名为MembershipAuthenticationDemo。



1:INSERTINTO[aspnet_Applications]

2:([ApplicationName]

3:,[LoweredApplicationName]

4:,[ApplicationId]

5:,[Description])

6:VALUES

7:(

8:''MembershipAuthenticationDemo''

9:,''membershipauthenticationdemo''

10:,NEWID()

11:,''''

12:)

现在数据库方面已经准备就绪,我们接着来完成编程和配置方面的工作。我们不打算从新创建一个解决方案,而是直接对之前演示的实例进行改造。我们采用自我寄宿的方式,由于Membership隶属于ASP.NET,所以我们需要添加System.Web.dll的引用,如果你采用的是.NETFrameowrk4.0(本例所示的配置也是基于该版本),你还需额外添加对System.Web.ApplicationServices.dll的引用。接下来,我们需要在服务寄宿方面所做的工作就是将下面一段配置整个拷贝到app.config中。



1:

2:

3:

4:

5:


6:

7:

8:

9:
10:connectionStringName="AspNetDb"applicationName="MembershipAuthenticationDemo"requiresQuestionAndAnswer="false"/>

11:


12:

13:


14:

15:

16:

17:

18:

19:

20:

21:

22:


23:


24:

25:

26:

27:

28:


29:

30:

31:

32:

33:

34:

35:


36:

37:


38:


39:


40:


考虑到有些人可能对ASP.NET下的Membership相关配置不太了解,在这里我对上述这段配置进行以下简单的说明。



配置名称为AspNetDb的连接字符串连接的是我们刚刚创建的数据库,并通过aspnet_regsql.exe工具在该数据库中创建了所需的数据库对象;

表示Membership配置节的/节点下配置了唯一的SqlMembershipProvider,配置名称为myProvider。上面配置的连接字符创名称AspNetDb配置在connectionStringName属性中,意味着该SqlMembershipProvider会将我们创建的数据库作为用户帐号存储;

服务终结点采用WS2007HttpBinding,采用Message安全模式,客户端凭证类型被设置为UserName;

服务应用了一个配置名称为membershipAuthentication的服务行为,该行为中通过节点设置了服务证书。在表示用户名/密码认证配置的节点中,将认证模式设置成MembershipProvider,而membershipProviderName属性的值为我们在/中设置的MembershipProvider的名称。

到目前为止,在我们创建的数据库中并没有用户帐户记录。为了演示认证的效果,我们必须创建相关用户帐户记录。为了省事,我直接将相关的代码写在了服务寄宿的代码中。如下面的代码片断所示,在对服务进行寄宿之前,我通过调用Membership的静态方法CreateUser创建了一个用户名、密码和Email分别为Zhansan、Pass@word和zhanshan@gmail.com的帐号。



1:if(Membership.FindUsersByName("Zhansan").Count==0)

2:{

3:Membership.CreateUser("Zhansan","Pass@word","zhanshan@gmail.com");

4:}

5:using(ServiceHosthost=newServiceHost(typeof(CalculatorService)))

6:{

7:host.Open();

8:Console.Read();

9:}

接下来我们需要对客户端的配置进行相应的调整,整个配置内容如下面的XML片断所示。对于这段配置有一点需要注意的是:终结点应用了一个名称为peerTrustSvcCertValidation的行为,该行为中将服务证书认证模式设置成PeerTrust,所以你需要通过MMC证书管理单元的导出/导入功能将Jinnan-PC证书导入到“受信任人(TrustedPeople)”存储区。



1:

2:

3:

4:

5:

6:

7:

8:

9:

10:

11:


12:


13:

14:

15:

16:

17:


18:

19:


20:

21:

22:

23:

24:

25:

26:


27:


28:

29:


30:


31:


32:


最后,我么来编写如下一段客户端进行服务调用的程序。在下面的代码中,我进行了两次服务调用。但是创建服务代理对象的ChannelFactory被设置了不同的用户名凭证。其中第一个是正确的用户名和密码,后一个却指定了一个根本不存在的用户名。



1:using(ChannelFactorychannelFactory=newChannelFactory("calculatorService"))

2:{

3:UserNamePasswordClientCredentialcredential=channelFactory.Credentials.UserName;

4:credential.UserName="Zhansan";

5:credential.Password="Pass@word";

6:ICalculatorcalculator=channelFactory.CreateChannel();

7:calculator.Add(1,2);

8:Console.WriteLine("服务调用成功...");

9:}

10:using(ChannelFactorychannelFactory=newChannelFactory("calculatorService"))

11:{

12:UserNamePasswordClientCredentialcredential=channelFactory.Credentials.UserName;

13:credential.UserName="lisi";

14:credential.Password="Pass@word";

15:ICalculatorcalculator=channelFactory.CreateChannel();

16:try

17:{

18:calculator.Add(1,2);

19:}

20:catch

21:{

22:Console.WriteLine("服务调用失败...");

23:}

24:}

输出结果:



1:服务调用成功...

2:服务调用失败...

献花(0)
+1
(本文系thedust79首藏)