Google Cloud平台是否提供应用程序级授权功能？
我正在研究使用使用GCP APIS设置的OAuth2.0客户端IDS的GCP项目。服务＆GT;凭据＆gt; OAuth 2.0客户端ID。
属于这些项目的父母组织的电子邮件地址的任何人都可以通过我们的OAuth2.0 OpenID Connect登录页面登录。
是否可以限制哪些人可以登录？例如，定义Google组（我们称其为“组1”），然后将特定用户添加到该组将非常方便。然后，我们可以有一个特定的项目（称其为“项目1”）要求用户在“组1”中以登录“项目1”。如果用户不属于任何组或属于“组2”，则他们将无法登录“项目1”。
I am working on GCP projects that use OAuth2.0 Client IDs set up using GCP APIs & Services > Credentials > OAuth 2.0 Client IDs.
Anyone with an email address that belongs to these project's parent organization can log-in via our OAuth2.0 OpenID Connect login pages.
Is it possible to restrict which individuals can login? It would be very convenient, for example, to define a Google Group (let's call it "Group 1") and then add specific users to that group. We could then have a specific project (call it "Project 1") require that users be in "Group 1" in order to login to "Project 1". If a user doesn't belong to any groups or belongs to "Group 2", instead, they would not be able to log-in to "Project 1".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果用户没有IAM角色/权限，则可以对您的应用程序进行身份验证，并且能够使用Google Cloud进行 。您是否将身份验证与授权混淆？您可以以每个用户为基础控制对Google Cloud的访问。 将Google cloud Platforn打开或关闭用于用户的Google Cloud Platform < /p>
[AFTER问题修改]
Google Cloud不提供应用程序级授权。您必须在应用程序或框架内实现访问控件。
If the users do not have IAM roles/permissions, they can authenticate to your application and be able to do nothing with Google Cloud. Are you confusing authentication with authorization? You can control access to Google Cloud on a per-user basis. Turn Google Cloud Platform on or off for users
Yes, Google Cloud supports groups. You can add identities to a group for group role management. Managing groups in the Cloud Console
Users do not log in to groups. They can be members of groups and assume those permissions.
[Update after question modification]
Google Cloud does not provide application-level authorization. You must implement access control within your application or framework.
从OIDC或OAUTH的角度来看。
OAuth 2.0是关于委派的，以限制应用代表用户可以做的事情；
尽管在OAuth 2.0上构建的OIDC作为流程的一部分具有身份验证，但仅用于流量，仅用于用户将权限（OAuth 2.0中的范围）委派给应用程序。
当然，您可以拥有单独的范围（对于项目1和项目2），这些范围将授予对两个不同应用程序的授权访问权限。
同样，通常，您应该仅授予访问权限的积极范围，而所有其他人则被拒绝。 （即“用户不属于...”）是如果您没有范围“项目1”，则无法访问资源。
From the OIDC or OAuth perspective.
OAuth 2.0 is about delegation to limit what an app can do on behalf of a user;
Although OIDC, which is built on OAuth 2.0 has authentication as part of the flow, it is only to the flow it is ONLY for the user to delegate permissions (Scope in OAuth 2.0) to an app.
You certainly could have separate scopes (for Project 1 and Project 2) that would grant scopes for the delegated access to the two different applications.
Also, generally you should grant only positive scopes for access and all others are refused. (i.e. " user doesn't belong...") would be if you do not have scope "Project 1", you can not access the resource.