When creating secure, cloud-enabled solutions, you must enable identity and access management. With identity and access management, you are able to identify (authenticate) and authorize a user, providing user-specific access to cloud resources, services, and applications.

This document reviews key components of identity and access management and describes how to enable these security capabilities in your cloud solutions.

Know your cloud users

Within cloud environments, you need to account for the different types of users and identities that you’re going to manage. These include:

  • Administrative users: cloud platform administrators, operators, and managers
  • Developer users: cloud application developers, platform developers, and application publishers
  • Application users: users of the cloud-hosted applications

Administrative users

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

  • Application publishers, operators, and administrators: Users in these roles require access to staging and production spaces to create, update, and delete applications and their service instances. These users require full access to the cloud environments.
  • Managers and team leads: These users need insight into their team members’ or employees’ activities. They typically require read-only access to all environments that are used by developers, operators, and administrators.

Administrative users’ accounts are very sensitive, as they are typically authorized to read sensitive information and execute potentially destructive actions. Administrative users’ accounts also require an
increased level of auditing. Attackers that are able to 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 existing applications.

Developer users

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

Developer’s user accounts are sensitive. They are typically authorized to read sensitive information and potentially manipulate applications. As such, they require an increased level of auditing. To meet the regulations of enterprise customers, it must be possible to restrict the access of developers to certain areas of the cloud.

In the case of IBM® Bluemix®, you can enable developers to access only development and staging spaces, and restrict production spaces.

Application users

The 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 in, authentication is often handled by Security Assertion Markup Language (SAML), an Open ID Connect-based (OIDC) repository, or by one of the single sign-on (SSO) Service Social Login options.

Learn more about authentication methods for specific application users.

A comprehensive security strategy encompasses the identity and access management 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.

Create a winning plan

The way that you choose to implement identity and access management in your cloud environment depends on your specific business requirements. You need to choose a cloud provider that supports the strategy you want to implement.

The IBM Cloud® platform supports a number of different strategies for implementing identity and access management in your cloud-enabled applications. First, we’ll look at the key components of identity and
access management. Then we’ll explain each of those components and how you can implement them in your own environment.

Key components of identity and access management

To create a secure cloud environment, you need to account for the following components of identity and access management:

  • Identity service / authentication: Enables applications deployed to the cloud to externalize the authentication of users to a range of
    different identity providers.
  • Single sign-on: Offers a seamless transition between applications, in and out of a cloud environment, without the need to interact with an authentication interface for each application
  • Multifactor authentication: Combats identity theft by adding an additional level of authentication for application users
  • Directory services: Hosts the user profiles and associated credentials that are used to access applications
  • Reporting: Provides a user-centric view of access to resources or a resource-centric view of access by users
  • Audit and compliance: Validates implemented controls against an organization’s security policy, industry compliance, and risk policies and to report deviations
  • User access management: Enables cloud providers to manage user identities in cloud-based platforms, applications, and services


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 the following identity providers:

  • Cloud directory (hosted in the same cloud as the application)
  • Social identity provider (such as Google, LinkedIn, Facebook, Twitter, or GitHub)
  • Enterprise-hosted identity provider
  • Cloud-hosted identity provider

With the proliferation of Software as a Service (SaaS) and API delivery models, API keys have emerged as another source of identities to accommodate.

Single sign-on (SSO)

The single sign-on capability offers a seamless transition between applications – in and out of a cloud environment – without the need to interact with an authentication interface for each application.

IBM Single Sign-On for Bluemix is a policy-based authentication service that provides an easy-to-embed, single sign-on capability for any runtime.

The Single Sign-On service supports several identity sources where your users’ credentials are stored:

  • SAML Enterprise: A user registry with an exchange of SAML tokens that completes the authentication
  • Cloud Directory: A user registry that is hosted in IBM Cloud
  • Social identity sources: The user registries that are maintained by Google, Facebook, GitHub, LinkedIn, and other social networks

For more information, see Single sign-on in the Application Security part of this series.

Multifactor authentication

Multifactor authentication — or additional 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 while also improving 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, operation being performed, preferences, or other factors.

Multifactor authentication is available as a built-in service in IBM SoftLayer. Learn more about this feature.

