Pass-Through Authentication

Summary

Sundeck is completely transparent to client applications, as it exposes exactly the same interface as Snowflake. In addition, authentication and authorization are handled by Snowflake or a third-party IdP in exactly the same way as they are today. Authentication and access tokens are simply passed through the Sundeck broker, without inspection, logging, or modification.

Sundeck supports all authentication methods offered by Snowflake, including username and password, keypair, and SSO by Snowflake and third-party identity providers such as Okta. In the case of a third-party IdP, all handling of credentials is done between the Snowflake client and the IdP, and the resulting SAML assertion from the IdP is simply forwarded by Sundeck to Snowflake during client authentication. Sundeck is never in the path of users entering credentials.

Call Flows: Snowflake SSO Authentication with Okta

Externalbrowser Authentication

In cases where an end-user is in the loop, the common authentication method used with Snowflake clients is ’externalbrowser’. In this method, the client authentication request is sent to Snowflake, which returns an Okta URL. The client receives this URL and then opens this URL (Okta login form) in a browser on the user’s local machine, where the user can type in their credentials.

Once successfully authenticated, Okta returns a SAML assertion to the Snowflake client, which then sends this to Snowflake (through the Sundeck private broker) to complete the authentication process:

When a valid SAML assertion is presented, Snowflake returns a short-lived (1 hour) Access Token, which the Client will use to establish a session and submit queries. This token flows through Sundeck on its way back to the client, however this token is not persisted, logged, or held in memory.

Okta Direct Authentication

Applications without a user in the loop (such as automated processes) can use an alternate form of Okta authentication, known as “direct authentication”. In this mode, the client directly calls an Okta endpoint URI with credentials; again these are handled exclusively between the client and Okta. If authentication is successful, Okta will return a SAML assertion, which the client can send to Snowflake through Sundeck (exactly as in the previous flow):

Notes on Sundeck’s handling of SAML Assertions :

Sundeck forwards SAML assertions the client receives from Okta authentication to Snowflake. These SAML assertions are never persisted, logged, or modified by Sundeck.
When a valid SAML assertion is presented to Snowflake, Snowflake will generate a short-lived Snowflake Access Token, which is returned to the client (forwarded through the Sundeck private broker). The client holds this Access Token and supplies it when querying Snowflake.

Post-Authentication Query Flow

Once a client has authenticated with Snowflake and has obtained a Snowflake Access Token, it may then submit queries to Snowflake. Sundeck receives client queries, looks up user session state from an in-memory cache (using a hash of the Access Token as the key, not the token itself), and then applies a series of predefined rules to the query which may modify the query or properties of the session.

Once the rules have been applied, the query (and any changes to session state) are forwarded to Snowflake, along with the Snowflake Access Token.

Notes on Sundeck’s handling of Snowflake Access Tokens:

Sundeck does not generate its own tokens; all client Access Tokens are generated and signed/encrypted by Snowflake. When clients access Snowflake to submit queries, they pass the Snowflake Access Token they received during the authentication process (described above). Sundeck does not store, log, modify, or persist Snowflake Access Tokens in memory.
When clients submit Snowflake requests (which include a valid Snowflake Access Token), Sundeck computes a hash of this token and uses the hash to retrieve session state. The tokens themselves are never retained in memory.