SSO, Hybrid Cloud Models

You want to use your on prem AD as the authenticator for AWS (or GCP) resources. Say you want to store desktop data in S3 buckets, but do not want to log in to the AWS console to do so.

You need to enable trust between your AWS account and your IdP (Identity Provider),  via a SAML configuration file. Once this trust is established, you can try accessing the S3 bucket directly.

What happens behind the scenes is that you first get redirected to the Identity Provider (your AD login). Once you login there, you receive a SAML token that is sent from your browser to the AWS console. AWS generates a temporary IAM credentials (called AWS STS), that let you access the S3 bucket for a limited timespan..

Identity Provider versus Service Provider

SAML versus OAuth

SAML on Google Cloud

Cloud Platform supports SAML 2.0-based SSO, which provides seamless SSO against Cloud Platform Console, web- and command-line-based SSH, and OAuth authorization prompts. Cloud Platform’s command-line interface tools, such as gcloud, gsutil, and bq, use SAML 2.0-based SSO for browser-based authentication as well.

SSO Overview

• You have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain.
• In fact, you want more: you want users who are already logged-in at domain X to be already logged-in at domain Y.
• The obvious solution to this problem is to share session information across different domains. However, browsers enforce a policy known as the same origin policy. This policy dictates that cookies (and other locally stored data) can only be accessed by its creator (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. All SSO solutions solve this problem: Sharing session information across different domains
• The essential concept is the same: there is a central domain, through which authentication is performed, and then the session is shared with other domains in some way.
• For instance, the central domain may generate a signed JSON Web Token (which may be encrypted using JSON Web Encryption). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.
• Whenever the user goes to a domain that requires authentication, he or she is redirected to the authentication domain. As the user is already logged-in at that domain, he or she can be immediately redirected to the original domain with the necessary authentication token.

SSO Enabling Technologies – OpenID Connect, SAML, OAuth

Depending on the type of auth middleman, the token could be SAML, OAuth or OpenID Connect

WS-Federation – SAML Token

OAuth –  JWT Token

OAuth does not deal with Authentication

• SAML deals with entire IAM – including Authentication.
• OpenID Connect runs on top of 2.0 – and provides secure, delegated access; Provides you with the token

Hybrid Model 1 – Sync’ed Identity from On-Prem to Cloud (different from Federated Identity)

User signs in to local LAN application using your local AD –> then hits a browser page for an O365 app –> O365 uses Azure AD – which already has the same user/pass – due to your backend scheduled SYNC!

1.    SSO is primary use Case

2.    Password Synchronization over the Internet

3.    DNS names need to be unique

Hybrid Model 2 – Federated Identity- True SSO – claims based authentication

1.    Instead of Identity, we have a token such that it is trusted

2.    Token comes out of on-premises datacenter. Central domain generates a SIGNED, JSON token. is trusted by cloud apps

3.    User goes to cloud based SaaS app, they are redirected back to local login page, ADFS authenticated locally-> sends token up to O365

4.    AD connect offers automated ADFS setup

5.    AWS has an AD Connector which is the same thing – a federator between on prem and cloud Identity !

Some popular SSO providers

Azure  AD – with AD Connector

• Identity as a service

Okta and Sailpoint

Summary