我在IBM云上有一组REST服务。入口集成了Appid进行身份验证。Ingress将令牌id和访问id添加到authorization头部。现在在API端(springboot),我是否需要在每次请求时再次验证用户?这会是多余的吗?如果没有,可以使用哪个appid接口对用户进行授权。对类似示例的任何引用
已经在IBM云站点上完成了示例。一个是关于入口和appid的集成,但没有讨论REST服务层如何处理那里的授权令牌。另一个只是spring和Appid (不谈入口)
发布于 2019-07-08 00:01:48
身份验证与授权是划清界限的地方。Ingress与App ID集成将为您执行身份验证,并且您的REST服务(应用程序)可以确保请求通过身份验证。现在,仅仅因为用户存在于您的系统中并提供了正确的凭据,并不意味着允许他访问他试图访问的服务或查看他试图查看的数据,这就是授权发挥作用的地方- REST服务可以使用授权令牌来确定用户是否具有使用服务的正确访问权限。
这里有一篇好文章,讨论了角色的使用-- https://cloud.ibm.com/docs/services/appid?topic=appid-tutorial-roles
发布于 2019-11-19 22:05:42
在任何应用程序中- REST、UI或其他-根据您的要求,可能需要多个级别的安全性。身份验证验证用户是他们声称的那个人,授权检查用户可能拥有的权限。对于用户可以访问的内容,每个应用程序可能都有自己的规则。
在您的示例中,您已经使用AppID验证了通过Ingress促成的用户,它为您的应用程序提供了一个用户主体(身份)。但是,每个用户都应该访问您的所有应用程序端点吗?如果答案是否定的,那么您将需要一个授权模型,对于该模型,常见的方法是RBAC (基于角色的访问控制)。
即使没有RBAC要求,对于每个请求,以某种形式验证用户的主体仍然是明智的。例如,用户可能属于您可能不期望的域,或者不再拥有对此特定REST应用程序的访问权限。您的应用服务器可能具有通过简单的授权功能为您提供帮助的功能,或者您可以自定义构建自己的验证。
目前,AppID作为身份提供者,可以作为用户角色的存储库。但是,您的应用程序或应用程序服务器必须决定如何处理该角色。
如果您正在寻找以云为中心的授权解决方案,您可能需要考虑研究Istio的授权策略:
https://stackoverflow.com/questions/56919211
复制相似问题