分布式系统的身份验证和授权

Question

我正在研究分布式系统的架构，基本上是在ruby（rails，sinatra等）中。

我有几个纯API的组件，比如API_C1，API_C2，API_C3。它有几个Web客户端应用程序，比如Portal1，Portal2和一些本机客户端应用程序，比如Native1。

要求：

1. 所有Web客户端的SSO（Portal1，Portal2），集中身份验证。
2. 所有API组件都应使用授权公开其API。
3. 集中式API授权。

我做了几个POC尝试了一些选项，但仍然没有完整的图片。

我为SSO尝试了rubycas服务器。它工作得很好。如果需要，我考虑使用java cas实现。

集中式API授权对我来说相当棘手。我倾向于采用OAuth2的方式，但有一些问题：

1. 是否可以让集中式OAuth提供程序为所有API组件提供服务？它应该如何工作以及使用什么库/宝石？
2. 默认情况下，如何使我的网络应用程序（Portal1和Portal2）受信任。我不希望用户授权访问受信任的应用程序。

3. 对于原生客户端应用程序（非Web环境），我想支持2条OAuth。这是正确的选择吗？是否可以同时使用3条腿和2条腿？

4. 如何将用户信用转换为oauth令牌？假设以下用例：

   • 用户登录Portal1（通过CAS服务器）并打开一些页面
   • Portal1后端服务器应从API_C1和API_C2中提取数据以显示该页面。如何在这里授权API？

我有一些想法，比如在相同的SSO CAS会话下使用API​​组件。这有点允许我的场景4）解决，没有在这里编码。但是使用API​​会话是一种不好的做法，然后如何混合API的会话和OAuth授权？

请指出正确的方向。可能还有一些其他选项可以执行自定义的OpenId或OAuth提供程序以支持SSO吗？

Answer 1

虽然这是一个老问题（2年前），但是我会在这里留下答案，以防有人试图解决类似的问题。

我认为您通过考虑使用OAUTH正在朝着正确的方向发展，但是我建议您使用version 2.0 of the OAUTH protocol

集中授权

  

是否可以为所有API组件提供集中式OAuth提供程序？它应该如何工作以及使用什么库/宝石？

• OAUTH 2.0通过让授权服务作为独立系统/服务运行来实现此方案，系统中的其他服务可以信任该服务并知道如何验证其颁发的令牌（通过使用其例如x.509证书公钥）

• 您可以使用基于SaaS的授权服务器，无需任何设置成本，例如Auth0

网络客户端

  

默认情况下，如何使我的网络应用程序（Portal1和Portal2）受信任。我不希望用户授权对受信任的应用程序进行访问。

• 使用resource owner password grant，用户（资源所有者）使用username＆amp;}对客户端（网站/门户/应用）进行身份验证。 password以及已知的client_id（也可以绑定到已知的HTTP来源）

• 或者，authorization code grant，其中门户网站将用户重定向到已知的授权服务URL，其中包含一些URL参数，供用户在那里进行身份验证并重定向回门户网站

原生应用

  

对于本机客户端应用程序（非Web环境），我想支持2条OAuth。这是正确的选择吗？

• 在OAuth 2.0中，在此方案中使用client credentials grant，可以存储client_id＆amp; client_secret并将它们发送到授权服务器以作为可信客户端进行身份验证（无需用户凭据）

将它们混合在一起

  

是否可以同时使用3条腿和2条腿？

• OAuth 2.0的所有上述授权类型可以在同一个授权服务/服务器上协同工作（据我所知。我实际上已经让它与Microsoft OWIN合作{{3} }）

  

如何将用户信用转换为oauth令牌？假设以下用例：

• 授权服务具有客户端用于发布表单或重定向到获取access_token的端点（URL），但实际方法取决于您使用的是哪种身份验证流程（post vs redirect）

  

用户登录Portal1（通过CAS服务器）并打开一些页面   Portal1后端服务器应从API_C1和API_C2中提取数据以显示页面。如何在这里授权API？

• 使用ASP.net用户输入username＆amp; password进入portal1，然后获得access_token，然后当portal1调用API_C1时，它可以将access_token附加到调用（HTTP标头：Authorization）（模仿）登录用户）

• 使用resource owner password grant用户被重定向到Auth服务，在那里输入他们的凭据，然后重定向回到具有access_token的portal1（客户端），然后将其附加到呼叫到API_C1来模拟登录用户

类似主题

最后，请查看与您的问题相关的authorization code grant