Tags:
What is IDaaS and Why Should I Use It?
Identity-as-a-Service (IDaaS) is a 3rd party offering of identity and access management (IAM) solutions, bundling many of the common IAM capabilities, typically designed to provide functionality such as:
- Account provisioning and deprovisioning, leveraging standard protocols like System for Cross-Domain Identity Management (SCIM) or proprietary connectors
- Integration with enterprise identity stores, such as Active Directory, OpenLDAP, or other authentication sources of truth
- Facilitate compliance activities
- Support for Multi-factor Authentication (MFA) and adaptive authentication
- Support for Single Sign-on (SSO) with standards like Security Assertion Markup Language (SAML) and OpenID Connect (OIDC); simplifying the user experience for accessing cloud applications via federated partnerships
Why IDaaS, well simply stated - building an IAM infrastructure requires a significant investment in development & infrastructure, so many organizations are choosing to buy versus build their IAM solution, avoiding much of the administrative overhead with an on-premise solution. Additionally, with the movement towards remote workforce and the proliferation of SaaS solutions, organizations can provide more robust access management to meet their business objectives.
In this article, the focus will be on using SAML with IDaaS, as it happens to be one of the most common single sign-on (SSO) methods for authentication and how this can be accomplished with the 3 big cloud providers (AWS, GCP, and Azure).
Foundational Knowledge
First, some important terms, definitions, and context to set the stage for this article:
- Metadata (in the context of SAML)
- “defines how a SAML entity can describe its configuration data (e.g., service endpoint URLs, key material for verifying signatures) in a standard way for consumption by partner entities. It has an associated schema.”2
- Identity Provider (IdP)
- “A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles.”1
- Service Provider (SP)
- “A role donned by a system entity where the system entity provides services to principals or other system entities.”1
- Attribute
- “A distinct characteristic of an object (in SAML, of a subject). An object’s attributes are said to describe it.”1
- Assertion
- “A piece of data produced by a SAML authority regarding either an act of authentication performed on a subject, attribute information about the subject, or authorization data applying to the subject with respect to a specified resource.”1
- Application Programming Interface (API) – related to creating a federation partner in IDaaS
- “the acronym “API” or its expanded version “Application Programming Interface,” it is almost always in reference to our modern approach, in that we use HTTP to provide access to machine readable data in a JSON or XML format, often simply referred to as “web APIs.”4
- System for Cross-Domain Identity Management (SCIM)
- “The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service.”3
With the general understanding of the context, important terms, and the associated definitions, let’s get practical! Beyond the formality, let’s now look at how to implement SAML based federation with the 3 major cloud providers, including:
- Amazon Web Services (AWS)
- Google Cloud Platform (GCP) & Google Workspace
- Azure & MS365
The following videos have been generated to show the overall practical steps required to setup SAML based federation for each of the cloud providers.These videos complement the content provided in the SEC488: Cloud Security Essentials course, related to day 1 around the Identity and Access Management (IAM) material. Additionally, I’d like to take a moment to express my gratitude to the University of Colorado Anschutz Medical Campus for allowing me to leverage their non-production environments for demonstrating this capability.
IDaaS Federated Partnership with AWS
IDaaS Federated Partnership with GCP & Google Workspace
IDaaS Federated Partnership with Azure & MS365
References:
[1] https://www.oasis-open.org/committees/download.php/21111/saml-glossary-2.0-os.html
[2] http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
[3] https://www.rfc-editor.org/rfc/rfc7644
[4] https://blog.postman.com/intro-to-apis-history-of-apis/
[5] https://www.oracle.com/technical-resources/articles/middleware/oracle-identity-cloud-service.html
[6] https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/index.html
[7] https://docs.oracle.com/en/cloud/paas/identity-cloud/uaids/access-saml-metadata.html
[8] https://www.oracle.com/technical-resources/articles/middleware/oracle-identity-cloud-service.html
[9] https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html
[11] https://cloud.google.com/architecture/identity/best-practices-for-federating
About the Author
Chris Edmundson has been employed in the information technology arena for over 25 years, working in a wide variety of roles, primarily in the public sector related to administration of K-12 public schools and at higher education institutions. He currently manages the Security Operations for the Office of Information Technology at the University of Colorado Denver | Anschutz Medical Campus. Chris is an Associate Instructor teachingSEC488: Cloud Security Essentials. Read Chris's full profile.