【问题标题】:How do you secure and meter the web services you share with your business partners?您如何保护和计量您与业务合作伙伴共享的 Web 服务?
【发布时间】:2009-10-08 13:47:08
【问题描述】:

我正在寻找有关如何限制对我们为业务合作伙伴提供的 API 的访问和记录调用的想法,以便与我们的客户关怀应用程序进行交互。我们是否应该像为自己的员工一样为外部合作伙伴创建用户名和密码? .Net 是否有某种管理单元层可以管理访问限制和计量,还是我们必须自己推出?

我们应该支持哪些格式? JSON 是规范的还是我需要了解一些新事物?

我是提供软件即服务的新手,我希望得到一些建议,包括我可以检查以获取提示的开源 .Net 项目。

编辑:现在充满新鲜感!

编辑:添加内容以回答一些问题

这将是我们的合作伙伴用来访问我们的客户服务功能的 API,例如创建新帐户、付款和其他帐户管理功能。

我熟悉 PostSharp,并且已经制作了一个技术演示,其中包含方法调用的日志记录功能。

我对调查我们的合作伙伴更喜欢哪种格式/协议不感兴趣,因为其中一项要求是能够在没有 IT 参与的情况下添加新的合作伙伴。我只是想要一些关于最佳做法的提示,以便我们以“正确”的方式进行操作,并且他们可以遵守。

