New challenges are rising as we enter into the New Digital Era with decentralization being one of the major challenges. Decentralization can bring more parties into cooperative ecosystems allowing for data to be shared in ways we never imagined. With data not relegated to remain in one place, its usage can stretch across multiple complex and multidimensional ecosystems. API based entitlements and communications do NOT guarantee #Atomicity and cannot scale into a decentralized environment. #Atomicity is crucial to any future decentralized ecosystem and it means that data would only be shared in an atomic swap between access and data distribution. Entitlement systems, as sophisticated as they might be, are not enough to “enforce” data usage policies. They are bilateral and needed for each application and therefore expensive and difficult to maintain as they don't provide automatic consent management and are not dynamic in nature. Entitlement systems, which are kept centralized, do not delegate sovereignty to data owners. Regulators are demanding more granular and explicit proof that organizations are complying with data usage and privacy directives.
At One Creation, one of our main features is the enforcement of data rights policies using #SmartContracts. Many of you have asked us: “How are you different from other entitlement services?”. In this article, we will provide a detailed comparison and explanation.
Entitlements
If you are an admin, you might be managing user permissions on multiple applications and data storages. Let’s look at the following scenario:
A new application user A requests access to an application that pulls data from an FTP site and a set of tables from a data warehouse. This user also needs access to the raw data in the data warehouse, FTP site, and additional data in cloud computing platforms to perform other bespoke queries.
Another application user B and engineer requires access to a data warehouse, FTP sites, and cloud computing platforms in order to maintain the application.
Each organization is different and has different technologies for user onboarding and entitlements. However, most processes look similar to the diagram above. To explain further, here are the steps (WARNING: repetitive steps ahead):
New user A provides some identity information in order to authenticate into the Application
Application admin will set up entitlement rules including whether the user A belongs to a group, what they are allowed to see at the function level, and what action is permitted
User A provides identity information to the data warehouse admin for authentication
The data warehouse admin will setup user group, role, and possibly filters to certain tables, columns, and rows
User A provides identity information to the FTP site admin for authentication
The FTP site admin will add user to the authenticated group and configure access level to the folders and files
Now that we have the user A onboarded, let’s setup user B, who requires a different level of access to different applications:
New user B provides some identity information in order to authenticate into the Application
Application admin will set up entitlement rules for user B
User B provides some identity information to the data warehouse admin for authentication
The data warehouse admin will setup user group, role, and possibly filters to certain tables, columns, and rows
User B provides identity information to the FTP site admin for authentication
The FTP site admin will add user to the authenticated group and configure access level to the folders and files
User B provides identity information to the cloud computing platform admin for authentication
The cloud computing platform admin will setup roles and policies to restrict the engineer’s access level
After going through most of the steps twice, we now have both new users onboarded. It’s the admins’ responsibilities to monitor and maintain their entitlement rules to ensure they are up to date.
If any of the application users require any custom entitlements logic, a new application layer needs to be built to implement this control. Ouch!
When a user leaves the organization it's HR’s responsibility to inform all admins to remove this user from all products and systems. Here are the challenges:
How does HR know the full list of user’s access points?
Even if HR has the full list and provides it to the admins, how do you ensure that the admins promptly remove all access?
Any mistakes and the engineer may still retain some level of access somewhere.
This application access scenario is only one out of the many complex layers within a large organization. Building, maintaining, and tracking is a big overhead.
Policy Enforcements Using Smart Contracts
Let’s look at how #SmartContracts enforce these policies in a much simplified but powerful and secure way.
1. A policy admin defines the set of data rights policies. Each policy (stored in a smart contract):
Applies to one or more sources of data
Defines the set of conditions: what type of user, what data points, and when
Contains an outcome if the above conditions are met
2. As the new application users onboard, each satisfies certain conditions with relevant data rights policies and therefore gains access to the permissioned data points atomically
3. Most importantly, our #SmartContracts allow for queries and onboarding of new entities with no human intervention. Once a “party” verifies themselves on the fabric, new rules are assigned to them. This means, a “#creator” is able to automatically consent to new data requests with no need to add new parties to the contract manually.
When a user leaves the organization, HR updates the user’s status in the organization's Active Directory. This new status violates the conditions in the relevant policies, therefore, the user’s rights to all data storages are immediately revoked atomically.
Voila!
Let’s take note of the steps we saved:
There’s no replication of user identify information from the Active Directory into each application
There’s no development and maintenance of access control on individual application level
There’s no need to actively entitle each user
Data consolidation into a single data storage is no longer a requirement
In addition, policies are enforced atomically and real time, without human intervention.
This is all achieved through One Creation’s Digital Rights Enforcement and Management (DREAM™) Fabric. We leverage the power of #SmartContract in a very special way, to achieve interoperability, without the need to adopt blockchain technology. Our DAML #SmartContracts sit on centralized databases. Putting a GPS on your data is just a few clicks of a button (or a couple lines of code).