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 theres 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 Reputationwith their settings and their rulesto 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, well be breaking down this diagram in more detail.
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.
And finally, lots of lines. These lines represent the various ways these components might interact with each other. Because were 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 well 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., http://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.
Now well break things down in more detail. Lets 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 doIon 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 hostnamesthis 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, well 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.
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. Youll 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 customers 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 customers various edge configurations are set up to use Identity Cloud as its origin, after the customers acceleration and security controls are applied.
Lets 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 Clouds 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 CNAMEd 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, itll 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?
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 proxys origin server.
Note that in terms of OIDC and OAuth flows, these are still front-channel requests theyre simply proxied through the customers Akamai edge instance before being sent to the IdP.
Also, if youre paying attention, you might notice that the above request to /authorize appears to be going through two different edge server instances: the customers 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 well see Identity Cloud requests originate is from the customers 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.
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
See more here:
The Interaction Between Identity Cloud and Akamai Edge Services - Security Boulevard
Read More..