+

Search Tips  |   Advanced Search

Manage identity and access for cloud admins, app developers, and users

When creating secure, cloud-enabled solutions, enable identity and access management (IAM) to identify (authenticate) and authorize a user to provide user-specific access to cloud resources, services, and applications.

The whole suite of IAM can be compartmentalized into three main areas:

The main goal of identity and access is to identify the right users by using the correct credentials to access the right resource for the appropriate purpose. Identity and access involve describing and handling the roles alongside the access privileges. Access is granted or denied based on the roles and scenarios that an individual is entitled to. After the identity is established, it can then be managed, modified, or removed based on the circumstances over the lifetime of the identity.

In a business-to-business scenario, API Security enables IAM, which can be integrated with the cloud-based microservices. In scenarios where customer identity and access must be handled, it can be done through self-service capabilities and profile management to authenticate users to systems. Identity can be offered as identity as a service (IDaaS), through which the single sign-on (SSO) capabilities can be applied to access applications. Beyond the SSO feature, multifactor authentication and identity governance can also be applied.


Identity and service providers

An Identity Provider (IdP) is a federation partner that vouches for the identity of a user. The IdP authenticates the user and provides an authentication token, which is information that verifies the authenticity of the user, to the Service Provider (SP).

The IdP can authenticate a user directly or indirectly. An example of direct authentication is validating a username and password. Indirect authentication might involve validating an assertion about the user's identity as presented by a separate IdP. The IdP handles the management of user identities to free the SP from this responsibility.

An SP is a federation partner that provides services to the user. Typically, SPs don't authenticate users but instead request authentication decisions from an IdP. SPs rely on IdPs to assert the identity of a user, and typically certain attributes about the user managed by the IdP. SPs might also maintain a local account for the user along with attributes that are unique to their service.

Many organizations have their own IdPs and want to use those capabilities when they use IAM in their solutions. Organizations that don't have an IdP rely on solutions that give them IdP capabilities. Those organizations work as SPs and use the IdP that is provided to them.


Cloud layers and IAM

When you look at a hybrid-cloud environment, you can identify layers that are built on each other. Those layers require unique IAM thinking.

The bottom-most layer is the Cloud Infrastructure layer, which provides a single platform for global data centers. This layer provides bare metal and virtual servers that are hosted on first-class computing, storage, and networking gear. The servers are deployed and managed to ensure complete support for all of workloads. In addition, this layer includes capabilities such as database services. The infrastructure layer is traditionally accessed by a few administrators and automation processes and is controlled by the IAM component of the cloud platform. Governing access to the infrastructure is an important task and normally requires some level of privileged access management.

Layered on top of the infrastructure is the Container Platform layer, such as Red Hat® OpenShift® Container Platform. The Container Platform orchestrates containers and manages their lifecycles for developers and their DevSecOps processes. The Container Platform layer is accessed by several developers and automation processes and is controlled by the IAM component of the container platform.

Applications run on the Cloud Infrastructure and Container Platform layers and serve users. Unlike the other layers, applications can have many users, and no specific IAM component controls applications. For business-to-employee applications, users are employees in a specific enterprise. For business-to-consumer applications, users are the customers that are served by the application.


Cloud users

Administrative users

Administrative users typically have one of the following types of roles:

Administrative users' accounts are sensitive because they're typically authorized to read sensitive information and run potentially destructive actions. Administrative users' accounts also require an increased level of auditing. Attackers that can capture such an account can steal data from production database service instances, deploy malicious applications inside the customer's domain, or even deface or destroy applications.

Privileged accounts are used by system administrators who manage an environment or who play the role of IT administrator for specific hardware and software. Administrative users with privileged accounts can instantiate and configure cloud resources, install software, reset passwords, access sensitive data, and log in to machines in one or more environments. Administrative users can also use their elevated privileges to make specific changes to the IT environment. The accessing entity varies from devices, databases, and servers to applications.


Developer users

