Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

4 Implementing Identity and Access Management for Cloud Applications

In this chapter, you will learn how to add authentication and manage access to applications deployed on the cloud. This chapter will discuss the patterns to enhance web and mobile apps with identity and access management (IAM) security capabilities.

The following topics will be covered in this chapter:

Authentication pattern for cloud application users
Service-to-service authentication
Cloud application authorization patterns

The following diagram illustrates application IAM patterns:

Figure 4.1 – Application IAM patterns

As shown in the preceding diagram, the patterns cover user onboarding, authentication and authorization patterns for web or mobile, and application programming interface (API) and backend applications.

Authentication pattern for cloud application users

Let’s get started!

Problem

How to manage the onboarding and authenticating of users for a cloud-deployed application.

Context

Modern cloud applications are focused on providing a personalized experience to their users. The application users can be the enterprise’s employees, customers, and partners. To provide a personalized experience for these users, it is important to identify the users and related attributes. A cloud application may be typically developed and deployed following cloud-native technologies, as a set of microservices, leveraging resources and services from multiple clouds. The problem to be solved is how to authenticate the user to the cloud-deployed applications and establish trusted access.

For applications used by employees, most enterprises want to use their existing identity provider (IdP) solutions so that their employees can sign on with their enterprise user identifier (UID) and credentials. Similarly, customers and partners would also like to be onboarded to cloud applications using their own company UID and credentials.

End users such as customers may wish to bring in their own identity (Bring Your Own Identity, or BYOI) or use their social IDs such as Facebook, Google, or GitHub IDs to access the cloud application. Using their existing IDs makes it easy for users to log in to the applications. In certain other cases, users may need to be onboarded just in time (JIT), whereby their ID and credentials are created when they register or sign up for the first time. This is the scenario for enterprises that do not have a known list of their application users or customers, such as applications attracting new customers not previously known to the enterprise. They want to enable their customers to join the application or sign up through a self-service portal.

Another dimension to this problem context is that users of the application like to do progressive authentication—anonymous user get to do progressive authentication. In this model, the application allows the user to browse through unprotected websites without having to log in. Once they sign up or identity themselves, then the user expects personalized experiences based on their attributes or details shared. An unprotected or informational website may not need to identify the user and does not need authentication.

Modern cloud applications allow users to experience parts of the application without having to sign up, and once they like the experience and they need more of it, the application encourages them to sign up. This is a transition from an anonymous user identity to establishing an identity through progressive authentication. For example, users can navigate or add items to a shopping cart through an app without signing up. When they need to check out items or buy items, they need to register and authenticate to make payments.

Modern applications designed in a cloud-native programming model are composed of several microservices running on different clouds. So, the authentication mechanism must support the authentication of users for applications written in multiple languages and running on different clouds—public or private.

Solution

The cloud application’s user type or profile determines the type of authentication method that needs to be used.

Application IAM solutions typically support standards-based integration with several IdPs as well as custom protocols for authentication. The authentication patterns supported by an application IAM solution are shown in Figure 4.2. The entire application IAM solution is available as a service from the cloud and is an integral service in most cloud service provider (CSP) catalogs.

As shown in the following diagram, the application IAM supports the onboarding and authentication of the different types of users, as discussed in the problem context, through different protocols:

Figure 4.2 – Application onboarding and authentication pattern

Employers, customers, or partners that want to leverage their existing user directory and identity infrastructure to authenticate their users perform integrations with the application that are typically done based on standards-based protocols such as Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). These standards help avoid duplication of identities, credentials, and other attributes. Depending on these attributes, users can be put into different groups such as anonymous groups that can have certain rights. Once a user signs up (creates an account, with some amount of validation of the user, even if only self-validation), that user is added to the KnownCustomers group, which has the rights to do things such as make purchases. And it’s also good to note that users can be, and often are, in multiple groups, such as KnownCustomer and StoreEmployee groups, concurrently. Those groups have different rights, of course.

For users that want to do a JIT sign-up with the app, the requirement is typically fulfilled with a Cloud Directory capability. The Cloud Directory pattern, discussed in Chapter 1, may be leveraged for application authentication. Cloud Directory lets the mobile and web applications delegate the management of the users’ details and enable quick sign-up and sign-in. Cloud Directory provides a user registry for applications that scales seamlessly and provides basic authentication such as requiring the user’s email address, mobile number, and password.

Most IdPs support standard protocols such as SAML and OIDC, but a few enterprises still have legacy proprietary identity systems. Wherever standards are missing, users need to integrate with their identity system using custom authentication protocols. In some cases, user details are stored in a file or a database. Integrating these kinds of custom IdPs for application authentication can be painful and, in fact, storing user details in this way creates other security exposures, such as the fact that the file could, itself, be stolen. If possible, the opportunity should be taken to migrate such approaches to a more modern IAM.

