asp.net 来自 WebApi 的 SSO 和 SAML 仅仅是因为客户端只有这些

asp.net SSO and SAML from WebApi simply because that is all the client has

我继承了这一点,并坚持使用这种方法。我只是想弄清楚它是否真的有效。

该项目涉及带有 android 和 ios 客户端的标准 asp.net 网络 api 应用程序。诀窍在于身份验证。该应用程序适用于第 3 方,并且可以从外部世界对用户进行身份验证的唯一方法是使用他们的 IDP。第 3 方不关心用户通过身份验证后会发生什么。 我所需要的只是前团队成员创建的架构图。该图有 3 层。 User/Mobile 设备、SAML SP Web APP 和客户端 IDP。流程的重要部分如下:

  1. 移动应用程序使用 IDP 用户名和密码调用 SAML SP Web 应用程序。
  2. SAML Web App 使用用户凭据调用 IDP 登录
  3. 用户已验证?成功响应 SAML SP Web App 和 SAML Assertion/Token
  4. SAML SP Web 应用程序以已批准的消息响应移动应用程序

一旦用户通过 IDP 进行身份验证,计划就是向移动设备颁发不记名令牌。

除非自从我上次不得不使用 SAML (2011) 以来事情发生了很大变化,否则我似乎缺少客户端浏览器来从 SP 重定向到 IDP,然后在有效的 SAMl 时重定向回 SP断言已创建。

我是否遗漏了一些东西,例如模拟浏览器以允许这些重定向并插入正确的用户名和密码的方法,或者是否有直接从 SP 调用 IDP 并拥有它的方法直接发回SP回复?或者我只是错误地阅读了图表或继承了一些非常糟糕的假设?我处于一个尴尬的境地,我不想回到客户那里重新审视一个应该在年初决定的流程,除非我绝对必须这样做。

SAML 的变化不大,因此您 2011 年的知识仍然绝对有效。

我还缺少浏览器重定向步骤。 SP 可以向 Idp 发送 username/password 并返回断言,这是一个很常见的误解,但 SAML WebSSO 配置文件(实际使用的配置文件)不支持这一点。

将 SAML2 用于移动应用程序很困难,SAML2 协议没有很好的支持重定向回客户端。一种常见的解决方法是使用 OpenID Connect。我参与了移动客户端通过 OpenID Connect 向 IdentityServer3 进行身份验证的设置。然后IdentityServer3充当SAML2 SP(通过Kentor.AuthServices中间件)到上游SAML2 Idp。

我知道你的处境很微妙,但我认为你必须回去问问它应该如何运作。具体来说,您应该询问用户应该在哪里输入凭据以及 SP 和 Idp 之间的通信应该如何工作。