Managing MMC Users and Roles

This document assumes that you are an administrator account holder in MMC.

Users are individuals who can log in to the console. For more information about adding and managing users, refer to Setting Up and Managing Users in MMC or Setting Up and Managing Users via LDAP.

User Groups allow you to assign permissions collectively to a group of users, effectively defining user roles. See Managing User Groups for more information.

Server Permissions specify which actions members of a user group may perform on a specified set of servers or server groups. These actions include viewing and deleting files, controlling servers, killing threads, and creating and disbanding clusters. For more information about server permissions, see Server Permissions Reference.

Global Permissions specify which tasks members of a user group may perform in the Management Console, such as viewing deployments, controlling flows, and managing users. For more information about global permissions, see [Global Permissions Reference ].

Mule Management Console offers two options for managing users, roles, and permissions:

Note that regardless of which method you choose for user management, you will need to use the Management Console to define user groups and assign permissions to them. Group permissions can be managed only via the console.

Ready to set up users?

Once you have set up users, you can define User Groups, each with a set of appropriate permissions, and then add users to those groups.

This section describes how to add, manage, and delete a user group, also referred to as a role, in the management console. Note that you cannot delete the Administrators group. The other three groups (Monitors, Deployers, and Server Administrators) model typical roles for console users and have been set up for your convenience.

Adding a new user group, or editing an existing group, entails setting server group permissions and global permissions. Server group permissions define the server groups that the user role or group can manage. The default console server groups are listed, including All servers, plus any server groups you may have created. There is also a set of permissions that apply specifically to servers, including permissions for file access, thread management, and server management.

The global permissions define the permissions that this group has regarding deployment, applications, alerts, flows, and so forth. See Understanding Permissions for more information.

Assigning individual users to user groups, equivalent to assigning them a role, is particularly important from a security perspective, since you are granting that user all the privileges and rights granted to the entire user group. Likewise, setting up the permissions for a user group is extremely important.

Whether you are modifying the permissions for the default user groups or setting up your own user groups, you need to consider the "actors" who will be in each user group and the use cases that these actors will be performing. In conjunction with these use cases, you can further fine-tune these permissions via server groups. By grouping servers into logical categories (Testing, Production, Development, Staging and so forth), you can give some groups more permissions for development and testing, but keep staging and production server environments more restrictive and thus more secure.

For example, you may want to define a user group for application developers. Application developers, of course, put together the application code itself, but they also need to test and debug the code before the application is ready for a production environment. To properly test an application, developers need to deploy their applications to a test system and potentially debug the message flows. Thus, you might want to give developers permissions for all tasks related to deployment, endpoint and flow control, and monitoring abilities on test- and development-specific servers.

You might want to use the staged server environment to set up and verify specific deployment scenarios prior to using them in a production environment. You might want to allow access to these servers for only certain deployment-related user groups. You might even decide that you need two levels of deployment specialists. At the same time, you may want to restrict developer access to the staged server environment so no unintended changes are made prior to release to a production environment.

You might also want a category of support technicians to have capabilities similar to developers, but on staging and production servers. You might have a support group handling sensitive accounts to which you give virtually all permissions.

You might have other user groups whose responsibilities rest more on system administration tasks. For these groups, you may want to give them permissions to manage other users, execute scripts, and manage alerts across all server groups.

Permissions give specific user groups the ability to carry out certain sets of tasks. Tasks can be server-related, such as registering or unregistering a server, or they may pertain to applications, such as deployment and flow control functions, or specific users, and so forth. Since permissions granted (or not granted) represent the security on your system, you should be particularly careful when assigning permissions to new user groups or modifying the permissions of existing groups.

The user groups provided by default (Administrators, Deployers, Monitors, and Server Administrators) have each been given a set of global permissions and server permissions. Both Administrators and Server Administrators by default have been given all global and server permissions; that is, they function as super users. It is important that these user groups retain these permissions to keep the servers fully functional. However, you should exercise care when assigning individual users to either of these groups, since each such user would immediately have these same permissions.

By default, the Administrators and Server Administrators groups also have Clusters - Create and Cluster - Disband permissions.

The two additional default user groups (Deployers and Monitors) have a very limited set of permissions. These two user groups have been included to illustrate the sort of granularity you might employ when assigning permissions to a group. For example, for Deployers, you might only want to grant them permissions related to deployments (create, delete, deploy, modify, and view deployments).

You can modify permissions for existing user groups, such as the user groups provided by default. You can also create new user groups and then assign global permissions to that group, plus specify whether that user group can act on all servers or just a particular server group.