Ensuring that all of your hybrid cloud platforms are equally and adequately protected can be challenging. Here's a close look at two important controls and best practices for implementation.
Today, many organizations dealing with hybrid cloud-based IT infrastructures are still struggling with getting the right level of security controls in place and, more importantly, ensuring that these controls protect all hybrid cloud platforms in an equal and adequate fashion. Having different levels of protection in place – for example, for VMs that run on-premises in your datacentre and for VMs hosted on a cloud provider’s platform – can allow malware or hackers to sneak in, exploit the weakest link, and affect and infect all islands of your hybrid cloud. Aligning controls between hybrid cloud islands is not a straightforward task – under the hood, hybrid cloud platforms have (or don’t have) their specific ways of securing their assets and the customer data, services and apps they support.
In this series of blog articles on hybrid cloud security fundamentals, I want to highlight what you should consider when planning and designing the security controls for your hybrid cloud. For each of the controls covered, I will define what exact security coverage they provide; whether there are important standards you need to consider; and how and to what extent the big cloud players (Azure, AWS, GCP) support them. I will also give some implementation best practices that are based on HPE experience, and show how the different controls resonate in the context of our own HPE Greenlake Cloud Services. In this first article I will focus on identity federation and single sign-on (SSO).
Getting to know the standards
Federated identity is the ability to link and use a user’s digital identity across different security domains, for example between your on-premises infrastructure and the Microsoft Azure platform. When two applications are federated, a user can use one application by authenticating with their identity to the other, without needing to use separate usernames/passwords for both. Federation is enabled through automated exchanges between Identity Providers (IDPs) and Resource Providers (RDPs). These exchanges are standardized in different federation protocols that I will briefly cover below.
The main benefit of federation is Single Sign-On (SSO), but also providing a scalable way to access shared resources across different environments (such as hybrid cloud islands) and supporting the need to store credentials only in a single hardened location.
Today there are two leading federation protocol standards: SAML and OIDC.
SAML stands for Security Assertion Markup Language. It is the oldest federation standard and was initially developed by an industry consortium called Oasis. The latest SAML version is v2. SAML is well-established in enterprises. SAML defines protocols for the automated exchange of identity tokens (ID tokens) and access tokens. ID tokens are analogous to real-life ID cards: they contain a set of claims about the user, like name and email. Access tokens contain access control information such as group memberships and user privileges. You surely have experienced SAML when it enables you to log on to your enterprise ID provider and then access additional applications, such as Salesforce, Workday, and Microsoft 365, without having to re-enter your credentials.
OIDC stands for OpenID Connect and extends the authorization capabilities of a protocol called OAuth by supporting authentication constructs such as an ID token. OAuth is the main standard for API access delegation – also known as delegated access – and access control in the consumer-focused cloud provider space. It is used for transparently exchanging consumer attributes between, for example, Facebook and LinkedIn, without requiring the user to re-enter all his personal details. You surely have experienced the use of OAuth and OIDC when you’re about to authenticate to a website and the site asks you to reuse your Facebook, LinkedIn, Twitter or other set of credentials.
OIDC and OAuth are younger than SAML. OAuth development was started by public cloud leaders including Google and Twitter; OIDC development is driven by the OpenID Foundation consortium. SAML uses an XML token format, OAuth and OIDC use the JSON Web Token format (JWT). Table 1 compares and summarizes the features of SAML, OAuth and OIDC.
How the big cloud providers support federation
The three major cloud providers can support both SAML and OAuth/OIDC based federation – as summarized in Table 2. To federate with the identities defined in an organization’s on-premise Active Directory you can set up SAML-based federation, whereby the on-premise AD is the ID provider and the cloud platform provider (Azure, AWS or GCP) is the resource provider. All three can also federate with the identities that consumers already have in cloud services, such as Facebook and LinkedIn, using OAuth/OIDC-based federation.
Federation requires local accounts on the resource-provider side to enable access control management – which in Azure and AWS as well as GCP can be done using a role-based access control (RBAC) system. To create these local “shadow” accounts you can use a directory synchronization engine that copies the accounts and/or groups in your on-premise AD to the cloud provider’s identity database (Azure AAD, AWS IAM or Google Identity).
Compared to AWS and GCP, Azure has a set of extra options for enabling SSO; it supports password-hash synchronization between AD and AAD, and it also supports a pass-through authentication option. In the latter case Azure always calls back to the on-premise AD when authenticating an Azure security principal. It’s also worthwhile mentioning that all three cloud providers allow you to use a managed Active Directory option – ADaas – in the cloud.
In summary, for SSO in an enterprise hybrid cloud, SAML is the most obvious option – also if you need to call on compute, storage or application resources hosted by a cloud provider. If your hybrid clouds need to integrate with identities in the consumer space and big ID providers such as LinkedIn, Facebook, or Twitter, then OAuth/OIDC is the best choice.
One important element that’s often forgotten when planning for federation is that both SAML and OAuth/OIDC can only be leveraged for apps that can be accessed using a web interface (HTTP or HTTPs-based access). There are some workarounds to enable applications that don’t have a web front-end to leverage SAML- or OIDC-based SSO by calling on an HTTP proxy or gateway. A good example is the Apache Guacamole gateway that can proxy VNC, SSH, and RDP applications – all very popular tools for remote management.
Also don’t forget that you need to provision shadow accounts in the security database of the resource provider to enable proper resource permissioning. If you don’t want to do all this work manually, you will need a provisioning solution that creates one-to-one or many-to-one mappings between the accounts hosted by the ID provider and the accounts used by the resource provider. Here is an important security hint: also consider the inverse process – de-provisioning – to remove accounts and permissions that are not in use or needed anymore!
Finally, it is also critical that you get all supporting IT infrastructure elements for federation right before you start implementing the federation solution. Especially important are well-functioning naming (DNS) and certificate (X.509-based PKI) services.
How HPE Pointnext Services helps you enable federation and SSO for your hybrid cloud
We can help you on several different fronts.
Advisory and professional services experts of HPE Pointnext Services can help you assess your federation needs, and architect, design and implement a tailored federation solution. HP Pointnext Services has many years of experience in building and implementing complex identity management solutions for a wide range of customers across verticals and across the world. Pointnext also partners with leading security solution vendors such as Nexus, which provides a very complete and leading edge federation gateway solution as part of its Smart ID Digital Access offering (formerly known as Hybrid Access Gateway). We also partner with more focused federation solution vendors such as Okta and PingID.
If you are an HPE GreenLake customer you can integrate your on-premise identity management system with HPE Greenlake Central and provide an SSO experience by federating with HPE Greenlake Central using SAML.
Finally, I want to point out that our HPE Communications & Media Solutions (CMS) division offers a nice federation solution for digital service providers (such as telcos, carriers, operators, mobile device vendors). This solution is called Secure Identity Broker (SIB) and is part of the CMS HPE Digital Identity Platform – it supports OAuth/OIDC-based federation.
Learn more about IT security risk management services from HPE.
Learn more about HPE GreenLake cloud services.
Jan De Clercq
Hewlett Packard Enterprise
twitter.com/HPE_Pointnext
linkedin.com/showcase/hpe-pointnext-services/
hpe.com/pointnext
Jan_De_Clercq
Security Chief Technologist, WW HPE Pointnext Services Security Practice
