Introduction

If you've had SAML SSO enabled on your Console, you may be curious why the first time a user tries to log in to the console, they get directed to your SSO provider rather than being logged into the Canary Console.

This page describes why, and what steps you can take if you don't want this default.

Keeping consoles and customers separate

As a rule, we aim to hide which customer a particular console belongs to. In other words, if a random Internet browser hits your console, it shouldn't be obvious who the console belongs to.

(This is one of the reasons why your console has a random prefix in its name.)

With the introduction of SAML, a trivial route to tie consoles to customers becomes possible.

SAML SP-initiated authentication

If SAML is enabled on your console and a user browses to the Console, then in a typical SAML SP-initiated authentication flow we'd send the user to your Identity Provider (Auth, Okta, OneLogin, etc).

The concern here is that the unique URLs defined at these Identity Providers often include the Customer Name!

For example, an Okta URL will look something like this:

https://dev-139568.oktapreview.com/app/canarydev139568_dashboardtesting00004443_1/.../sso/saml

And OneLogin's URLs look something like this:

https://canary-tools.onelogin.com/trust/saml2/http-post/sso/182340

It may be possible to identify the customer by observing the redirected URL.

We want to avoid this!

Our approach

We tackle this with two prongs:

1. Users whose browsers have never logged into the Canary Console are directed to the base Identity Provider (okta.com, auth0.com, onelogin.com, etc). There they login to the Identity Provider, and click on the Canary app. This logs them into the Canary Console, and sets a long-lived cookie in their browser so we can recognise them when they return. In effect we've converted their SP-initiated authentication flow into an IdP-initiated flow, but only for the first login from that browser.
2. Users whose browsers have previously logged into the Canary Console will see the natural SP-initiated flow.

With this two-pronged approach, the customer's SAML URL (and hence the name) is not revealed unless the user has previously successfully logged in. The downside is that on a user's first login in a particular browser (or after cookies are cleared), they will need to click on the Canary app in the SSO dashboard.

Skip the tricks, give me SP-initiated auth

If this default flow doesn't suit you for whatever reason, we can change this for you, just get in touch with support.