こんにちは。バクラク事業部機械学習・データ部データグループの@civitaspoです。僕は定期的にエディタを変えるのですが、最近CursorからNeovimに移行しました。LazyVimを使ってセットアップするとシュッと使いやすい環境ができあがったので、Neovimのコミュニティ・エコシステムは素晴らしいなと感動してしまいました。Javaも普通にNeovimで書けちゃう。

さて、弊社ではSnowflake導入に向けた大規模な検証を進めています。これまで弊社ではデータウェアハウスソリューションとしてGoogle CloudのBigQueryを利用してきました。もちろんBigQueryも素晴らしいソリューションの一つですが、弊社のサービス提供環境がAWSであるという都合上、Snowflakeとは親和性が高く、またSnowflakeはBigQueryとは異なる素晴らしい機能を持ち合わせているため、導入の価値があると判断しました。導入に至った経緯や導入プロジェクトの詳細については、プロジェクトが完了に近づいたら、別途ブログに書こうと思います。

今回はSnowflake導入検証の一環で、弊社がIdentity Providerとして利用しているMicrosoft Entra ID（旧称 Azure Active Directory）によるSingle Sign-On、及びSCIMプロビジョニング*1の有効化を行ったので、その手順をブログに書こうと思います。非常に公式ドキュメントが豊富なので、本ブログから得られる追加情報は多くないかもしれませんが、同様の作業を行う方々の参考になればと思っています。

なお、本記事ではMicrosoft Entra IDに関する基礎的な説明は行いません。Microsoft Entra IDはクラウドベースのアイデンティティ管理およびアクセス管理サービスです。弊社では従業員がアクセスするツールは原則Microsoft Entra IDによる認証を必要としています。

Single Sign-Onの有効化

まずはSingle Sign-On（以下、SSO）の有効化から進めます。SSOの設定に関しては、MicrosoftとSnowflakeの両方からドキュメントが提供されています。このドキュメントに沿って作業を進めます。

learn.microsoft.com docs.snowflake.com

Microsoft Entra ID側での作業

まずは、Microsoft Entra IDでEnterprise applicationを作成します。UIから「+ New application」をクリックします。

ギャラリーの検索窓に「Snowflake」と入力すると「Snowflake for Microsoft Entra ID」というアプリケーションがあらわれるのでクリックします。（「Snow Atlas SSO」はロゴが似ていますが、完全に別アプリケーションなので間違えないように注意してください。）

名前を入力して作成します。複数のSnowflakeアカウントを運用する想定であれば、SnowflakeアカウントごとにEnterprise applicationの設定が必要になるため、対応するSnowflakeアカウントが分かる名称にしておくと良いでしょう。今回はこのまま作業を進めます。

Enterprise applicationが完成したらサイドバーの「Single sign-on」メニューから「SAML」を選択します。

Basic SAML Configurationを埋めていきます。ドキュメント通りに埋めていくだけです。

設定名	設定値
Identifier	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com`
Reply URL	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com/fed/login`
Sign on URL	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com`
Relay State	設定しない
Logout Url	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com/fed/logout`

<SNOWFLAKE-ACCOUNT-IDENTIFIER> は各Snowflakeアカウントに割り振られた一意な識別子です。通常、サインアップ時に機械的に生成された識別子が組織に対して割り振られます。<SNOWFLAKE-ACCOUNT-IDENTIFIER>はこの組織識別子とアカウント名をハイフンで繋いだものになります。

たとえば、組織識別子がlayerxだとして、アカウント名がsandboxであれば、<SNOWFLAKE-ACCOUNT-IDENTIFIER>はlayerx-sandboxとなり、URLはhttps://layerx-sandbox.snowflakecomputing.comとなります*2。以下の画像の例では、組織識別子がobbzpgs、アカウント名がlayerxとなっています。

なお、この組織識別子はサポートに問い合わせることで変更することが可能です。サインアップ時に割り当てられた組織識別子は意味を持たないランダム文字列なので変更することをおすすめします。また、組織識別子を変更する場合、当然ながら<SNOWFLAKE-ACCOUNT-IDENTIFIER>も変更されるため、SAML設定もやり直しになります。先に組織識別子を変更してからSAML設定を行うほうが手戻りは少なくなるでしょう。

docs.snowflake.com

その後、「Attributes & Claims」はデフォルト設定のまま変更せず、「SAML Certificates」項目に進みます。