Developers must be able to create, update, and delete an application. They must also be able to create service instances and bind those instances to the application.

Developers' user accounts are sensitive. They're typically authorized to read sensitive information and potentially can manipulate applications. As such, they require an increased level of auditing. To meet the regulations of enterprise customers, you must be able to restrict the access of developers to certain areas of the cloud.

We can enable developers to access only development and staging spaces and restrict production spaces.


Application users

A web application's audience determines the authentication model that is used. For an unprotected website, you don't need authentication. For websites that require sign-on, authentication is often handled by Security Assertion Markup Language (SAML), an Open ID Connect-based (OIDC) repository, or by one of the App ID Service Social Login options. For more information about authentication methods for specific application users, see Application security.

A comprehensive security strategy encompasses the IAM requirements of all of these users. The solution must be catered to a wide audience, including organizational users, internet and social-based users, third-party business partner organizations, and vendors. IBM Security Verify provides identity-as-a-service for every user, including SSO, risk-based MFA and adaptive access, user lifecycle management, and identity analytics.

Try IBM Security Verify


Key components of IAM

The way that you choose to implement IAM in your cloud environment depends on your specific business requirements. Choose a cloud provider that supports the strategy you want to implement. The IBM Cloud platform supports many different strategies for implementing IAM in your cloud-enabled applications. To create a secure cloud environment, you need to account for the following components of IAM:


User identity, authentication, and authorization service

Authentication, or the identity service, enables applications deployed to the cloud to authenticate users at an application level, based on a range of identity providers. For example, the identity service recognizes a subset or combination of these identity providers:

With the proliferation of software as a service (SaaS) and API delivery models, API keys have emerged as another source of identities to accommodate. With IBM Cloud™ App ID, you can add authentication to your web and mobile applications and secure your cloud-native applications and services on IBM Cloud. IBM Cloud App ID manages user-specific data that you can use to build personalized application experiences.

IBM Cloud App ID is designed for developers to get authentication and authorization working, abstracting away complex security functions. To integrate authentication into your application, you can use an onboarding wizard to create a working sample application with Google and Facebook authentication or that uses email and password. IBM Cloud App ID has a highly scalable cloud directory to store user records in the cloud. It has client SDKs for iOS and Android, REST APIs, server SDKs for Node.js and Swift, and a customizable login UI widget that you can use to integrate authentication into your application. For other languages such as Python, you can use the IBM Cloud App ID REST APIs.

We can use authentication filters to secure cloud-native applications, and services are secured from unauthorized access. IBM Cloud App ID is built with open standards (OAUTh2, OIDC). It supports both anonymous and authenticated users. If users start anonymously and later authenticate, applications can continue to use the information that was previously stored for them. It also provides storage for user data, such as application preferences or information from public social profiles, which you can use in your applications.

Try IBM Cloud App ID and learn how to use it for your application user authentication scenarios.

Try IBM Cloud App ID


Multifactor authentication

Multifactor authentication, or extra authentication controls, is used to combat increasing levels of identity theft. Examples of multifactor authentication include single-use passwords, certificates, and tokens.

To maintain the user experience and improve login security, risk-based authentication controls are typically used. These controls change the level of required authentication based on a user's location, past activity, the operation that is being done, preferences, or other factors.

Multifactor authentication is available as a built-in service in IBM Cloud infrastructure offerings. For IBM Cloud environments, you can implement multifactor authentication into your environments indirectly through SAML. The third-party identity provider implements multifactor authentication on your behalf.


Directory services

Directory services support the identity service by hosting the user profiles and associated credentials that are used to access applications. Directory services can be used to host a range of information, from user identities and group or role membership to resource and service descriptions and locations to access policies.

Directory services typically use a directory access protocol, such as a lightweight directory access protocol (LDAP). They can be shared across components in an application, across applications, or across organizations.


Cloud directory services

Cloud directory services securely manage user profiles and their associated credentials and password policy inside a cloud environment. A directory service within a cloud means that applications that are hosted in the cloud don't need to use their own user repository.

