【问题标题】:Web services and authentication & authorization dilemmaWeb服务和认证授权困境
【发布时间】:2015-09-21 22:38:57
【问题描述】:

当前设置:

  • App2 是一个现有的 Web 应用程序,旨在使用户能够执行 交易。已登录。全球访问。
  • App1 是一个纯信息应用程序,无需登录。全球访问。

建议的更改:

  • App1 现在将有用户登录和一些新功能
  • 它的部分新功能是拥有一些事务性后端 应用程序2

计划

  • 在 App2 中创建 Web 服务以公开可访问的功能 由 App1 提供。

困境

  • App2 暴露的 web 服务只能被登录的用户使用 来自 App1 的用户。

设置

  • App1 和 App2 部署在同一个应用服务器上(并且可能会在很长一段时间内进行此设置)
  • App1 和 App2 拥有来自不同数据库的不同用户集。

问题:

  1. 解决困境的最佳方法是什么?
  2. 将 App2 的后端复制到 App1 中是否可行?
  3. 将这两个应用程序作为单点登录也是一个实际的选择吗? (例如,在 SSO 下,只需在 App1 中提供指向 App2 的直接页面链接。)

就是这样。谢谢。任何建议将不胜感激。

【问题讨论】:

    标签: web-services security single-sign-on ws-security


    【解决方案1】:

    此问题的解决方案是任何token based authentication 解决方案的一部分。

    在您的用户对 App1 进行身份验证后,您允许他们检索令牌以访问 App2 中的 API。此令牌必须经过签名(以防止篡改)并包含依赖方标识符或受众 URI。

    您在 App2 中公开的 API 检查令牌是否有效并用于调用它(具有正确的依赖方标识符或受众 URI)。

    【讨论】:

    • 您的意思是 CSRF 预防的相同概念?由于两个不同的应用程序将引用相同的令牌,如果此令牌临时保存在数据库中可以吗?如果不使用像 OAuth 这样的第三方,这可能吗?
    • 我说的是不记名令牌,而不是 CSRF 令牌。您的 STS 会专门为您要调用的 API 颁发令牌。令牌内的声明之一将指示令牌的用途(观众或依赖方)。您可以使用任何 STS 执行此操作,无需特别需要 OAuth。您也不需要在数据库中存储任何内容,因为令牌包含您需要的所有声明。
    • 所以概念是,在调用 Web 服务 api 之前,客户端请求一个令牌,然后将其与 msg 请求一起提交。令牌中允许的用户名是否允许访问 api?我没听错吗?
    • 是的,为每个用户颁发一个令牌,因此它只包含使用该服务的用户的用户名。它还包含其他信息,例如令牌有效的时间范围、令牌的颁发者以及令牌的用途。
    • 客户端生成token?
    猜你喜欢
    • 2015-07-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-07-17
    • 1970-01-01
    • 1970-01-01
    • 2011-11-10
    • 1970-01-01
    相关资源
    最近更新 更多