Let’s look at the SAML and OIDC protocols in detail next.

SAML

SAML is an open standard for exchanging security information between entities. The building blocks and participants of SAML exchange identity, authentication, attribute, and authorization information. SAML supports web single sign-on (SSO) and identity federation use cases for cloud applications.

As shown in the following diagram, the SAML interaction starts with a user trying to log in to a cloud application. SAML exchanges take place between the cloud application, IdP, and the user accessing the application through a web browser. A login session or a security context is created to evaluate accessing resources managed by that cloud application. This SAML flow, which is typically called a service provider (SP)-initiated flow, is initiated by the cloud application that is also referred to as the SP. In step 2, the cloud application redirects the user to a SAML IdP. A trust relationship is pre-established between the cloud application and the IdP. The IdP redirects the user to a login page. The user then enters the UID/credentials, which are verified against the user identity store. The verification response is provided back to the IdP, which in turn provides a SAML response to the cloud application:

Figure 4.3 – SAML protocol

Based on the response from the IdP, the cloud application can make an authorization decision based on the assertions in the SAML response. The SAML response does not contain any user credential information. The SAML specification also defines a structure, schema, and protocol for the exchange of these messages between the parties. Communication between the SP and IdP is encrypted and encoded for security purposes. Refer to the SAML site for more details on the standard (http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html).

OIDC

There will be a population of application users that want to bring in their identity (BYOI) or social logins to authenticate themselves for access to the application. This model is again managed through standards-based integration. The most frequently used standard is OIDC. Enterprise identity management (IdM) is also transitioning from SAML to OIDC as a preferred protocol for integrating with cloud applications.

OIDC is a lightweight identity layer built on top of the Open Authorization (OAuth) protocol. OIDC supports cloud applications to verify the identity of the user based on the authentication performed by an authorization server. This authentication information is shared in an interoperable and REpresentational State Transfer (REST)-like manner: friendly and secure.

As shown in the following diagram, OIDC allows the cloud application user’s authentication to be done with the help of an IdP:

Figure 4.4 – OIDC protocol

The user logs in to any cloud application that supports OpenID authentication by using their accounts. OpenID supports SSO by allowing single credentials for authenticating to multiple cloud applications. The application redirects the user to an identity service supporting the OIDC protocol. The identity SP (IDSP) redirects the user to the login page for the user to enter their user details and credentials. The IdP stores the user details, and the applications create accounts for their use. The identity service returns an authorization code to the requestor. In this authorization code flow pattern, the application exchanges the authorization code for a token. This exchange requires a client secret that has to be available with the cloud application. Typically, a server-side application requires an end user; however, it relies on interaction with the end user’s web browser, which redirects the user and then receives an authorization code. On successful authentication, the IdP returns the user profile claims as a token against the authorization code. This identity token contains authentication information. OIDC recommends JavaScript Object Notation (JSON) as the data format for exchanging information in a language-neutral, text-based, and lightweight manner. The tokens exchanged are implemented as JSON Web Tokens (JWTs) (Request for Comments (RFC) 7519) that clients receive after successful user authentication.

The claims could vary, depending on the backend authentication service. JWT is a JSON format useful for exchanging information between parties. It contains most claims found within access tokens, but also includes user identity claims, such as name, email, locale, and picture. Identity tokens are used to understand who the user is. User identity claims come from IdPs and depend on how the application requires users to authenticate. Both tokens are cryptographically signed with tenant-specific keys to prevent tampering and contain a set of claims that help developers to customize application behavior and make business logic decisions. Please refer to the links provided in the References section for details on the OIDC standard and protocol, as well as details on JWT.

Known uses

We will look at some known uses here:

