none
客户端认证方式None,在契约内部手工认证用户名与密码,与常规UserName认证在安全上来说有什么异同呢? RRS feed

  • 问题

  • 客户端认证方式None,在契约内部手工认证用户名与密码,与常规UserName认证在安全上来说有什么异同呢?
    2010年9月1日 3:20

答案

  • 你所说的常规UserName认证是定义在WS-Security规范里的,具有良好的交互性,而且WCF已经实现了此标准,你所作的就是配置一下,方便实用。 相比之下,通过契约方法来传递用户凭证,服务端的验证部分要完全自己实现,而且验证方式对客户端来说也不可见,除非写文档告知。

    总之,尽量用Ws-security定义的UserName验证把。


    Mog Liang
    • 已标记为答案 wyssoft 2010年9月3日 7:40
    2010年9月2日 3:14
  • 谢谢。
    真不知道UserName还是安全规范。呵,其实用它也挺好,但总觉得实现方式上被套牢,不舒服,所以我打算只把WCF作为一个传输平台,至于怎么实现业务流程包括用户验证都靠自己来实现。但还是有些提心安全上漏洞。


    自己开发单独的服务来进行UserName的验证还是有问题的。

    仍然无法解决一些常见的安全问题,比如数据加密,也就数据机密性、不被修改,也就是一致性,不丢失,也就是完整性。

    另外你自己实现的WCF操作,实际客户端的每次调用都要实例化服务,不然无法进行验证。

    这个和实际的WCF验证机制不一样,WCF的验证发生在服务实例化以前。


    Frank Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
     

    老徐的网站】:http://www.frankxulei.com/

    老徐的博客】:http://www.cnblogs.com/frank_xl/

    微软WCF中文技术论坛
    微软WCF英文技术论坛

    • 已标记为答案 wyssoft 2010年9月3日 7:40
    2010年9月2日 14:55
    版主

全部回复

  • 你所说的常规UserName认证是定义在WS-Security规范里的,具有良好的交互性,而且WCF已经实现了此标准,你所作的就是配置一下,方便实用。 相比之下,通过契约方法来传递用户凭证,服务端的验证部分要完全自己实现,而且验证方式对客户端来说也不可见,除非写文档告知。

    总之,尽量用Ws-security定义的UserName验证把。


    Mog Liang
    • 已标记为答案 wyssoft 2010年9月3日 7:40
    2010年9月2日 3:14
  • 谢谢。
    真不知道UserName还是安全规范。呵,其实用它也挺好,但总觉得实现方式上被套牢,不舒服,所以我打算只把WCF作为一个传输平台,至于怎么实现业务流程包括用户验证都靠自己来实现。但还是有些提心安全上漏洞。
    2010年9月2日 5:53
  • 谢谢。
    真不知道UserName还是安全规范。呵,其实用它也挺好,但总觉得实现方式上被套牢,不舒服,所以我打算只把WCF作为一个传输平台,至于怎么实现业务流程包括用户验证都靠自己来实现。但还是有些提心安全上漏洞。


    自己开发单独的服务来进行UserName的验证还是有问题的。

    仍然无法解决一些常见的安全问题,比如数据加密,也就数据机密性、不被修改,也就是一致性,不丢失,也就是完整性。

    另外你自己实现的WCF操作,实际客户端的每次调用都要实例化服务,不然无法进行验证。

    这个和实际的WCF验证机制不一样,WCF的验证发生在服务实例化以前。


    Frank Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
     

    老徐的网站】:http://www.frankxulei.com/

    老徐的博客】:http://www.cnblogs.com/frank_xl/

    微软WCF中文技术论坛
    微软WCF英文技术论坛

    • 已标记为答案 wyssoft 2010年9月3日 7:40
    2010年9月2日 14:55
    版主
  • 谢谢。
    真不知道UserName还是安全规范。呵,其实用它也挺好,但总觉得实现方式上被套牢,不舒服,所以我打算只把WCF作为一个传输平台,至于怎么实现业务流程包括用户验证都靠自己来实现。但还是有些提心安全上漏洞。


    自己开发单独的服务来进行UserName的验证还是有问题的。

    仍然无法解决一些常见的安全问题,比如数据加密,也就数据机密性、不被修改,也就是一致性,不丢失,也就是完整性。

    另外你自己实现的WCF操作,实际客户端的每次调用都要实例化服务,不然无法进行验证。

    这个和实际的WCF验证机制不一样,WCF的验证发生在服务实例化以前。


    Frank Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
     

    老徐的网站】:http://www.frankxulei.com/

    老徐的博客】:http://www.cnblogs.com/frank_xl/

    微软WCF中文技术论坛
    微软WCF英文技术论坛


    “仍然无法解决一些常见的安全问题,比如数据加密,也就数据机密性、不被修改,也就是一致性,不丢失,也就是完整性。”

    设置为SecurityMode.Message,应该可以避免吧。你说的“WCF的验证发生在服务实例化以前”这个对比自实现应该可以减少验证的开支吧。

    2010年9月3日 0:17
  • 谢谢。
    真不知道UserName还是安全规范。呵,其实用它也挺好,但总觉得实现方式上被套牢,不舒服,所以我打算只把WCF作为一个传输平台,至于怎么实现业务流程包括用户验证都靠自己来实现。但还是有些提心安全上漏洞。


    自己开发单独的服务来进行UserName的验证还是有问题的。

    仍然无法解决一些常见的安全问题,比如数据加密,也就数据机密性、不被修改,也就是一致性,不丢失,也就是完整性。

    另外你自己实现的WCF操作,实际客户端的每次调用都要实例化服务,不然无法进行验证。

    这个和实际的WCF验证机制不一样,WCF的验证发生在服务实例化以前。


    Frank Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
     

    老徐的网站】:http://www.frankxulei.com/

    老徐的博客】:http://www.cnblogs.com/frank_xl/

    微软WCF中文技术论坛
    微软WCF英文技术论坛


    “仍然无法解决一些常见的安全问题,比如数据加密,也就数据机密性、不被修改,也就是一致性,不丢失,也就是完整性。”

    设置为SecurityMode.Message,应该可以避免吧。你说的“WCF的验证发生在服务实例化以前”这个对比自实现应该可以减少验证的开支吧。

    是的。

    WCF这里支持WS-Security规范,你担心的或者考虑的问题,这些规范都有解决方案。


    Frank Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
     

    老徐的网站】:http://www.frankxulei.com/

    老徐的博客】:http://www.cnblogs.com/frank_xl/

    微软WCF中文技术论坛
    微软WCF英文技术论坛

    2010年9月5日 2:42
    版主