Resource Access Management¶
Secure Data Sharing (SDS) enables you to create and manage fine-grained access rights. It is based on industry standard paradigm Policy Based Access Control (PBAC), which is an advanced framework to centrally manage permissions on business resources. SDS complements the already existing access management capabilities based on Role Based Access Control (RBAC) framework. SDS encompasses several services to solve the fine-grained access needs of enterprises. One of the key backend services is Resource Access Management (RAM), which provides an interface to configure and manage policies for several business objects.
During the first stage of general availability, by default, Secure Data Sharing Policies are not activated in your environment. To gain access, please contact our support team.
Be aware that through enablement of Secure Data Sharing Policies on your environment, all [Standard Users] and [Subtenant Users] lose access to all SDS protected resources. You will have to create policies to grant access again.
For accessing the [Policy Editor] in the [Settings] application, you need to have the respective roles listed in Resource Access Management roles and scopes. By default, these are enabled for users with the role
Once the Resource Access Management switch is turned ON in the [Settings] application, by default, all access to the resources (Assets, Time Series Data, Events, Files and Folders in the Integrated Data Lake) participating in Resource Access Management is denied. Access can then only be granted via policies.
Please note that once Resource Access Management is provisioned for your environment, it takes up to 1 hour to reflect the change. Similarly, requests for policy quota upgrades also take up to an hour to reflect.
There are some exceptions to this rule: - A user having the role
Tenant-Administrator is allowed unrestricted access to all the assets, events, and timeseries data of that environment for out-of-the-box applications (like Asset Manager, Operations Insights, etc.). - A user having the role
Data Lake Manager is allowed unrestricted access to all folders and files in [IDL] inside this environment. - Third-party or custom applications would still need a valid policy to access resources, irrespective of the
Data Lake Manager user role. - A technical user (without Interactive User Impersonation) has unrestricted access to all the resources of the environment, irrespective of whether the user is added to a policy.
A policy, at high level, consists of a mapping of 3 entities namely, [subjects], [actions], and [resources / resource groups]. In short, this means WHO as a user will get access, WHICH resources will be accessible, and WHAT actions will be allowed on those resources (eg. Add, Delete, Read, Write, etc.).
A policy describes a given set of subjects and is allowed to perform a given set of actions on a specified set of resources. More details about the policy resource groups is mentioned in below section. Set of actions, and resources are bound by a rule, and a policy can have multiple rules. These various terms used are explained below.
Since a policy always grants access and has no provision to deny access, overlapping policies, where the same user may have access granted via multiple policies, have no impact.
A policy can be deactivated any time, and policy is bound to the environment.
To understand Policy schema in detail, please refer Resource Access Management API Specification.
Resource and Resource Group¶
A policy resource represents either an individual business object (Asset or IDL File/Folder) or a Resource Group containing one or more individual business objects. In a nutshell, Resource Group is a container of heterogeneous resources.
One resource can be associated with multiple Resource Groups. A Resource Group cannot contain another Resource Group. That means nesting of Resource Groups is not supported.
With the following advantages, Resource Groups allow for more flexibility in managing access to member resources:
- Within the same policy, administrators can manage a greater number of resources when properly organized.
- Policy configuration need not be touched if the resources only need to be added or removed from the Resource Group.
To understand how the resource and resource groups are structured in a policy, please refer to Resource Access Management API Specification.
There are certain limits on the amount of policies and few internal objects within a policy. These are listed in Policy Limits
For any known issues, refer Known Issues.
Any questions left?
Except where otherwise noted, content on this site is licensed under the Development License Agreement.