zerion Identity Management
What you need to know
- What is ZIM?
- What is a ZIM policy?
- Introduction to Best Practices
- What are the best practices for writing a ZIM policy?
What is ZIM?
ZIM, or Zerion Identity Management, is a web service that helps securely control access to Zerion resources for you and your users. ZIM controls who can use your Zerion resources (authentication) and what resources they can use and in what ways (authorization).
Click here for more information on ZIM.
What is a ZIM policy?
A ZIM policy is a document that formally states one or more permissions. In its most basic sense, a policy lets you specify the following:
Actions: What actions you will allow a user to perform? Each Zerion Web Service has its own set of actions. For example, you might allow a user to create Dataflows. Unless otherwise specified that user would ONLY be allowed that single action within the Zerion Console.
Resources: Which resources you allow the action on. For example, what specific Dataflow will you allow the user access to? Users cannot access any resources that you have not explicitly granted permissions to.
Effect: What the effect will be when the user requests access — either allow or deny? Since the default is that resources are denied to users, you typically specify that you will allow users access to a resource.
For more information on Zerion Identity Management (ZIM), please have a look HERE.
Introduction to Best Practices
ZIM policies are intentionally designed to be flexible, allowing for increasing granularity. The ability to customize access at a deep level can be overwhelming to manage if proper steps are not taken.
The following recommended practices are intended to (1) maintain an organized library of policies, (2) minimize conflicts between policies, and (3) reduce the learning curve for new policy writers.
If you are unfamiliar with the elements of ZIM or how policies and permissions are structured, please start with this article.
6 Best Practices for Writing ZIM Policies
Have a look below for what we consider 6 essential best practices for writing effective policies.
Shorter is Better
As a guiding principle, try to avoid writing "catch all" policies. While multiple permissions are able to be combined into a single policy, it can be difficult to assign the policy to a User Group where all users would receive the full policy.
For example, creating a policy that allows the creation of ZIM users, Dataflows, and Forms may not be applicable to a group created for developers who should not manage users.
Follow a Naming Convention
If our goal is to keep policies short, then we need a way to name and organize the bigger number of smaller policies. Although every company has different requirements, thus individualized naming considerations, use the following table to plan your naming system.
|
Question |
Explanation |
Recommended Practice |
|
What service is the policy for? |
ZIM controls access to all Zerion services so it is important to identify which service the policy addresses. |
Use the following prefixes:
|
|
Does the policy allow or deny access? |
A policy can either allow or deny access to the included actions and resources. Remember that if there is an allow/deny conflict of actions or resources that deny will take priority. |
Use one of the following tags:
|
|
What action(s) does the policy include? |
The actions list is normally the longest part of a policy. Try to group actions that can be described by a single role or function. It is better to split a long list of actions into two policies rather than having to write exception policies to accommodate special cases. |
Define a role that describes the action list. Some recommendations are:
|
|
What is the scope of the policy? |
Being able to identify the associated resource(s) will save time when browsing through a list of policies. |
Use one of the following suffixes:
|
Avoid the * Wildcard
Using the asterisk (*) as a wildcard character represents all possible options for the action or resources. For example, the following policy would allow the user to delete any Dataflow on the server.
{
"effect": "allow",
"actions": [
"dfa::delete::dataflows"
],
"resources": [
"zws::servers::company::dfa::dataflows::*"
]
}Potentially more problematic, a policy that uses the asterisk in an action will allow/deny all actions for the supplied resource. The following resource would allow all actions on all Dataflows.
{
"effect": "allow",
"actions": [
"dfa::"
],
"resources": [
"zws::servers::company::dfa::dataflows::*"
]
}Be very careful when deciding to use the asterisk (*). Remember that when using this, the policy will then apply to future resources created as well as future actions that are added.
Master the Resource Property
Using the resource property to scale down the scope of access is critical to ensuring a policy does not give access to unintended resources. For example, if a company has only one Dataflow, with an id of 1234, the following permissions are effectively synonymous:
{
"effect": "allow",
"actions": [
"dfa::export::records"
],
"resources": [
"zws::servers::company::dfa::dataflows::1234"
]
}{
"effect": "allow",
"actions": [
"dfa::export::records"
],
"resources": [
"zws::servers::company::dfa::dataflows::*"
]
}However, once a second Dataflow is created in the company, the first permission will not allow an associated user to export data from it while the second will. Specifically listing the resource(s) that the policy applies to will protect your policies from inadvertently granting undesired access.
Take Advantage of the ::self Property
The ::self identifier is a powerful way to allow/deny actions for resources created by the user. Let's look at the following policies all intended to allow the user to delete Dataflows.
Example 1: Delete Any Dataflow
|
This policy allows associated users to delete any Dataflow on the server. While this may be intended for admins, it is not recommended for developers or testers.
Example 2: Delete Specified Dataflow(s)
|
This policy allows associated users to delete only Dataflows listed in the resources property. This is the most specific policy; however, it requires updating every time a user creates a new Dataflow.
Example 3: Delete Any Dataflow Created By User
|
This policy allows associated users to delete only Dataflows they created themselves. This is an excellent example of creating a policy that is slightly less restrictive, but has improved functionality and can be assigned to many users.
Start From a Template
Now that you're armed with the previous five recommended practices, this final recommendation is intended to help get you started. We recommend starting from a template policy and modifying it to fit your needs. For beginners we recommend visiting the Customer Success Center and viewing our list of Policy Templates.
Comments
0 comments
Please sign in to leave a comment.