Permissions

Permission checks are done when using the Content API (the REST api).

Users

A list containing the user names of all known ACE users can be retrieved by using the REST service(s) located at {aceurl}/security/user/search and {aceurl}/security/user/search/filtered.

Using the default user search attribute

Any requests to the REST service located at {aceurl}/security/user/search will search for users using the default user search attribute. This field can be configured as part of the content-service configuration.

A specific user can be located by providing the query parameter query={query}.

Examples:

$ curl 'http://ace-content-service:8081/security/user/search'

Will return a list containing the usernames of all known ACE users.

$ curl 'http://ace-content-service:8081/security/user/search?query=adm'

Will return a list containing the usernames of all known ACE users where the content of the default user search attribute match the provided query (wildcard matched).

Using custom search attributes

If you want to located ACE users using user attributes other than the default (see above), use the REST service located at {aceurl}/security/user/search/filtered and supply zero or more query parameters on the format {attributeName}={attributeValue}.

The list of valid search attributes are configured as part of the content-service configuration.

Examples:

$ curl 'http://ace-content-service:8081/security/user/search/filtered'

Will return a list containing the usernames of all known ACE users.

$ curl 'http://ace-content-service:8081/security/user/search/filtered?cn=adm'

Will return a list containing the usernames of all known ACE users where the content of the user attribute 'cn' match the provided value (wildcard matched).

$ curl 'http://ace-content-service:8081/security/user/search/filtered?cn=adm&description=administrator'

Will return a list containing the usernames of all known ACE users where the content of the user attributes 'cn' and 'description' both match the provided values (wildcard matched).

Permissions

Note: all permissions are applied to the content as a whole, using its type. There are no separate permissions for different aspects of a content.

The available permissions are:

Permission	Explanation
Create	Permits creating contents of a specific type. Note that having Read permission for a content type automatically includes Create permission for that type.
Read	Permits reading contents of a specific type in a context . Note that all users have this permission to read all contents on the view acePublic (or any symbolic view resolving to acePublic).
Update	Permits updating contents of a specific type.
Delete	Permits deleting contents of a specific type.
AssignAlias	Permits assigning aliases to contents of a specific type.
AssignToView	Permits assigning contents of a specific type to any view, e.g., assign article contents to acePublic view to make article contents publicly available. Note that, the permission is also needed, if the view is backed by a content, i.e., the content have the alias _view/{viewname}.
UnassignFromView	Permits unassigning contents of a specific type from any view.
ContentMetadata	Unused.
AddOwner	Permits adding an owner to a content's security context.
RemoveOwner	Permits removing an owner from a content's security context.

Role

A Role is defined in a content of type aceRole as a list of permissions for each content type. The content for a role needs an Alias of form _role/{rolename}. Roles can be retrieved using GET @ {aceurl}/security/role.

Example of a role

An editor role with Alias _role/editor:

{
  "system": {
    "contentType": "aceRoleContent"
  },
  "aspects": {
    "aceRole": {
      "_type": "aceRole",
      "name": "editor",
      "permissions": {
        "com.atex.ace.content.Article": [
          "Create",
          "Read",
          "Update"
        ],
        "com.atex.ace.content.SomeOtherType": [
          "Read",
          "AssignToView",
          "UnassignFromView"
        ]
      }
    }
  }
}

Contexts

Contexts defines the scope where permissions for a given user are valid. Contexts allows a user to assume different types of roles in different scenarios.

When creating a new content, you may pass a content metadata operation containing an aceSecurityContext aspect with the contexts you want to apply to the content (See Content Metadata).

Default Context

If there is no aceSecurityContext while creating a content, a default security context will be assigned according to the following steps:

1. If a Content Hierarchy is present, the security context will be based on that.

2. Otherwise, the content will inherit contexts from the user's contexts, where the Create permission is present.

UserRoles

UserRoles defines what roles a user has in different contexts. UserRoles is stored in a content of type aceUserRoles with Alias of form _userroles/{username}.

Example of roles being assigned to a user

An aceUserRoles content with Alias _userroles/kalle:

{
  "system": {
    "contentType": "aceUserRolesContent"
  },
  "aspects": {
    "aceUserRoles": {
      "_type": "aceUserRoles",
      "username": "kalle",
      "roles": {
        "sitemap": [
          "editor",
          "publisher"
        ],
        "site_sports_section": [
          "editor"
        ],
        "site_news_section": [
          "editor"
        ]
      }
    }
  }
}

Permission/roles/user example

A user has role editor in context context_1 and role publisher and editor in context_2. The editor role contains permissions Create, Read, Update and the publisher role contains permissions AssignToView, UnassignFromView on content type editorialArticle. Therefore, the user can create an editorialArticle type content in context_1 and can assign the article to/from any view in context_2.

Note that it is possible to add multiple roles for a user in the same context.