With the Cloud Directory service in IBM Cloud App ID, users can do these tasks:

We can populate the registry with user information through the cloud directory admin interface, bulk user load, or self-registry.


Privileged access management

As cyberthreats continue to increase and use insider privileges to attack, effective privileged access management (PAM) is critical. PAM solutions such as IBM Secret Server help you secure privileges for service, application, root, and administrator accounts across your enterprise. In implementing PAM, you need to understand and audit privileged access, automate password changing, complete real-time session monitoring and control, and secure the identities that are used in your DevOps workflows.

A key part of securing your organization is ensuring that you're integrating identity into the broader security landscape to mitigate internal and external threats. Two key parts of that process are as follows:

Be sure to implement privileged activity monitoring where logs are sent from your PAM solution to your enterprise-wide security information and event management (SIEM). Such monitoring provides insights into the use of privileged accounts and can correlate privileged account governance and access to activities that are done on target systems. Those activities include correlating operating system, application, and database event logs with IBM Security Secret Server and IBM Security Privilege Manager logs.


Identity governance

Identity governance solutions, such as IBM Security Identity Governance and Intelligence (IGI) help security operators control user permissions on resources and get a clear picture of allowed access and potential security risks.

Seek to extend your identity governance and use it to also govern access to your cloud infrastructure and container platform resources. Identify governance connectors to the various cloud resources and make those resources available for employees in governance flows, such as access request and approval. Then, managers can give developers and administrators access to the various cloud resources that they need based on business needs.


Reports

Reports can provide a user-centric view of access to resources, or a resource-centric view of access by users. Reports often address which users have access to each resource, which access is being used by each user, and under what conditions, and which users have changed access rights.

For more information about the reporting capabilities of IBM Cloud, see Monitoring and intelligence.


Audit and compliance

Audit and compliance is an increasingly critical service within the IAM framework, both for the cloud provider and the cloud consumer. These processes are required for the auditor or risk officer to validate implemented controls against an organization's security policy, industry compliance, and risk policies, and to report deviations.

Compliance standard such as HIPAA, PCI/DSS, and NERC are mandatory for specific industries, and an automated report helps organizations to efficiently demonstrate compliance to those standards. However, cloud consumers must understand how the cloud provider fits within their overall workload compliance assessment.


Auditing and compliance in IBM Cloud

Audit logs are created for all successful and unsuccessful authentication attempts by application developers. Audit logs are also created for privileged access to Linux® systems that host the containers where IBM Cloud applications run.

For all IBM Cloud deployments, IBM uses the IBM Security QRadar® tools to consolidate Linux logs to monitor privileged access on Linux systems. IBM Cloud also uses IBM security information and event management (SIEM) to monitor successful and unsuccessful login attempts of application developers.


IBM Cloud auditing resources

For more information about auditing, compliance, and other security-related items, see the IBM Cloud documentation.

IBM Cloud is audited by a third-party security firm and meets all the requirements for ISO 27001. IBM Cloud works with independent auditors and third-party organizations to meet the industry's most stringent guidelines to provide reports and information for the customer's own compliance needs. Learn more about the compliance standards that IBM Cloud meets.

For more information about compliance, see Security policy, governance, risk, and compliance.


Enable user and service access management

The user and service management capability enables cloud providers to manage user and service identities in cloud-based platforms, applications, and services. With efficient user management, cloud-deployed applications can provision and de-provision customer, partner, and vendor user profiles with minimal human interaction. This capability streamlines access control based on the role, organization, and access policies that are defined by the owner.


User access management for administrators, operators, and developers

The user accounts of administrators and developers give them access to sensitive information, so potential attackers can manipulate applications. To mitigate this risk, customers require maximum control over the whole lifecycle of these users. In particular, cloud owners want to control these items:

