The Interaction Between Identity Cloud and Akamai Edge Services
Akamai Identity Cloud is a purpose-built customer identity and access management (CIAM) platform specifically architected to meet the needs of application owners and API providers’ consumer identity needs. As a cloud-based SaaS offering, all interactions with Identity Cloud occur over the public internet. And as an integrated part of the larger Akamai Intelligent Edge Platform, Identity Cloud transactions benefit from many of the same services that Akamai customers do — namely, Ion for application acceleration and Kona Site Defender for web security and DDoS protection.
All request/response interactions with Identity Cloud, either front channel direct from the end user or via back-channel communication from application infrastructure, are accelerated by Ion and protected by Kona.
But there’s a bit more to this story, because many Identity Cloud customers are also users of these same Akamai acceleration and security services. And through the magic of DNS CNAMEs, these Akamai customers are also able to apply their instances of Ion, Kona, and even Bot Manager and Client Reputation…with their settings and their rules…to their Identity Cloud web-based transactions.
The purpose of this post is to explain the various interactions across user, application, and Identity Cloud — and where exactly, architecturally speaking, customer-managed Akamai services are invoked vs. where Akamai services that are solely managed by Identity Cloud engineers are invoked.
The following diagram helps to describe these distinctions…
In the rest of this post, we’ll be breaking down this diagram in more detail.
An Overview
At a high level, this diagram represents the various possible elements of an Identity Cloud setup and the interaction points between those elements. Some elements always exist, while others may or may not exist.
- In the bottom right, we have Identity Cloud itself. This encompasses all the storage and services that go along with managing consumer identities. As we’re discussing Identity Cloud architectures, this will obviously always exist.
- On the left, we have the various user agents where our end users interact. Web browsers and mobile apps are the most common, of course, but this can also include PoS systems and IoT devices. These are common, though wouldn’t exist in a machine-to-machine use case.
- We see “Akamai Edge Proxy” with smaller boxes, one labeled “Akamai-Managed” and “Included,” the other “Customer-Managed” and “Optional.” This is the Akamai edge platform, where the Ion performance optimizations and security features like Kona Site Defender get enabled. In a second, we’ll unravel the difference between the two boxes.
- In the upper right there’s a box for “Customer Infrastructure,” which is labeled as “Common.” This is where Akamai’s customer application server, web server, and microservice servers run. These may be on-prem or in the cloud. While some simpler single-page applications (SPA) may not need back-end infrastructure, enterprise web architectures do typically include some of these components.
And finally, lots of lines. These lines represent the various ways these components might interact with each other. Because we’re talking about the modern-day internet, all of these lines represent HTTPS request/response transactions: the back-and-forth conversation between clients and servers, all based on the HTTP protocol, all secured via TLS. Additionally, one of the defining characteristics of modern-day HTTP is the use of DNS names (A records and CNAMEs), which you see in the boxes that straddle the lines.
As we’ll see shortly, these DNS names are one of the keys to understanding exactly when various elements of Akamai functionality are applied. To foreshadow, keep an eye out for customer-owned domains (e.g., www.customer.com, accounts.customer.com) vs. shared Akamai domains (e.g., janrain.com, janraincapture.com). This will give us a major hint as to where Identity Cloud customers can apply their own configurations settings to Identity Cloud transactions.
Shared Edge Configurations for Identity Cloud
Now we’ll break things down in more detail. Let’s start with Identity Cloud itself.
The box on the right represents the entirety of Identity Cloud — the storage and application components that allow our customers to collect, store, and access end-user profile data. This is a cloud-hosted, redundant, and highly available set of services.
Notice, however, that there is only one line going to this box! This is because, as a part of the Akamai family, Identity Cloud itself takes advantage of the same robust acceleration and security Akamai edge features as many of our customers do…Ion and Kona. To put it simply:
All requests and responses to and from Identity Cloud pass through the Akamai edge.
This allows us to apply acceleration and security controls to all requests destined for the infrastructure of Identity Cloud. Note: These performance and security controls are shared, and are based on configuration settings managed and monitored by a team of engineers at Akamai. These controls are designed to increase the overall performance of the platform (using Ion) and to protect the platform against a broad swath of web application vulnerabilities (using Kona).
Referring to the point made above about DNS names, notice that the requests to the Akamai edge are all to janrain.com and janraincapture.com hostnames…this is how you know the Ion and Kona configurations are shared. It is important to understand that Identity Cloud customers do not have control over the settings applied at this point.
Next, we’ll look at how Akamai customers can control performance and security controls using their own instances of Ion, Kona, and even Bot Manager and Client Reputation.
Customer-Specific Edge Configurations for Identity Cloud
While Identity Cloud customers are unable to control the shared performance and security settings and controls that are applied to incoming Identity Cloud requests, those customers with existing Ion, Kona, Bot Manager, and/or Client Reputation entitlements are able to use those entitlements to control and protect certain Identity Cloud workflows.
Across the top of this diagram, we see the main places where requests to Identity Cloud originate. You’ll notice that each of the three boxes across the top can generate these requests.
1) Directly from the user agent
In this case, an application such as a single-page browser app or a mobile app communicates directly with Identity Cloud hostnames (e.g., *.janrain.com) without benefit of proxying through the customer’s own Akamai instance. As such, these requests will only benefit from the shared level of acceleration and protection discussed previously.
2) Proxied through the Akamai edge
As most Akamai customers know, Akamai edge features are enabled by way of a DNS CNAME, which allows a customer to still use hostnames associated with their own domains, yet direct that traffic to Akamai edge proxy servers. This is fundamentally how products like Ion, Kona, and Bot Manager are injected into the path of web traffic, and Identity Cloud requests are no different.
In this case, however, the customer’s various edge configurations are set up to use Identity Cloud as its origin, after the customer’s acceleration and security controls are applied.
Let’s look at a more concrete example.
An Akamai customer — who also uses Kona, Ion, Bot Manager, and Client Reputation — wishes to move its aging and homegrown customer identity functionality over to Identity Cloud. It wishes to use the modern OIDC standard and choose Identity Cloud’s Hosted Login model, which provides an authentication, registration, and profile management experience that is simple to use and robust — right out of the box. It creates a new hostname…
accounts.customer.com
…which, like its other properties, is CNAME’d to the Akamai edge…
accounts.customer.com. IN CNAME accounts.akamai.com.edgekey.net
Now, when it wants its application to invoke an authentication/registration experience, it’ll make a standard OIDC authorize call to this new hostname…
https://accounts.customer.com/{{customer_id}}/login/authorize?client_id=xxx
...which now arrives at an Akamai server. However, because this request was made using the accounts.customer.com hostname, our customer is able to apply its own configuration settings to this Identity Cloud traffic. What might it do?
- Enable Bot Manager Premier to provide credential abuse mitigation to the login flow, which cannot be done via the shared edge configuration
- Apply a custom network blocklist
- Apply the same client reputation and rate control rules shared across its other web properties
Once these controls are applied, the requests are then forwarded, or proxied, to the normal Identity Cloud hostname (e.g., v1.api.us.janrain.com), which has been configured as the proxy’s origin server.
Note that in terms of OIDC and OAuth flows, these are still front-channel requests — they’re simply proxied through the customer’s Akamai edge instance before being sent to the IdP.
Also, if you’re paying attention, you might notice that the above request to /authorize appears to be going through two different edge server instances: the customer’s instance, and then the shared instance. While this is true, in practical terms these will most likely either be the same physical Akamai edge server (i.e., a localhost request), or another server in the same region.
This means there will be very little impact from a performance perspective.
3) Back-channel or machine-to-machine requests generated from customer managed infrastructure
The final place in the architecture where we’ll see Identity Cloud requests originate is from the customer’s own infrastructure. These API requests are often, though not always, kicked off by a user-driven event, and involve a direct request from the back-end infrastructure to Identity Cloud.
An example of a user-driven back-channel request is the code-for-token exchange that occurs during the OAuth/OIDC authorization code grant flow. But this could also include other administrative RESTful API calls, such any profile updates that may be executed in response to, for instance, a webhook.
Notice that these requests are to Akamai identity domains, and thus are protected only by the shared Ion and Kona configurations, not customer-specific setups. That said, from a security perspective this is generally less worrying. In the case of the code-for-token exchange, for example, the back-channel requests are preceded by a front-channel request as we saw in #2 above, so customer protections can be applied upstream, earlier in the flow.
Other back-end RESTful API calls that are generated server side will simply not present the same level of risk as a user-agent generated front-channel request.
Summary
As described above, Identity Cloud is an integral part of the Akamai platform, and utilizes some of the same acceleration and security features that many of our web and media delivery customers benefit from. Identity Cloud comes out of the box with enhanced performance and security that comes from the shared Ion and Kona configurations that are in place.
In addition, Identity Cloud customers that have entitlements to Ion, Kona, Bot Manager, and Client Reputation can also layer these products in front of their own Identity Cloud request flow and customize these to their own specific needs.
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Michael Schmidt. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/__ljgGCvUtg/the-interaction-between-identity-cloud-and-akamai-edge-services.html