We are getting ready to release Attribute Based Access Control (ABAC).  This article provides an overview of some of the upcoming Admin UI changes that you will see once ABAC has been released.

But, first of all, what is ABAC?

Attribute based access control is an authorization model that evaluates attributes to determine access.  Attributes can be about the subject (the user or entity requesting access), the object (the resource or file the subject wants to access) or even the environment (the broader context including characteristics such as time of day or IP address).  ABAC policies work alongside RBAC (Role Based Access Control) and Divisions to provide additional access control granularity.  These policies are essentially boolean logic statements where a condition is evaluated to a true or false result.  Each policy targets a specific group of API calls (known as a 'target') and applies to a specific subset of users (known as the 'subjects')

ABAC will evolve over time as more attributes and targets are defined.  The initial ABAC release focuses on restricting permission changes and will deliver the following use cases:

• Cannot grant new roles - Prevent non-admin users from granting roles they do not themselves have
• Cannot update certain user profile fields - Prevent define user profile fields from being modified except by supervisors or admins

ABAC UI Overview

There is a new Organization Setting that controls ABAC enforcement.  Enable this setting to create and edit policies.  Each ABAC policy also has an individual on/off setting.

To create an ABAC policy, select the new Policies option under People & Permissions:

In the Policies menu, you can create an ABAC policy from scratch or you can use the Templates to help get you started.

Select one of the Templates to view the policy details.  The policy templates are based on the 'code editor UI' which includes the associated policy JSON code.  We have plans for a 'visual editor UI' in future which will present the user with a logic builder UI in place of the JSON code.  

The policy JSON contains information on the:

• Subject (user requesting access - policies can apply to all users, a single group, a single workteam, or a single user)
• Effect (allow/deny)
• Condition (policy rules - nested boolean logic statements)
• Preset Attributes (static data supplied when creating the policy)

The 'Validate Syntax' option checks to ensure your policy has all of the required fields, that the listed attributes are valid for the given target, that all attribute comparisons are valid for their respective data types and also that any preset attribute names don't conflict with ones defined in the system.  You can't save the policy if the syntax is invalid, so the syntax validation happens automatically when you save the policy.  Once you have saved the policy, you can then test the policy with sample data to confirm the policy behaves as expected, prior to enabling it.

As an alternative to using a policy template, you can create a policy from scratch.  In this case, the Policy JSON is a blank template which can be updated to create a policy, based on a condition which includes one or more of the available attributes.

Whether you start from a template, or create a policy from scratch, the resulting policy will then appear on the main policies page, once saved.  If the policy and the ABAC organization setting are enabled, the policy will be evaluated when the user attempts to perform the action outlined in the policy.  If the request doesn't meet the conditions outlined in any of the ABAC policies, the policy library (logic engine) returns a result of 'deny' and the access request is denied.  If the policy library returns a result of 'allow', then the existing permissions are checked to confirm that the user has the necessary permissions to perform the requested action.  All of the ABAC logic happens before the permission checks and is additional to the permission checks.  So, the user needs to meet the conditions of the policy and have the correct permission in order to access the resource.  

What happens if there are conflicting ABAC policies, with one policy allowing access and the other denying access?  Deny always wins out, so if any of the ABAC policies returns a result of 'deny', then the access is denied.

If you have a use case which you think ABAC could help with, review and vote on the existing ABAC ideas or go ahead and submit an additional idea:

• Use ABAC to restrict permission changes / prevent users from modifying their own permissions in Genesys Cloud
• Use ABAC to restrict access to Genesys Cloud
• Use ABAC to restrict feature access/usage within Genesys Cloud

#Roadmap/NewFeatures
#Security

------------------------------
David Murray
Principal Product Manager
Genesys Cloud
------------------------------

Hi David, I'm curious.  Where you mention here environment access and time of day, what would a user experience if we were to do something like say "this group of users can only access the environment 9am-5pm".  What would happen to that user at 5:01pm?

We are getting ready to release Attribute Based Access Control (ABAC).  This article provides an overview of some of the upcoming Admin UI changes that you will see once ABAC has been released.

But, first of all, what is ABAC?

