The Anypoint Platform allows you to create and manage separate environments for deploying, which are independent from each other. This presentation also explains how permissions work across different products and APIs managed feom the Anypoint Plaform.

1. MULE ACCESS MANAGEMENT
MANAGING ENVIRONMENTS & PERMISSIONS
Shanky Gupta

2. 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.

3. 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:

4. • 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.

5. *** 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.

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

7. 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.

8. 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.

9. 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:

10. 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.

11. 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.

12. • 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.

13. *** 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.