MULE ACCESS MANAGEMENT

MANAGING ENVIRONMENTS & PERMISSIONS

Shanky Gupta

ENVIRONMENTS• The Anypoint Platform allows you to create and manage separate environments for

deploying, which are independent from each other.Environments can either be of production or sandbox type. By default, when creating a new organization you get one production environment named Production.

• Sandbox environments are helpfully restrictive environments for developers and testers, they facilitate safe testing of applications without the risk of affecting the production environment.

• For example, you can create a sandbox environment for a QA team in which they can test new releases of applications before deploying in production. You can add users to a sandbox environment without permitting them to access the production environment, thereby securing production and eliminating the risk of a developer accidentally operating upon an application in production. After you are sure an application is safe to expose to users, you can easily promote the application from a sandbox environment to a production environment.

MANAGING ENVIRONMENTS(ADMIN ONLY)

• To create or manage environments, access the corresponding menu by clicking the menu icon at the top right of the screen and clicking Environments:

• To add an environment, click Add environment. Add a name, click Production or Sandbox, and clickCreate.

• To rename or delete an environment, click its entry in the table.• In the Edit environment menu:

• Update: Change the name and click Update.

• Delete: To delete an environment, click Delete.

• You can’t grant users access to an environment directly, you must do it through the use of roles.

*** IMPORTANT

• Depending on the type of subscription you have on CloudHub, you may be restricted to creating a limited amount of each kind of environment.

MANAGING PERMISSIONS

• Further slides explain how permissions work across different products and APIs managed from the Anypoint Plaform.

ASSUMPTIONS

• It is assumed that you have an Organization Administrator role in your organization, that you have been assigned as the administrator of one of the business groups of your Organization, or that you have API Version Owner permissions and that you want to manage user permissions for an API version, a business group or the entire organization.

HOW PERMISSIONS WORK IN THE ANYPOINT PLATFORM

• In the Anypoint Platform, users belong to an organization and have a set of roles and permissions.

• Each role contains a list of permissions that define what a user that holds that role can do with the specific resources it scopes.Certain Roles come with a set of default permissions. As an Organization Administrator, you can create your customized roles and assign the permissions you see fit, or, depending on the product, you can add permissions directly to a specific user, without the need for roles.

UNDERSTANDING PERMISSIONS

• Depending on the amount of products you have in the Anypoint Platform, you’ll see a set of default types of permissions in every new organization and business group when first created. There is, however, one distinction to make between the permission types:

1. PRODUCT PERMISSIONS

• Default permissions for each Anypoint Platform product (Runtime Manager, Data Gateway, etc). They are environment specific – they grant you the ability to do something within a particular environment, but not to the entire organization.

2. API PERMISSIONS

• Default Permissions for each API managed from the Anypoint Platform. They can be API version specific or they can be extended to all API versions - you can manage user access based on a particular API version, but you cannot extend those permissions to the entire organization.

• You can assign user permissions to edit or view individual API versions or API portals using the following pre-defined roles: API Version Owner and Portal Viewers.

• Since API versions and Products deployment environments are grouped under organizations (and optionally under business groups too), to access them you need to have an account that owns the necessary permissions and that belongs to its corresponding organization or business group (if such resource exists).

• Roles that are assigned at the master organization level can only reference resources that are at the master organization level, roles that belong to a business group can only reference resources within that business group.

*** IMPORTANT

• A user that owns any role of a business group is implicitly granted membership in that business group.Once a user belongs to a business group within an organization, the only way to assign entitlements to that same user in a different business group is by assigning it a role within that second business group.