このSAMLの証明書は有効期限があることに留意しておきましょう。デフォルトで3年です。この有効期限を切らしてしまった場合、最悪Snowflakeへのログインができなくなる可能性があります。複数人のカレンダーに有効期限を登録しておくことをおすすめします。

さて、ここでは「Certificate(Base64)」をダウンロードしておきます。あとでSnowflake側の作業で使用します。

最後に、「Set up （Enterprise application名）」項目の情報を控えておきます。この情報もSnowflake側の作業で使用します。最後の「Test」はSnowflake側の設定完了後に押します。

便宜上、Snowflake側の設定時に使用する情報に番号をふっておきます。

①「Certificate (Base64)」でダウンロードしたファイル
②「Set up （Enterprise application名）」項目で取得した「Login URL」
③「Set up （Enterprise application名）」項目で取得した「Microsoft Entra Identifier」

では、Snowflake側の作業に移りましょう。

Snowflake側の設定

こちらもドキュメントどおりに作業します。SnowsightのSQL Worksheetを開き、Security Integrationを作成するためのSQLを発行します。

Snowflake Security Integration Property	設定値
`SAML2_ISSUER`	Microsoft Entra ID側の作業で取得した③の情報
`SAML2_SSO_URL`	Microsoft Entra ID側の作業で取得した②の情報
`SAML2_PROVIDER`	CUSTOM
`SAML2_X509_CERT`	Microsoft Entra ID側の作業で取得した③の情報
`SAML2_SP_INITIATED_LOGIN_PAGE_LABEL`	任意の文字列弊社では`MICROSOFT_ENTRA_ID_SAML2`としました。
`SAML2_ENABLE_SP_INITIATED`	true
`SAML2_SNOWFLAKE_ISSUER_URL`	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com`
`SAML2_SNOWFLAKE_ACS_URL`	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com/fed/login`

ここで注意点ですが、Microsoft Entra ID側の作業で取得した③の情報には-----BEGIN CERTIFICATE-----、-----END CERTIFICATE-----という文字列が含まれています。しかし、SAML2_X509_CERTの値として格納するときは、このヘッダーとフッターを取り除く必要があります。そのため、以下のコマンドで内容を取得しましょう。

cat /path/to/Snowflake\ for\ Microsoft\ Entra\ ID.cer | grep -v '^---' | pbcopy

また、SAML2_X509_CERTに値を設定する時は改行文字列を取り除いてはいけないことにも注意しましょう。SQLを記述するとき、以下のようにシングルクオートが改行されて行頭にあるのが正しい状態です。

SAML2_X509_CERT = 'MIIC8DCCAdigAwIBAgIQW+IH4P61MIdFUBZ6Yn0qiTANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQD
EylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0yNDA0MTAxMDQy
.....<snip>....
R0mLqLFL4NNgNbaL/UUrb6shc0S3s6I2Mp1S9Y49+MA/Fpbf02zF1nKqunpBySyrVUizY3mgmQVg
Vwa4QH453wMGLv7grBFq
'

このSQLを実行するとインテグレーションが作成されます。

Microsoft Entra ID側に戻ってテストを実行する

テスト実行前に少しだけ準備が必要です。

テストを実行するユーザーの Microsoft Entra ID 上における User Principal Name を使ってSnowflake上にユーザーを作成する
Enterprise applicationの「Users and groups」で、テストを実行するユーザーを所属させておく

この2つの作業を終了させたらテストを実行します。

成功すると以下のような表示になります。

SCIMプロビジョニングの有効化

次にSCIMプロビジョニングの有効化作業を進めます。SCIMプロビジョニングに関しても、MicrosoftとSnowflakeの両方からドキュメントが提供されています。このドキュメントに沿って作業を進めます。

learn.microsoft.com

docs.snowflake.com

Snowflake側での作業

SnowsightのSQL Worksheetを開き、Security Integrationを作成するためのSQLを発行します。最後のSQLで払い出されたアクセストークンはMicrosoft Entra ID側の作業で使用するので控えておいてください。

use role accountadmin;
create role if not exists microsoft_entra_id_scim;
grant create user on account to role microsoft_entra_id_scim;
grant create role on account to role microsoft_entra_id_scim;
grant role microsoft_entra_id_scim to role accountadmin;
create or replace security integration microsoft_entra_id_scim
    type = scim
    scim_client = 'azure'
    run_as_role = 'MICROSOFT_ENTRA_ID_SCIM';