Attribute based access control is an authorization model that evaluates attributes to determine access.  Attributes can be about the subject (the user or entity requesting access), the object (the resource or file the subject wants to access) or even the environment (the broader context including characteristics such as time of day or IP address).  ABAC policies work alongside RBAC (Role Based Access Control) and Divisions to provide additional access control granularity.  These policies are essentially boolean logic statements where a condition is evaluated to a true or false result.  Each policy targets a specific group of API calls (known as a 'target') and applies to a specific subset of users (known as the 'subjects')

ABAC will evolve over time as more attributes and targets are defined.  The initial ABAC release focuses on restricting permission changes and will deliver the following use cases:

• Cannot grant new roles - Prevent non-admin users from granting roles they do not themselves have
• Cannot update certain user profile fields - Prevent define user profile fields from being modified except by supervisors or admins

ABAC UI Overview

There is a new Organization Setting that controls ABAC enforcement.  Enable this setting to create and edit policies.  Each ABAC policy also has an individual on/off setting.

To create an ABAC policy, select the new Policies option under People & Permissions:

In the Policies menu, you can create an ABAC policy from scratch or you can use the Templates to help get you started.

Select one of the Templates to view the policy details.  The policy templates are based on the 'code editor UI' which includes the associated policy JSON code.  We have plans for a 'visual editor UI' in future which will present the user with a logic builder UI in place of the JSON code.  

The policy JSON contains information on the:

• Subject (user requesting access - policies can apply to all users, a single group, a single workteam, or a single user)
• Effect (allow/deny)
• Condition (policy rules - nested boolean logic statements)
• Preset Attributes (static data supplied when creating the policy)

The 'Validate Syntax' option checks to ensure your policy has all of the required fields, that the listed attributes are valid for the given target, that all attribute comparisons are valid for their respective data types and also that any preset attribute names don't conflict with ones defined in the system.  You can't save the policy if the syntax is invalid, so the syntax validation happens automatically when you save the policy.  Once you have saved the policy, you can then test the policy with sample data to confirm the policy behaves as expected, prior to enabling it.

As an alternative to using a policy template, you can create a policy from scratch.  In this case, the Policy JSON is a blank template which can be updated to create a policy, based on a condition which includes one or more of the available attributes.

Whether you start from a template, or create a policy from scratch, the resulting policy will then appear on the main policies page, once saved.  If the policy and the ABAC organization setting are enabled, the policy will be evaluated when the user attempts to perform the action outlined in the policy.  If the request doesn't meet the conditions outlined in any of the ABAC policies, the policy library (logic engine) returns a result of 'deny' and the access request is denied.  If the policy library returns a result of 'allow', then the existing permissions are checked to confirm that the user has the necessary permissions to perform the requested action.  All of the ABAC logic happens before the permission checks and is additional to the permission checks.  So, the user needs to meet the conditions of the policy and have the correct permission in order to access the resource.  

What happens if there are conflicting ABAC policies, with one policy allowing access and the other denying access?  Deny always wins out, so if any of the ABAC policies returns a result of 'deny', then the access is denied.

If you have a use case which you think ABAC could help with, review and vote on the existing ABAC ideas or go ahead and submit an additional idea:

• Use ABAC to restrict permission changes / prevent users from modifying their own permissions in Genesys Cloud
• Use ABAC to restrict access to Genesys Cloud
• Use ABAC to restrict feature access/usage within Genesys Cloud

#Roadmap/NewFeatures
#Security

------------------------------
David Murray
Principal Product Manager
Genesys Cloud
------------------------------

Hi Vaun, It is an interesting question.  I will start with the caveat that this is functionality which is not yet supported by ABAC.  We haven't yet implemented the ability to use ABAC to deny access to Genesys Cloud.  This is a use case we will be adding shortly.  So, some of the behavior around this has yet to be defined.  From your perspective, what would that desired behavior be?