AWS Cognito (https://aws.amazon.com/cognito/) is a secure and scalable identity store as well as supporting users signing in to cloud applications using social and enterprise identities. Amazon Cognito supports application identity integration with social IdPs such as Apple, Google, Facebook, and Amazon, and enterprise IdPs leveraging SAML and OIDC patterns.
Azure Active Directory (Azure AD) (https://docs.microsoft.com/en-us/azure/active-directory/external-identities/identity-providers) is a multi-tenant, cloud-based IAM service that supports IdPs for external identities, including social IdPs such as Google and Facebook, and setting up federation with any external IdP that supports the SAML or Web Services Federation (WS-Fed) protocols.
Google Identity Services (GIS) (https://developers.google.com/identity) enables users to sign in to apps and authorize apps to use Google services. Android and web authentication API flows support the custom login widget for sign-in and sign-up options. GIS APIs conform to the OIDC specification for both authentications.
IBM Cloud App ID (https://www.ibm.com/cloud/app-id) allows easy adding of authentication, secure backends, and APIs, and managing user-specific data for mobile and web applications. App ID allows you to enhance applications with advanced security capabilities, such as multi-factor authentication (MFA), SSO based on standards, and user-defined password policies. App ID also provides a scalable user registry for users to manage their own accounts.

Service-to-service authentication

Let’s get started with service-to-service authentication!

Problem

How to onboard and authenticate services for a cloud-deployed application.

Context

Apart from users, systems and services interact with cloud resources and cloud applications to deliver functionality. There is a need for a standards-based approach to be able to implement effective and efficient service access to applications in the cloud.

Traditionally, security is enforced at the edge layer for a monolithic application, and subsequent interactions are considered secure. This is like an entry check at the gate of a mansion, and then no authentication is required to enter different rooms of a building. But in cloud-based applications, there are multiple microservices, and they need to communicate with each other to deliver the function. Authentication is required at each service entry point. This is like an identity check for entering each room in the mansion. These services are likely to communicate with each other using either asynchronous or synchronous means. Many of these services may be private or require explicit authentication for access. One service calls another receiving service, using its endpoint Uniform Resource Locator (URL). Application IAM is required at the boundary of each of these services to establish a service identity. For the receiving service, the user identity on behalf of whom the service is invoked also needs to be considered for determining the set of permissions needed to perform the work.

Another example is where a client, such as a mobile application, directly invokes a cloud service or needs access to a protected resource on the cloud, such as a backend API. The actions or the backend APIs invoked could be different based on the user identity. If we consider this as north-south direction service interaction, there is also a need to secure east-west interactions between the services on the same cloud or on different clouds. Please see the following Solution section for details on patterns applicable for each case.

Solution

A cloud application can have its own identity and credential (application access key or public key certificate) and use that identity to authenticate and access any cloud resource. The service access to services such as storage or runtimes is subject to access-control rules specified based on those resources. In a cloud-native programming model, an application is formed of many services. Each service can also have its own identity. Please read the concept of service ID (SID) or service account, discussed in Chapter 3, for details. This identity is used to mutually authenticate with an invoking application or with other cloud services. With the use of application identity and credentials passed as a token, cloud applications can uniquely identify other applications or services. By using an access token, protected resources are provided access only after validation of the token to establish it is originating from a trusted, authenticated source.

You can see an illustration of the process in the following diagram:

Figure 4.5 – Service-to-service authentication

For several reasons, one application needs to communicate with another service or application without any user intervention. For example, as shown in the preceding diagram, a non-interactive or backend application needs to access another application to perform its work. This application could have requirements to access another set of cloud services to fulfill its tasks. For instance, if service A needs to access service B, it needs to propagate its own service identity as well as additional information such as the invoker or the user identity. The important aspect to consider is that the requests are exchanged on behalf of the application, not on behalf of an end user. So, the first check is to ensure that the service or application is authenticated and authorized to access the target service or application. But depending on the application design, access control for service B could be based on the propagated user identity and not the invoking service’s identity. The identity is propagated in the form of tokens, as discussed in the pattern for user authentication for cloud applications. There are multiple patterns for managing authentication and authorization for service-to-service interactions, depending on the use case.

Client application accessing a protected resource on the cloud

In this pattern, as shown in the following diagram, the user accesses the cloud resource through a client-side application such as a mobile application. The protected resource or service is invoked on behalf of the end user. The user identity token needs to be passed to make a successful invocation. The cloud service or protected resource, upon receiving the tokens, can validate them and action the request accordingly. As discussed in the preceding pattern, the receiving cloud service may need to interact with other services to deliver the functionality. In this case, the tokens are propagated downstream for user authentication and authorization:

Figure 4.6 – Client application directly accessing cloud resource

Application accessing a protected resource on the cloud through a gateway

The gateway pattern, as shown in the following diagram, is very similar to the pattern of the client application directly accessing the protected resource on the cloud. The variation in this pattern is that security is enforced at the edge or gateway. This assumes that subsequent layers are considered secure:

Figure 4.7 – Managing authentication and authorization at the gateway

Once the identity is authenticated at the gateway level, subsequent services need not enforce checks.

Application accessing a protected resource on the cloud through another service

As shown in the following diagram, in the pattern where trust cannot be established with client applications such as browser applications, we can take the approach of routing access to the protected resource through a server-side service:

Figure 4.8 – Managing authentication and authorization through a server-side service

The variation from the preceding patterns of clients directly or through a gateway is that the identity tokens remain on the server side and are not exposed outside. In this pattern, a user requests a backend resource through the client application. The client application interacts with the backend service or server application. The backend service then invokes the service to access the protected service or resource on the user’s behalf. All the interactions may not involve an end user. Based on mutual trust between the microservices, one service can get results from another service and pass back the information to the client service, which provides it to the user.

Service mesh pattern

For certain scenarios, a central gateway model fails to address the security need for agility and evolution of a microservices model that needs protection for inter-service interactions’ cloud environment (east-west communications) as well. In this service mesh pattern, there is a control plane that manages the overall topology and configuration. The data plane of the service mesh manages communication between the services.

As shown in the following diagram, the service mesh pattern is non-intrusive or does not introduce any new functionality in the service or application:

Figure 4.9 – Service mesh pattern

With this architecture, the service-to-service communication policy and governance are managed by the control plane as opposed to the individual services. The security functionality in the service mesh pattern is achieved by a set of sidecar proxies. Sidecar proxies sit in between the client and target service, check for security, and then forward to the target service endpoint. Similarly, responses are verified and security is checked by the proxy before returning to the invoker.

The service mesh pattern can be extended across multiple cloud and on-premise environments, making it a good choice for implementing micro-perimeter-level authentication and authorization, leveraging a central or federated control plane.

Some of the merits of adopting this pattern include the following:

With the service mesh pattern, there is no need to duplicate the functionality or repeat the code in each service for enforcing authentication and authorization
This is aligned with the zero-trust security model that goes beyond perimeter-based protection and enforces security for each microservice (micro-perimeter level) even inside the trusted zone
The service mesh pattern can also enforce mutual trust through Mutual Transport Layer Security (mTLS) for inter-service communication
The service mesh can help protect against service impersonation or unauthorized access as only authenticated services can communicate through the mesh
Any risk of insider threat related to data exfiltration or man-in-the-middle (MITM) attacks between clients and protected resources can also be eliminated with the service mesh pattern

Known uses

We will look at some known uses here:

AWS Cognito, Azure AD, GIS, and IBM App ID services support patterns accessing a protected resource on the cloud through a gateway pattern as an API gateway solution integrated with the application IAM service.
Similarly, access to microservices or backend APIs running on Kubernetes clusters may be protected at the ingress level with authentication. The ingress controller provides a mechanism where you can define a policy that will be enforced to delegate all needed authorization and authentication to the ingress controller of the applications.
Istio, Linkerd, AWS App Mesh, and Consul Connect are some of the top service mesh tools that support communication between microservices in a Kubernetes environment. They can be leveraged to build service mesh authentication and authorization patterns.

Cloud application authorization patterns

Let’s get started with cloud application authorization patterns!

Problem

How to manage access to different application functionality for users or services.

Context

Authorization determines what a user or a service is permitted or not permitted to do inside the application. Once a user or service identity is established, there is a need to establish which actions they can perform with the application.

Solution

Authorization is a method of allowing or denying access to a particular resource depending on an authenticated user’s or service’s entitlements. The authorization could work at two levels, as follows:

Coarse-grained—High-level and overarching entitlements defined as create, read, update, delete (CRUD) sorts of permissions at the service or protected resource level
Fine-grained—Detailed, explicit, and specific entitlements to protected resources based on additional factors such as time, location, department, role, and other attributes

Authorization in a cloud environment is attained by either access-control policies or access right delegations. The authorization process decides which user or service is allowed to perform certain operations on the system or application.

Authorization rights can be managed centrally, which keeps sensitive information in one place. This model has reduced management and security costs for keeping the information secure. Alternatively, it could be handled by each third-party application in a distributed style. This has a risk that the user’s private information can be accessed by multiple applications. Such permissions are unsafe since the privacy of the user is involved.

A cloud network contains different SP environments in which a single user is able to access different kinds of services at the same time while each service is from a different SP and with different security levels. Sometimes, authorization rights are given by third-party vendors, and these third-party applications are authorized to access certain private information. Such permissions are unsafe since the privacy of the user is involved. Authorization in a cloud environment is attained by either access-control policies or access-right delegations. The CSP defines and implements access-control policies such that the resources and services are accessed only by authorized users. Centralized access-control mechanisms are advantageous to organizations in securing sensitive information and reducing several management and security tasks.

Cloud applications implement one or a combination of multiple of the following access-control patterns to address the authorization requirements.

Mandatory access control

Mandatory access control (MAC) takes a confidentiality-first approach. It limits access based on the sensitivity of the information and the need to know from a user’s perspective.