To meet these requirements, many customers use an internal solution like an enterprise-owned SAML identity provider. The SAML identity provider is accessible only through the enterprise network, so attackers can't access the login screen. Often, SAML identity providers already support multifactor authentication. We can use the multifactor authentication capabilities that are inside the SAML identity provider. Some customers even use external service providers that manage their enterprise user accounts.


IBM Cloud authentication

IBM Cloud user accounts are based on IBMid. Enterprise customers can also do a SAML-based enterprise federation through IBM-wide federation into IBMid.

To learn how to implement this federation, see the IBMid Federation Adoption Guide. To use multifactor authentication, you must use federation with a SAML identity provider that supports multifactor authentication.

In addition to interactive authentication by using IBMid, IBM Cloud allows users to create API keys. We can create an API key in the IBM Cloud console. API keys can be used to log in to the IBM Cloud CLI or log in to IBM Cloud platform by using the Cloud Foundry (CF) CLI.

API keys give you the following benefits:


IBM Cloud authentication for applications and services

To enable an application or service to authenticate itself as an identity, we can create a service ID. As with users, you can assign policies to this service ID. If you create service instances in IBM Cloud or if you create service bindings to IBM Cloud services, new service IDs can automatically be created for you.

We can create one or more API keys for authenticating service IDs. API keys are the only method to authenticate service IDs. API keys for service IDs have similar characteristics as API keys for users. If the service ID is used for different purposes or in different CLIs, create multiple API keys. To rotate API keys, create an API key, replace the old API key with the new one in the client or CLI, and delete the old API key.

For more information about service IDs, see Creating and working with service IDs. For more information about API keys for service IDs, see Managing service ID API keys.


IBM Cloud infrastructure

IBM Cloud infrastructure users are typically administrators, operators, and developers. Users don't use the IBM Cloud customer portal and don't need any access control.

We can grant fine-grained access control to IBM Cloud users from the customer portal. Permissions are grouped by areas, but can also be selected on a per-action base. The following table shows areas that you can base user permissions on:
Area Permission
Administration Give administrative users permission to add users, view account summaries, edit the company's profile, reset passwords, update payment details, submit one-time payments, and cancel a server. We can set or revoke these permissions with a single click, or grant a user individual permission for each action.
Support Permission in the support area gives the user the ability to restart virtual machines (VMs) and complete all support ticket-related activities, including viewing, updating, and creating tickets.
Security Permissions in the security area enable the user to manage several security-relevant areas, such as SSL or SSH certificate and key management, access to firewalls, and vulnerability scanning.
Hardware Hardware permissions give the user access to view hardware details, restart or control the system, manage server monitoring, issue operating system reloads, edit hostnames and domains, and start RescueLayer.
Software In this area, a user gets permissions to view several software products.
Public network Thirteen fine-grained permissions allow users to control all the relevant settings of the customer's public network.
Private network In this area, you can grant low-level network permissions that are related to VLANs, tunnels, port controls, and more.
Sales Users with sales permission can add, upgrade, or cancel servers, services, storage, and IP addresses.

IBM Cloud enables users to get permissions to specific areas so that customers can control permissions that are based on roles. We can also use IBM Cloud APIs to manage these permissions. See the IBM Cloud documentation.

To create a more secure environment, control users' logins by a login policy, even on a per user basis. Restrict users from accessing the customer portal from specific IP addresses, such as from a customer's enterprise network. We can also individually restrict a password's lifetime. Finally, you can limit the visibility and manageability of individual virtual instances and bare-metal servers to a certain set of systems per user.


IBM Cloud IAM

IBM Cloud consolidates the management of users and their access to different services in a new IAM view. From this view, you can do these tasks:

To define access for users and service IDs, create a policy that connects that identity (user or service ID) to a resource group or resource by specifying one or more roles for that identity. For roles, you can select from the following platform management roles: Viewer, Editor, Operator, or Administrator. Services can bring their service-specific roles, such as Reader, Writer, and Manager for the Object Storage service.

For more information about assigning policies, roles, and their meanings, see the IBM Cloud documentation.


More Info