Permissions

Permissions help you to secure your world, configure feature accessibility, and manage access to component features.

Permissions Types are collected together into Permission Groups which can be owned by a Component, in which case they'll be transferred along with the component when moved between service providers.

A permission is like a switch or key, allowing a certain activity. Scripts and Components can check if a user's Connection Identity has a particular permssion on some securable object.

Permissions are applied on Securables for Entities. Permission entries are evaluated as described in Inheritance and given the hierarchy of Securables described below.

Securables

There are two types of securable objects: Entities and Worldspace. Entities can be granted Permissions on these securable objects (Worldspace or other Entities). The securable object hierarchy looks like this:

Securable (permissions are applied "on" a securable)

Entity (permissions are applied "for" an entity)

Account

Persona

EntityGroup

DynamicGroup

Area (Worldspace)

ServiceProvider

World

Scene

SceneInstance

Layer

AreaGroup

Inheritance

Permissions entries can be either allow' or deny entries. They can also be either regular or forced entries. Forced entries always override regular entries, and survive crossing a permission root in the worldspace hierarchy.

When determining a user's effective permission to some securable object, it's best to think of a keyring to which keys (permissions) are added or removed:

• Start with an empty keyring, and a securable object you want to evaluate permissions for
• Get the list of all Entities that the user's Connection Identity belongs to. At a minimum, their Account entity ID.
• Work your way "up" the hierarchy. Layer -> Scene -> World -> World -> Service Provider. If you're working with something like a persona the hierarchy might look like Persona -> Account -> Service Provider.
• Include any Area Groups along the way, and their parent Area Groups recursively
• For each securable object, look at its permission entries (the list of all permissions "for" any of the connections Entities "on" that securable):
  • For an allow entry, add a key to the keyring for that permission. If there's an existing regular deny, replace it (toggle it) to an allow. If there's an existing forced deny, the allow does not apply.
  • For a deny entry, add a red deny key to the keyring. If there's an existing regular allow, replace it (toggle it) to a deny. If there's an existing forced allow, the deny does not apply.
  • For a forced allow, replace any existing allow or deny keys, forced or not, with a forced allow key.
  • For a forced deny, replace any existing allow or deny keys, forced or not, with a red forced deny key.
  • If an allow and deny exist for the same permission at the same level of the hierarchy, the deny takes precedence.
  • If the securable being evaluated is a world, and that world is a Permission Root, remove any regular permissions (allow or deny, but not forced)
• Finally, remove all deny keys from keyring (they were symbolic placeholders).
• The remaining keys are the effectively allowed permissions.