【问题讨论】:

    标签: .net service


    【解决方案1】:

    我们一直在使用3scale。它允许计量和限制对您的 API 的访问。

    【讨论】:

    • 恭喜,兄弟。在所有答案中,我得到了最大的吸引力,尽管它很简短。我们目前正在评估与 3Scale 的合作伙伴关系,以处理大量我不得不自己动手做的事情。不要把代表都花在一个地方。
    【解决方案2】:

    你不是很清楚谁是合伙人;或者您是否正在保护对数据的访问、限制 API 调用,或两者兼而有之。

    您正在做的事情可能非常适合您的业务。假设您需要保护服务提供访问权限的数据,您需要对每个用户进行身份验证并保护传输层。对于前者,您需要拥有最终用户的用户名和密码或唯一的 API 令牌。这应该在每个请求上进行检查。如果您对服务使用 HTTP,则可以使用 SSL 启用传输安全性。在 Web 服务器级别启用此功能通常是最简单的,您不会提及您正在做任何特殊的 Web 服务托管。

    假设这种安全性已经到位,它应该为审计提供基础,这就是我假设您所说的日志调用的意思。用户名或 API 令牌将让您了解谁在进行调用,这是审计的基础。接下来创建一个您希望查看审计跟踪的数据列表。询问业务用户记录的信息是否可以帮助处理您的问题(是什么促使您添加记录)。

    接下来要考虑的是日志记录代码应该去哪里(有中心点吗?你使用 AOP 来添加它吗?),以及审计跟踪应该记录到哪里。有像 PostSharp 这样的工具,可以让您在应用程序中编织日志,而无需进行大量修改,但在执行此操作之前,请查看是否有一种简单的方法可以将日志功能添加到应用程序的公共位置以“捕获”信息你需要。

    一旦您掌握了数据,您就需要将其保存在某个地方。这就是事情变得有趣的地方。您需要了解应用程序的性能特征,以及可能的使用模式。在许多应用程序中,只记录到数据库是可以的,但有时这将是一个性能问题。记录到文本文件对某些人来说是可以的,但如果数据需要关联回您的用户数据库怎么办?在这种情况下,您需要一些代码来处理日志文件和导入数据。

    在您花太多时间构建任何日志记录代码之前,值得先看看NLogLog4Net 和企业库logging block。这些是通用工具,可以提供更好的基础。

    如果您需要强制执行用户配额,您可能需要考虑处理日志的速度,以确定用户进行了多少次调用。理想情况下,每次处理传入请求时,您都将掌握用户的当前状态,以便能够返回适当的响应。可以努力将此功能添加到现有应用程序中,并提供“基础设施”来支持它。

    是否使用 REST、JSON、XML、SOAP 等实际上取决于您的受众。他们会使用 Ruby 和 Python 之类的语言来调用您的服务,还是会使用 .NET?如果他们主要是 .NET 用户,那么使用 JSON 构建纯 REST 接口可能没有多大意义,因为 .NET 使 SOAP 变得非常容易。另一方面,如果您在客户端使用 JavaScript,那么 SOAP 和 XML 就很糟糕。请记住,如果没有更多关于用户的信息,就没有正确的答案。一般来说,JSON 不是万能的,XML 也并非总是最糟糕的选择。

    更新

    我没有兴趣调查我们的 合作伙伴的格式/协议 他们更喜欢,因为其中一个 要求是添加新的能力 没有 IT 参与的合作伙伴。 ID 就像一些关于最佳实践的提示一样, 以便我们以“正确”的方式进行操作 他们可以顺从。

    最灵活的选项可能是 REST 和 XML。由于几乎所有平台都有 HTTP 堆栈,因此得到了最广泛的支持。 XML 可以说比 JSON 更灵活地表示您的数据。我会从这里开始并在支持方面工作,可能会添加 JSON。然而,这不是我所说的以客户为中心的方法。如果这是平台的核心功能,那么您应该真正对客户的需求感兴趣。嘿,即使你今天做一个快速调查,至少你会有一个更合理的起点。如果您认识合作伙伴的任何开发人员,那么您可能能够从他们使用的工具和语言中推测出他们更喜欢什么(甚至查看他们的招聘广告可能会让您了解他们是 .NET 还是 Java购物 - 虽然远非科学方法)。

    【讨论】:

      【解决方案3】:

      我认为你需要明确你的想法。

      软件即服务意味着您为用户提供了一个工作软件,以便他们处理他们自己的数据,同时将您的软件用作操作该数据的工具。在这里,用户通常对您可以提供的数据不感兴趣(这对他们来说毫无用处)。 SaaS 只是他们的替代解决方案。他们还可以在本地、在他们的网络中开发/安装满足他们需求的软件,因为他们的主要兴趣是他们的数据,他们只需要一个工具来处理它。

      通常,对于软件即服务,您可以通过用户的帐户来管理用户。帐户有一个功能包,其中定义了可用功能、所用资源的报价以及定义可以做什么和不能做什么的访问权限。

      您所描述的基本上是对您的数据的外部访问。它与 SaaS 的概念几乎没有共同之处。例如,GeoIP 定位服务有同样的问题,允许访问他们的数据库,但监控每个用户的使用情况(例如,一个帐户允许每个用户每月 1000 次地理定位请求)。

      为了了解什么对您最有效,您需要决定您希望允许您的业务合作伙伴开展什么样的活动。

      • 他们只是想读取您的数据吗?如果这是一个简单的数据消耗问题,那么您可能可以摆脱使用具有使用限制的基本用户帐户。根据您关于首选数据格式的问题猜测,我想这是您的情况。

      • 他们是否打算积极参与客户服务流程并添加、删除、修改或以其他方式处理数据?在这种情况下,您需要考虑系统的设计,并设计(如果还没有)用户、组、访问权限和配额的系统。您将为您的业务合作伙伴创建帐户,同时定义允许的活动、使用限制等。然后您需要更新您的代码库以查看这些参数。

      关于格式,我认为与本次讨论无关,想起来还为时过早。您不妨问问您的合作伙伴他们更喜欢什么。

      【讨论】:

        【解决方案4】:

        要限制对您的网络服务的访问,可以选择实施基于自定义soap 标头的自定义身份验证机制。它并不复杂,您不会牺牲互操作性。网上有很多文章可以做到这一点,例如:Build Secure Web Services With SOAP Headers and ExtensionsAuthenticate .NET web service with custom SOAP Header 等。

        或者您可以查看 WS-Security 和即将推出的 WS-Authorization 来处理标识、身份验证和授权等概念(请参阅An Overview of the WS-Security Framework)。但实际上,我对 Microsoft Web 服务堆栈的了解不够深入,无法提供有价值的指导。

        关于通话记录,我看不出有什么特别的困难。实施限制访问后,您将了解要记录的内容和位置。

        【讨论】:

          【解决方案5】:

          用于实施访问限制

          • 我建议您实施自己的策略。我们之前有类似的要求,我们已经实现了以下方法

            • 第一级:需要为每个请求提供用户名和密码。
            • 第二级:会话密钥 (GUID) 必须随每个请求一起传递。
            • 3 级:资源级权限 - 需要传递特定的密钥代码才能访问资源。为此,您需要针对每个资源维护每个客户的权限集。这使您可以限制具有有限访问权限的客户。

            这将是这样的..

            if (base.IsUserValid(userObject))
            {
             if (base.ValidateSession("sessionid"))
             {
               if (base.IsUserAuthorizedToAccessResource("resourcekey","ReadorWrite"))
               {             
                     //Grant Access
               }
              }
            }
            
          • 如果客户使用 .Net 技术,我建议您使用基于 SOAP/XML 的服务。 REST/JSON 最适合使用其他技术的客户。但这完全取决于您的客户需求。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2021-10-30
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2019-09-17
            • 2011-02-17
            相关资源
            最近更新 更多