| copyright | lastupdated | ||
|---|---|---|---|
|
2017-11-16 |
{:shortdesc: .shortdesc} {:codeblock: .codeblock} {:screen: .screen} {:new_window: target="_blank"}
{: #iamconcepts}
The identity concept in {{site.data.keyword.Bluemix_notm}} IAM consists of the following components:
- User identities
- All users are identified by their IBMid.
- Service and app identities
- Service IDs are the Cloud IAM feature that is used to provide a separate identity for services and applications. You can create a service ID to be used by an application that needs access to your {{site.data.keyword.Bluemix_notm}} services so that individual user credentials do not have to be used.
- API keys
- Platform API keys are available through Cloud IAM for you to use to authenticate by using API or CLI as a user or service ID. These API keys are provided through Cloud IAM and therefore cannot be used generally to authenticate with IBMid outside of IBM Cloud.
- Resources
- {{site.data.keyword.Bluemix_notm}} resources are identified by their cloud resource names (CRN). For more information, see [Cloud Resource Names](/docs/iam/crn.html).
The concept of access management in {{site.data.keyword.Bluemix_notm}} consists of a few interrelated components, including users, resources, policies, roles, actions, and the Cloud IAM control system, which allow users to take actions on resources within an account.
You can review the following list to learn more about these Cloud IAM components:
- Users
- All users within an account are identified by their IBMids. Users can be invited to the account and given access to resources. Access can be assigned to individual resources, down to the instance level, or to a set of resources that are organized in an account resource group.
- Resources
- Account resources are the provisioned service offerings that are selected from the catalog or finer-grained resources within a service instance.
- Policies
- Policies are how users or service IDs in the account are given permission to access account resources. Policies include a subject, target, and role. The subject is the user or service ID that you are providing access to. The target of the policy is the resource to which you want to provide access. And, the roles are the way to define the level of access or allowed actions on the target of the policy. There are three types of policies that allow access to account resources: a resource group policy, a resource instance policy, and an account-wide policy for access to all Identity and Access enabled services. Depending on your selections, there might be custom configuration options such as defining access down to resources in a specific region or defining access to the granular level of a service-specific resource within an instance.
- Roles
- Cloud IAM access roles allow a user to complete specific tasks on the resource that is defined in the policy. There are two types of access roles: platform management and service access. Platform management roles define allowable actions for managing resources at the platform level including user access, creation of instances and service IDs, and managing resource groups, for example. And, service access roles define allowable actions within the context of using the service. These roles are customized based on the service that is selected within the policy.
- Actions
- Actions are mapped to the Cloud IAM roles to enable users to perform only specific tasks when they are assigned the different roles. Allowable actions for each role might change based on the service that is being accessed because each service defines how that role maps to the use of the service.
- Access management system
- The Cloud IAM control system permits or denies actions by users within the context of a service based on the assigned policy. When a user tries to complete a specific action, the control system uses the attributes that are defined in the policy to determine whether the user has permission to perform that task.