根据以下@ user18044的问题进行了更新
如果用户通过2个不同的基于SAML的身份提供程序在两个不同的Web应用程序中进行身份验证，并且其中一个应用程序需要从另一个应用程序公开的Web API请求数据，则是否可以调用Web API通过用户在两个应用程序中的当前身份验证状态安全地保护方法，而无需通过API级别身份验证协议（如OAUTH）单独保护API方法？请注意，这两个应用程序都由我的公司拥有和运营，并共享相同的二级域和用户群，即使身份服务器不同（一个是遗留的）。
一些进一步的信息：应用程序A是一个门户应用程序，它将使用应用程序B提供的数据来托管小部件。应用程序A将仅通过应用程序B公开的Web API与应用程序B通信。目前应用程序B不公开Web API（应用程序本身内部除外）。这是需要添加到应用程序B的新功能。应用程序A将使用Okta作为其SSO。我们的首席架构师的建议是继续使用我们基于使用dk.nita.saml20 DLL在内部开发的自定义遗留IDP服务器。我相信它们都是基于SAML的，但我不认为他们可以共享相同的身份令牌，而无需进行一些改造。但这已经超出了我对身份验证主题的了解。 :)我认为我们的架构师的计划是让用户使用两个不同的身份提供者单独进行身份验证，然后仅使用CORS保护Web API，他的理由是，因为用户已经知道并经过身份验证才能使用应用程序B ，允许应用程序A调用应用程序B的web api方法不会有任何安全隐患，因为用户应该在应用程序B中进行身份验证。这对我来说似乎很古怪，因为我可以想象一个许多浏览器重定向发生可能对用户不透明，但除此之外，我只想弄清楚安全漏洞可能在哪里，因为我觉得会有一些。
我知道这种做法不会被视为最佳做法，但话虽如此，我真的很想明白为什么不这样做。是否存在安全隐患？它会工作吗？如果是的话，有没有＆＃34;陷阱＆＃34;或实施过程中需要考虑的事项？
重申一下，我们的首席架构师正在提出这个解决方案，而且我的直觉检查失败了，但我对这个话题的了解不足以证明我的立场是合理的，或者让我觉得足够舒服接受他的。希望一些安全专家能够启发我。
答案 0 :(得分：1)
如果不了解更多关于当前应用程序和API的确切安全性，则很难回答。 Web应用程序及其API是否具有相同的依赖方标识符（即，可以使用相同的标记来对两者进行身份验证）？
如果两个Web应用程序都使用WS-Federation协议对用户进行身份验证，则很可能SAML令牌将存储在身份提供程序将令牌发布回应用程序时设置的Cookie中。
您无法从JavaScript访问这些Cookie。如果属于应用程序B的Web API使用相同的基于cookie的身份验证机制，则可以使用此选项，前提是您允许cross origin resource sharing。
如果您的网络API使用类似于承载令牌身份验证方案（如OAuth）或在STS中具有不同的依赖方ID，则这显然不起作用。
我认为这会导致您的肠道检查失败的原因是因为您基本上是以cross-site request forgery attack的方式访问网络API。
我在这种方法中遇到的一个问题是，如果用户未使用其他Web应用程序进行身份验证，那么对API的调用也将失败。
答案 1 :(得分：1)
我同意user18044，因为它基于跨站点请求伪造攻击和应用程序之间的安全性。如果用户X有权访问App A，那么他们是否可以访问App B，反之亦然？如果不是这种情况，那么每个应用程序都需要单独进行身份验证......而且它不会是SSO。我发现这些链接可能对您的情况有所帮助。
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations