Intro to IAM - Resources

Welcome to Equinix!

This discussion post is the first in a short series that I think might help you hit the ground running as you begin your digital transformation journey. Before we get too much further, let’s establish some IAM terminology that we’ll be using a lot in the sections to follow.

If you'd prefer to watch along, here's a spotlight video on IAM 

and here's a short primer on Resources, Projects, and Organizations

 Benefits and Features of IAM

Our robust IAM framework simplifies access for employees and customers through single credentials and secure authentication, and provides several other benefits:

• Greater security - Streamlined digital identities reduce risk and exposure to threats like data breaches and phishing.
• Centralized control -Role-based access control (RBAC) allows for centralized management of authentication and access rules.
• Regulatory compliance - Enhanced visibility and control help meet regulatory requirements.
• Customer Resource Hierarchy (CRH) – View and manage the structure of organizations, projects and resources.
• Access Management (AM) – Add users and grant access to the user in a given resource. Create custom roles that suit your internal organization setup.
• Identity Management – Manage your access and security settings. Link your accounts and switch between them without having to re-login.

Resources

Resources, (also known as Assets), are the building blocks that reflect your organization. These include different types of organizations, projects, connections, and virtual devices.

Customers can create organizations, projects, and manage billing account assignment to build a resource hierarchy that feels familiar and matches the setup and operations of their organization. 

Every node in the customer resource hierarchy is a resource which can be accessed and controlled using IAM. A digital resource such as a Fabric port or Virtual connection would be a leaf node in the resource hierarchy and would also be referred to as an asset.

Organizations

Organizations allow you to model your resource hierarchy so that it matches your actual organizational setup. Organizations can also serve as parent nodes for other organizations or for projects. 

Projects

Projects enable the convenient assignment and management of assets required for your end-customer or internal project's needs. 

In this example, the reseller has created separate organizations and projects for their end-customers. Each project entity has been assigned a set of product specific assets required to carry out a given end-customer commitment.

Default Projects

A default project is created by the system whenever a new first level organization is created. Default projects belong under the first level organization and are immutable, which means this organization can’t be deleted, renamed, or moved anywhere in the resource hierarchy.

Projects

A project is an entity within the customers resource hierarchy, A project is used to group multiple digital assets so that they can manage access rights to users spanning multiple projects. Projects are the second to last node in the resource hierarchy and are also parent of all digital assets.

In the example shown above, the Resources/Assets (shown in yellow) are nested inside the Projects (shown in orange), which then fall under two Organizations (shown in red).User Access

User Access

Users assigned to an organization automatically inherit access to organizations and projects nested under the given organization node. This applies to existing organizations and projects as well as future organizations and projects created under this organization. Changes in role assignments on a specific hierarchy level are also reflected in the underlying organizations and projects.

In the example Organization above, Joe has been assigned to the "Moonshot International" organization. Through inheritance, he can access all organizations and projects nested under the Moonshot International organization. Joe has also been explicitly assigned to the Nucleus project.

Here are some things to consider when an organization or project is moved under a new parent organization:

• Users explicitly assigned to the organization or project will still be able to access it, and organizations and projects nested under it, after it's moved to a new target organization.
• Users that inherited access to it from the current parent organization, will no longer be able to access the organization or project.
• Users that have access to the new parent organization, by being explicitly assigned to it or through inheritance, will gain access to the organization or project being moved.

Hopefully this discussion post and the video primers provided helped paint a picture of how customers are structuring their Organizations using IAM and got familiar with some of the "building blocks" in the Equinix IAM Portal. Next time we'll take a look at users and roles! 

Reference Documentation:

Equinix Product Documentation

Equinix Fabric

Equinix Network Edge

About Identity and Access Management (equinix.com)