select system$generate_scim_access_token('MICROSOFT_ENTRA_ID_SCIM');

Microsoft Entra ID側での作業

SSO設定で使用したEnterprise applicationを開きます。「Provisioning」→「Provisioning」に遷移し、以下の情報を入力します。

設定名	設定値
Provisioning Mode	Automatic
Tenant URL	`https://<SNOWFLAKE-ACCOUNT-IDENTIFIER>.snowflakecomputing.com/scim/v2`
Secret Token	先のSQLで取得したアクセストークン

この状態で「Save」をクリックします。すると、「Mapping」項目と「Settings」項目の変更が可能になります。

「Mapping」項目は、Microsoft Entra ID側のAttributeとSnowflake側のユーザープロパティの対応を定義することができます。

ドキュメント上は以下のプロパティが追加で設定可能と書かれています。

しかし、この設定はやや特殊な操作を必要とします。以下のCommunity Knowledgeに書かれている通り、Microsoft Entra IDの旧UIに対してアクセスを行い、Snowflake側のAttributeを追加してあげる必要があります。

community.snowflake.com

この操作はMicrosoft Entra IDの新UIでは更に難易度が高くなります。まず、「Mapping」項目の「Provision Microsoft Entra ID Users」からAttribute Mappingの設定画面に遷移します。次に、「Show advanced options」にチェックを入れ、「Review your schema here」をクリックします。するとSCIMプロビジョニングで使用されるSchemaの編集画面に入れるので、Target Object であるurn:ietf:params:scim:schemas:extension:enterprise:2.0:UserのSchemaに所望のAttributeを定義することで実現することができます。

少し脱線しましたが、最後に「Provisioning Status」を「On」にすることで設定が完了します。

Microsoft Entra IDのSCIMプロビジョニングは40分毎に実行されます。SCIMプロビジョニングが実行されるとSnowflake側にユーザーが連携されます。アカウントの作成者は先ほどSecurity Integration作成時に指定したロールになっているのがわかります。

これでSSOの有効化とSCIMプロビジョニングの有効化の両方が完了しました。

設定が完了したので、ユーザーが認証で迷わないような設定を行っていきます。Snowflakeには「Identifier-first login」という機能があります。これはログイン画面において、まずはユーザー名を入力してもらい、そのユーザーにとって有効な認証方法のみを表示してくれる機能です。

docs.snowflake.com

この設定を行うことで設定前にはパスワードも入力できるログイン画面が表示されていたのが、設定後はユーザー名のみが表示されるようになり、利用者は迷わなくなります。

この設定はドキュメントに書いてあるとおり以下のSQLを実行するのみで完了します。

USE ROLE ACCOUNTADMIN;
ALTER ACCOUNT SET ENABLE_IDENTIFIER_FIRST_LOGIN = true;

もちろんパスワード認証のみが設定されているユーザー（たとえば緊急アクセス用など）はユーザー名を入力したあと、パスワード入力画面に遷移します。

おわりに

本記事ではSnowflakeにおけるMicrosoft Entra IDを使用したSingle sign-on、およびSCIMプロビジョニングの有効化について説明しました。ドキュメントには記載されていない情報もいくつか付加情報として載せられたと思っています。本記事が同様の作業を行う方々の助けになることを願っています。

Snowflakeの話以外にもまだまだお話したいことはたくさんあるので、面白そうだなと思って頂けた方は僕と話しましょう〜！以下のリンクでもTwitterでもお返事お待ちしています！

jobs.layerx.co.jp

*1:SCIMはSystem for Cross-domain Identity Managementの略称ですが、正式名称よりも略称のほうが伝わると考え、この記事では一貫してSCIMプロビジョニングと表記しています。

*2:アカウント名にはハイフンを使用できません。代わりアンダースコアが使用できます。アンダースコアを使用した場合、ドメインにアンダースコアが含まれることになり、一部のサービスでは接続時にエラーを返すことがあります。この問題に対してSnowflakeはアンダースコアをハイフンに置き換えたドメインも同一のものとして扱うようになっています。Account identifiers | Snowflake Documentation, Solution: Error when trying to connect to Tableau Desktop using OAuth SSO flow