In Shiro, a role is a set of permissions. When a user logs into Cortex, a role is assigned to the user. Depending on the role, a customer may be restricted from executing create, read, update, or delete operations in the API.

Out of the box, Cortex has three roles:

Roles are hierarchical, meaning that higher-level roles inherit the permissions assigned to roles below them. For example, out of the box, REGISTERED is above PUBLIC so REGISTERED inherits all of PUBLIC's permissions.

Note: Adding 'relos.role.' before each role is required syntax. Any role defined without this syntax are removed through a permissions filter.

In Shiro, a permission defines what a user can do in Cortex.

Out of the box, Cortex has five role permissions:

Permission parameters refine permissions, allowing you to apply permissions to a specific instance of a resource. For example, the cartId parameter restricts a user's permissions so they only apply to the user's own cart.

Out of the box, Cortex has the following permission parameters. The following parameters are exclusive to a resource:

The following parameters are available for all resources:

When assigning permissions to resources, it can be helpful to understand how URI and URI-parts map from their display in Cortex Studio to their use in the permissions files.

The overall pattern for URIs in permissions is the following:

:{RESOURCE-FAMILY.PARAMETER}:{URI-PART}               
               

Where {RESOURCE-FAMILY.PARAMETER} is the resource's base family, and {URI-PART} is a resource identifier, like form. In many cases, {RESOURCE-FAMILY.PARAMETER} is {base.scope}. For more information on resource identifiers, see Resource Identifiers.

For example: The URI of the Orders resource displays in Cortex Studio as scope/orders/. To apply the CREATE permission to Orders, you would do the following:

relos.role.PUBLIC=CREATE:{base.scope}:{orders}
               

Shiro allows for wildcards at any point in the URI, using *. For example:

relos.role.PUBLIC=CREATE:{base.scope}:*:{orders}
               

The above would apply the CREATE permission to any URI with the pattern scope/[something]/orders, but not to, say scope/orders/[something].

By default, Shiro applies * to the end of all URIs. Meaning relos.role.PUBLIC=CREATE:{base.scope}:{orders} applies CREATE to scope/orders and all resources below it. For example, if scope/orders/profiles/ existed, profiles would recieve CREATE as well.

Sometimes you only want to apply permissions to a resource, but not its children. To do this, use EOL:

relos.role.PUBLIC=CREATE:{base.scope}:{orders}:EOL                  
               

Permission parameters are configured in a Helix resource by extending the AbstractHelixModule class, and binding PermissionParameterStrategy to the class:

For more information, see Configuring Prototypes.

To add permission parameters to a custom legacy resource's resource permissions, assign the parameter to a parameter strategy in the resource's permissionParameterResolver.

The scopeParameterStrategy is predefined in Cortex, but the custom yourResourceIdParameterStrategy needs to be implemented.

Out of the box,Cortex has the following parameter types and strategies:

Cortex uses a role hierarchy to enable roles to implicitly include the parent role's access rights. Out of the box, a role hierarchy has been defined where Customer is above Anonymous so Customer inherits all of Anonymous' permissions. If you want to define or add to the Role Hierarchy, edit the roleHierarchy.config file. Once a new roleHierarchy.config file is created, the API overrides the predefined role hierarchy with the hierarchy defined in the new config file.

Role hierarchy takes effect without having to restart Cortex.

relos.role.PUBLIC=LINK:carts,items

Do not surround LINK parameters with curly braces.

relos.role.PUBLIC=LINK:*

relos.role.PUBLIC=ADVISE_READ:carts,items

Do not surround ADVISE_* parameters with curly braces.

relos.role.PUBLIC=ADVISE_READ:*,ADVISE_CREATE:*,ADVISE_UPDATE:*,ADVISE_DELETE:*