您如何保护和计量与业务合作伙伴共享的Web服务?

时间:2009-10-01 14:24:57

标签: .net service

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

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

我很擅长提供软件即服务,并且非常喜欢一些建议,包括我可以检查提示的开源.Net项目。

编辑:现在有了丰厚的新鲜感!

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

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

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

我不想调查我们的合作伙伴他们更喜欢哪种格式/协议,因为其中一项要求是能够在没有IT参与的情况下添加新合作伙伴。我想了解一些关于最佳实践的技巧,以便我们以“正确”的方式做到这一点,并且他们可以遵守。

5 个答案:

答案 0 :(得分:3)

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

答案 1 :(得分: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商店 - 远非科学方法。)

答案 2 :(得分:0)

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

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

通常,通过软件即服务,您可以通过其帐户管理用户。一个帐户有一个功能包,它定义了可用的功能,使用的资源的引用以及定义可以做什么和不能做什么的访问权限。

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

为了了解最适合您的方法,您需要决定希望业务合作伙伴开展哪些活动。

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

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

关于格式,我认为这与讨论无关,而且有点太早思考。您可能希望向合作伙伴询问他们的偏好。

答案 3 :(得分:0)

要限制对Web服务的访问,可以选择基于自定义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 Services堆栈是否足以提供有价值的指示。

关于通话记录,我没有看到任何特别的困难。一旦实施了限制访问,您将找到要记录的内容和位置。

答案 4 :(得分:0)

实施访问限制

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

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

    这将是这样的......

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