Setting file-based permissions

Grant and revoke administration authority by configuring file-based permissions for working with an integration node and its resources or and integration server and its resources.

Before you begin

Read the following topics:

About this task

You can grant and revoke administration authority for an integration node and its managed integration servers, or for an independent integration server, by configuring file-based permissions for specified roles. You can configure these permissions by using the mqsichangefileauth command, or by setting properties in the node.conf.yaml file (for an integration node and its managed integration servers) or in the server.conf.yaml file (for an independent integration server).

You can use file-based permissions for authorization if the file-based or LDAP-based mode of administration security has been specified for the integration node or server. For LDAP authorization, you must associate a role with the LDAP groups to which the user belongs, and then set file-based permissions for that role. For more information, see Configuring authorization by using LDAP groups.

To specify an authorization mode for an integration node (and its managed integration servers) or an independent integration server, you can either use the mqsichangeauthmode command or set the authorizationEnabled and authorizationMode properties in the node.conf.yaml or server.conf.yaml configuration file.

Three levels of authorization permissions are supported for IBM® App Connect Enterprise administration security: read, write, and execute. You can assign permissions to a role by specifying the type of permission followed by a plus (+) to grant permissions, or a minus (-) to revoke permissions:

read+/-
write+/-
execute+/-
all+/-

These permissions can be applied to each role for the following types of objects:

Integration node resources
Integration server resources
Data objects (record-replay)

Note: If you grant permissions to a role at the integration node level, those permissions are not applied to the integration servers that are managed by the integration node; you must also set permissions explicitly for individual integration servers.

Set file-based permissions for your integration node or integration server by completing one of the following tasks:

Setting permissions in the node.conf.yaml configuration file or server.conf.yaml configuration file

About this task

You can configure authorization for an integration node (and its managed integration servers) or for an independent integration server, by setting permissions for roles in the Security section of the node.conf.yaml or server.conf.yaml configuration file.

You can define a role and grant or deny permissions to it, by specifying them in the appropriate .conf.yaml file. In the following example, the role called viewRole has been granted read permission only, and the role called adminRole has been granted permission for all actions.

Permissions:
    viewRole:  'read+:write-:execute-'
    adminRole: 'all+'

Procedure

Configure the authorization mode for an integration node or server by completing the following steps:

Open the node.conf.yaml file (for an integration node and its managed integration servers) or the server.conf.yaml file (for an independent integration server), by using a YAML editor.

If you do not have access to a YAML editor, you can edit the file by using a plain text editor; however, you must ensure that you do not include any tab characters, because they are not valid in YAML and would cause your configuration to fail. If you are using a plain text editor, ensure that you use a YAML validation tool to validate the content of your file.
If administration security has not already been enabled, activate authentication and authorization by setting the basicAuth and authorizationEnabled properties to true:
```
basicAuth: true
authorizationEnabled: true
```
Specify the file-based authorization mode, by setting the authorizationMode property to file:
```
authorizationMode: file
```
Define the role and set its permissions, by specifying a combination of read, write, and execute, or all, with + to grant permission, and - to deny permission; for example:
```
viewOnly:  'read+:write-:execute-'
aceAdmin:     'all+'
```
where the viewOnly role has only read permission, and the aceAdmin role has permission for all actions.
Save the modified file.
Restart the integration node or independent integration server, as appropriate, for the changes to take effect.

Setting permissions by using the mqsichangefileauth command

About this task

You specify the permissions as a comma-separated list of values. A value can be specified for each permission (read, write, and execute) only once in the list of values. For example, you cannot specify all-,read+ because it would be attempting to set the read permission twice (once explicitly, and once as part of all). If all is specified, it must be the only value. If you specify all-, all permission records in the registry are removed.

Procedure

Follow these steps to set permissions for a role:

Ensure that administration security has been enabled for the integration node.
For more information, see Enabling administration security.
Use the mqsichangefileauth command to change the permissions that are assigned to a role.
For example, the following command shows how to set permissions on an integration server that is associated with an integration node:
```
mqsichangefileauth ACE11NODE -r aceAdmins -e default -p read+,execute+
```
In this example, the role aceAdmins is granted execute and read permission on ACE11NODE.default (the default integration server on the ACE11NODE integration node). If this role did not previously exist, the write permission is disabled.
The following example shows how to set permissions on an independent integration server (which is not managed by an integration node):
```
mqsichangefileauth -w server_workpath -r aceAdmins -e default -p read+,execute+
```
The mqsichangefileauth command saves the permissions to the node.conf.yaml or server.conf.yaml overrides file.
Restart the integration node or independent integration server for the changes to take effect.

What to do next

For information about authentication, see Authenticating users for administration.