jerqi commented on code in PR #4624:
URL: https://github.com/apache/gravitino/pull/4624#discussion_r1726672270
##########
docs/security/access-control.md:
##########
@@ -20,24 +42,90 @@ Gravitino doesn't support metadata authentication. It means
that Gravitino won't
:::
-
## Concept
+### Authorization
+
+Gravitino also provides a set of authorization frameworks to interact with
different underlying data source
+authorization systems (e.g., MySQL's own permission management and the Apache
Ranger permission management system for big data)
+in accordance with its own authorization model and methodology.
+More information you can see [Authorization push
down](authorization-pushdown.md).
+
+### Authentication
+
+As mentioned above, Gravitino uses Ownership to control the rights of
resources in the management category and uses Role to control the permissions
of operations in the operation category,
+so when a user performs a specific operation on a specified resource,
+Gravitino will perform a composite authentication on the Ownership and Role to
which the resource belongs.
+When a user has more than one Role, Gravitino will use the user's current Role
for authentication, and the user can switch the current Role to access
different resources.
+
+#### Permission fuzzy matching
+
+Gravitino uses the resource's ENTITY ID (long type) to preserve permission
relationships.
+So Gravitino can't directly support fuzzy matching of resource names (string
type), such as wildcards like (*) and (%).
+Gravitino uses the resource parent node to express support for all resource
(*) wildcards for child resources, for example,
+if we need to set read permissions for all table resources, we can set it to
`{catalog1.schema1, READ_TABLE_PRIVILEGE}`,
+which stands for having access to `catalog1.schema1.*` read access to all
tables.
+
+### Storage of authority data
+
+A key requirement of Gravitino should be to display permission information and
perform operations such as grant and revoke, along with push-down of the
permission information to the underlying data source system.
+It also needs to be able to translate that information to the corresponding
permissions within the underlying system in order to achieve permission control
over the data in the data source.
+
+If Gravitino does not store privilege information itself and only push-down
permission to the underlying data source system,
+it would be very difficult for Gravitino to translate Gravitino's privilege
model back from the different privilege systems of the underlying data source.
+
+Gravitino currently stores all the permission information (Privilege,
SecurableObject, Role, User and Group) itself,
+and when there is a discrepancy between the permissions of the underlying data
source and the permissions stored in Gravitino, Gravitino’s permission system
will be trusted.
+
+Additionally, Gravitino provides a mechanism to ensure fault tolerance in the
privilege data storage and push-down to the underlying data source privilege
system.
+As a result of this, Gravitino’s push-downs to the underlying permission
system operations are required to be idempotent operation,
+meaning that each kind of privilege push-down operation can be repeated
without causing conflicts and will always achieve the same output.
+
### Role
-A metadata object to which privileges can be granted. Roles are in turn
assigned to users or groups.
+The traditional rights system generally uses RBAC (Role-Based Access Control)
for rights management,
+where each Role contains a collection of different operating privileges for
different resources.
+When the system adds a new user or user group, you can select the Roles which
they are expected to be granted to,
+so that the user can quickly start using it, without waiting for the
administrator to gradually set up the access rights to resources for him.
+
+Roles also employ the concept of ownership – the owner of a Role is by default
the creator of the Role,
+implying the owner has all the permissions to operate the Role, including
deleting the Role.
+
+Gravitino introduces the concept of the “Current” Role, where a user can own
multiple Roles at the same time,
Review Comment:
We don't have the concept of current role.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