For Bluemix environments, you can implement multifactor authentication into your environments indirectly through SAML. The third-part identity provider implements MFA 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, for

  • User identities and group or role membership
  • Resource and service descriptions and locations
  • Access policies
  • Directory services typically use a directory access protocol, for example, a lightweight directory access protocol (LDAP) and 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 hosted on the cloud do not need to use their own user repository.

    The Cloud Directory service in SSO service in Bluemix lets users:

    Bluemix Public icon
    Bluemix Local
    Bluemix Dedicated icon

    • Populate the registry with user information
    • Specify password policy
    • Review the API Access settings used with the Cloud Directory Sync feature and with user self-care features

    There are several ways to populate the registry with user information:

    • Cloud directory admin interface: Add users or groups on the Cloud Directory identity source page.
    • Bulk user load: Add multiple users by importing a .csv file that contains the user information.
    • Self-registry: Enable users to register by clicking the Register New User link on the Cloud Directory login page.
    • Cloud Directory Sync: Manage your own local user registry and use the Cloud Directory Sync utility to set up an automatic update of user accounts from the local registry to the cloud directory.


    Reporting can provide a user-centric view of access to resources, or a resource-centric view of access by users. The reports often address:

    • Which users have access to each resource
    • Which access is being exploited by each user, and under what conditions
    • Which users have changes access rights

    Bluemix Dedicated and Bluemix Local

    Bluemix Dedicated icon
    Bluemix Local

    All dedicated and local customers of Bluemix get regular security reports through the Bluemix Admin Console. Reports are generated for the following Bluemix categories:

    • Administrator logins
    • Application developer logins
    • Administrator administrative events
    • Application developer administrative events
    • Administrator database administrative events
    • Admin Console events

    Audit and compliance

    Audit and compliance is an increasingly critical service within the identity and access management 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 efficiently demonstrate compliance to these standards. However, it’s imperative that cloud consumers understand how the cloud provider fits within their overall workload compliance assessment.

    Auditing and compliance in Bluemix

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

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

    This auditing capability applies to all deployment models: Bluemix Public, Bluemix Dedicated, and Bluemix Local.

    IBM Bluemix and IBM SoftLayer auditing resources

    Bluemix Public icon
    Bluemix Local
    Bluemix Dedicated icon

    • Refer to the Bluemix documentation for more details on auditing, compliance, and other security related items.
    • Bluemix is audited by a third-party security firm and meets all the requirements for ISO 27001. Read the report (PDF).
    • IBM SoftLayer works with independent auditors and third-party organizations to meet the industry’s most stringent guidelines to provide reports and information for customer’s own compliance needs. Learn more about the long list of compliance standards that IBM SoftLayer meets.

    Read the Security policy, governance, risk, and compliance document for specific information about compliance.

    Enabling user access management

    The user management capability enables cloud providers to manage user 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 streamlines access control based on the role, organization, and access policies defined by the owner.

    User access management for administrators, operators, and developers

    As outlined above, user accounts of administrators and developers give 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:

    • Provisioning of users into the cloud. Customers want to control whom can access which resources in which role. In Bluemix, you can use the administration feature in the console to add single or multiple users (who) to organizations and spaces (resource) in a Bluemix role (role).
    • Password policies. Customers must be able to control the usage of special characters, minimum password lengths, and similar settings.
    • Multifactor authentication. Many companies want to use multifactor authentication like time-based, one-time-passwords (TOTP). One widely used implementation of TOTP is the “Google Authenticator” app for smartphones.
    • De-provisioning access. When a user leaves the company or switches his or her role, you must be able to immediately revoke the user’s permissions.

    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 are prevented from accessing the login screen. Often, SAML identity providers already support multifactor authentication. We recommend using multifactor authentication capabilities inside the SAML identity provider. Some
    customers even use external service providers that manage their enterprise user accounts.

    Bluemix Public

    Bluemix Public icon

    Cloud user accounts in Bluemix Public are based on IBM Web Identity (IBM ID). Enterprise customers also have the option to do a SAML-based enterprise federation through IBM-wide federation into IBMid.

    To learn how to implement this federation, refer to the IBM ID Federation Adoption Guide. To leverage multifactor authentication, federation with a SAML identity provider that supports multifactor authentication is necessary.

    Bluemix Dedicated

    Bluemix Dedicated

    The enterprise customer can decide to use the IBM ID in a Bluemix Dedicated environment. Additionally, an enterprise customer can decide to either use a SAML federation without using IBM ID or even a direct integration with his enterprise LDAP through a secure VPN.

    To use multifactor authentication, federation with a SAML identity provider that supports multifactor authentication is necessary.

    Bluemix Local

    Bluemix Local

    If you are running your cloud application in a Bluemix Local environment, you can opt to use IBM ID. Typically, enterprise customers decide to directly integrate with their enterprise LDAP server to authorize cloud users.

    IBM SoftLayer

    IBM SoftLayer users are typically administrators, operators, and developers. End users are not using the IBM SoftLayer portal and therefore do not need any access control.

    Grant fine-grained access control to IBM SoftLayer users from the SoftLayer portal. Permissions are grouped by areas, but can also be selected on a per-action base. Grant
    permissions to users based on any or all of the following areas:

    • Administration: Give administrative users permission to add new users, view account summaries, edit the company’s profile, reset passwords, update payment details, submit one-time payments, and cancel a server. You 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 reboot virtual machines (VMs) and 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, like SSL or SSH certificate and key management, access to firewalls, vulnerability scanning, etc.
    • Hardware: Permissions related to hardware give the user the ability to view hardware details, reboot or control the system, manage server monitoring, issue operating system reloads, edit host names and domains, and initiate 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 relevant settings of the customer’s public network.
    • Private network: In this area, you can grant low-level network permissions related to VLANs, tunnels, port controls, etc.
    • Sales: Users with sales permission can add, upgrade, or cancel servers, services, storage, and IP addresses.

    IBM SoftLayer enables users to get permissions to specific areas, making it easier for customers to control permissions based on roles.

    Learn how to adjust a user’s access control settings.

    You can also use IBM SoftLayer APIs to manage these permissions. Read how to enforce permissions on SoftLayer APIs.

    To create a more secure environment, control user’s logins by a login policy – even on a per user basis. You can restrict users from accessing the IBM SoftLayer Portal from specific IP addresses, such as from a customer’s enterprise network. Additionally, you can individually restrict a password’s lifetime.

    Finally, limit visibility and manageability of individual virtual instances and bare-metal servers to a certain set of systems per user.

    User access management for application users

    The application is responsible for managing access and authorization to the app. Authorization is supported in dedicated Bluemix while using corporate LDAP directory as the identity source. Achieve this through the
    application-supported capability of enforcing LDAP group-based authorization. The solution is restricted to local and dedicated Bluemix where corporate directory access is available to web application.

    Learn more about user access management for application users.


    Join The Discussion

    Your email address will not be published. Required fields are marked *