Ultimately, as long as we have a way to identify the user or group of users defined in the policy, we can deny access at any time.  So, for example, a user who is already logged in prior to 5pm might continue to be logged in (their access tokens aren't automatically invalidated) but the ABAC policy could prevent them from accessing resources post 5pm.  That might not be a desirable outcome so the policy could be implemented in a different manner such that, once the user has access, they continue to have access until they logout or their tokens expire.  Similar to getting access to a conference call which is locked at a certain time.  Once you are in, you are in, but if you don't get in ahead of the deadline, you are blocked.  So, in summary, yet to be defined but definitely something to think about.  

Hi David, I'm curious.  Where you mention here environment access and time of day, what would a user experience if we were to do something like say "this group of users can only access the environment 9am-5pm".  What would happen to that user at 5:01pm?

We are getting ready to release Attribute Based Access Control (ABAC).  This article provides an overview of some of the upcoming Admin UI changes that you will see once ABAC has been released.

But, first of all, what is ABAC?

Attribute based access control is an authorization model that evaluates attributes to determine access.  Attributes can be about the subject (the user or entity requesting access), the object (the resource or file the subject wants to access) or even the environment (the broader context including characteristics such as time of day or IP address).  ABAC policies work alongside RBAC (Role Based Access Control) and Divisions to provide additional access control granularity.  These policies are essentially boolean logic statements where a condition is evaluated to a true or false result.  Each policy targets a specific group of API calls (known as a 'target') and applies to a specific subset of users (known as the 'subjects')

ABAC will evolve over time as more attributes and targets are defined.  The initial ABAC release focuses on restricting permission changes and will deliver the following use cases:

• Cannot grant new roles - Prevent non-admin users from granting roles they do not themselves have
• Cannot update certain user profile fields - Prevent define user profile fields from being modified except by supervisors or admins

ABAC UI Overview

There is a new Organization Setting that controls ABAC enforcement.  Enable this setting to create and edit policies.  Each ABAC policy also has an individual on/off setting.

To create an ABAC policy, select the new Policies option under People & Permissions:

In the Policies menu, you can create an ABAC policy from scratch or you can use the Templates to help get you started.

Select one of the Templates to view the policy details.  The policy templates are based on the 'code editor UI' which includes the associated policy JSON code.  We have plans for a 'visual editor UI' in future which will present the user with a logic builder UI in place of the JSON code.  

The policy JSON contains information on the:

• Subject (user requesting access - policies can apply to all users, a single group, a single workteam, or a single user)
• Effect (allow/deny)
• Condition (policy rules - nested boolean logic statements)
• Preset Attributes (static data supplied when creating the policy)

The 'Validate Syntax' option checks to ensure your policy has all of the required fields, that the listed attributes are valid for the given target, that all attribute comparisons are valid for their respective data types and also that any preset attribute names don't conflict with ones defined in the system.  You can't save the policy if the syntax is invalid, so the syntax validation happens automatically when you save the policy.  Once you have saved the policy, you can then test the policy with sample data to confirm the policy behaves as expected, prior to enabling it.

As an alternative to using a policy template, you can create a policy from scratch.  In this case, the Policy JSON is a blank template which can be updated to create a policy, based on a condition which includes one or more of the available attributes.

Whether you start from a template, or create a policy from scratch, the resulting policy will then appear on the main policies page, once saved.  If the policy and the ABAC organization setting are enabled, the policy will be evaluated when the user attempts to perform the action outlined in the policy.  If the request doesn't meet the conditions outlined in any of the ABAC policies, the policy library (logic engine) returns a result of 'deny' and the access request is denied.  If the policy library returns a result of 'allow', then the existing permissions are checked to confirm that the user has the necessary permissions to perform the requested action.  All of the ABAC logic happens before the permission checks and is additional to the permission checks.  So, the user needs to meet the conditions of the policy and have the correct permission in order to access the resource.  

What happens if there are conflicting ABAC policies, with one policy allowing access and the other denying access?  Deny always wins out, so if any of the ABAC policies returns a result of 'deny', then the access is denied.

If you have a use case which you think ABAC could help with, review and vote on the existing ABAC ideas or go ahead and submit an additional idea:

• Use ABAC to restrict permission changes / prevent users from modifying their own permissions in Genesys Cloud
• Use ABAC to restrict access to Genesys Cloud
• Use ABAC to restrict feature access/usage within Genesys Cloud

#Roadmap/NewFeatures
#Security

------------------------------
David Murray
Principal Product Manager
Genesys Cloud
------------------------------