目次
- 目次
- はじめに
- この記事で分かること
- SSO連携の構成図
- 参考記事
- Google Workspace側でのSAMLアプリ設定(IdP側)
- OCI IAMでのIdP作成(SP側)
- Google Workspace側でのSAMLアプリ設定続き(IdP側)
- Google Workspace側でのSAMLアプリ有効化(IdP側)
- OCI IAMでのIdPポリシー作成(SP側)
- OCI IAMでのサインインポリシー作成(SP側)
- OCI IAMでのユーザ作成(SP側)
- Google Workspace側でのSAMLアプリ設定
- Google Workspace側での接続テスト
- 検証で発生したトラブルシューティングやおすすめの対策
- 今後の展開予定
- まとめ
- おわりに
はじめに
こんにちは、エーピーコミュニケーションズの松尾です。
クラウド活用を進めていくとID・認証管理の一元化は避けて通れません。
ログイン先サイトが増えるにつれて、サイトごとのID管理ではスケーラビリティに限界が出てきます。
そこで登場するのが SSO(シングルサインオン)です。
本記事では、Google Workspace(旧G Suite)をIdP(Identity Provider)、OCI IAMをSP(Service Provider)とし、SSOで認証してログインするまでを紹介します。
この記事で分かること
- OCI IAMとGoogle WorkspaceでのSSOログイン実装手順(※認証まで)
- SSOログインのフローを図で理解
SSO連携の構成図
全体構成とフローはこのようなイメージです。
①:Google Workspaceへログインしたユーザが、
②:ランチャーからOCI IAM用アイコンをクリック、
③④:IdPからSPへ認証要求が実行され、
⑤:認証結果が返る
⑤が正常であれば、OCI IAMのコンソール画面へリダイレクトされる形となります。
参考記事
参考としているのは次の2つの記事です。
Federating OCI Identity Domains with Google Workspace
Manage Access to Oracle Cloud with Google Cloud IAM
Google Workspace側でのSAMLアプリ設定(IdP側)
Google Workspace 管理コンソールへ管理権限を持つアカウントでログイン。
アプリ > ウェブアプリとモバイルアプリ をクリック。
カスタムSAMLアプリの追加 をクリック。
アプリ名とアイコンをアップロード。
オプション1のメタデータをダウンロード。
ACSのURL、エンティティIDを求められます。一旦ここでストップし、OCI側へ移ります。
OCI IAMでのIdP作成(SP側)
OCI Consoleへログインし、SSOログインさせたいアイデンティティドメインのセキュリティ > アイデンティティ・プロバイダ をクリック。
SAML IdPの追加 からIdPを作成していきます。
名前を入れて、
Google側でダウンロードしたメタデータをアップロード、
リクエストされた名前IDフォーマット に電子メールアドレスを選択、IdPを作成します。
作成されたIdPのメタデータタブを開くと、プロバイダID(エンティティID)とアサーション・コンシューマ・サービスURL(ACS URL)が確認できます。この値をGoogle側へ設定していきます。
IdPはアクティブ化しておきます。
Google Workspace側でのSAMLアプリ設定続き(IdP側)
ACSのURLとエンティティIDを設定、
マッピングは参考ブログと同様に設定していき、アプリを作成します。
Google Workspace側でのSAMLアプリ有効化(IdP側)
作成したSAMLアプリのユーザーアクセスをオンに設定します。
OCI IAMでのIdPポリシー作成(SP側)
サインインポリシーを設定していきます。
IdPポリシーからIdPルールの追加をクリック、
アイデンティティ・プロバイダの割当てへ、IdP名を選択し、ルールを作成します。これにより指定のIdPからのログインが許可される形です。
OCI IAMでのサインインポリシー作成(SP側)
サインオン・ポリシーから、OCI Console用のセキュリティポリシーをクリックします。
ここではデフォルトで全ユーザに有効になっているMFAを除外させていきます。MFAを効かせたままにしたい場合は特に変更する必要はありません。
サインオン・ルールの追加から、
条件にIdPを指定し、
アクションでは「追加ファクタの要求」(MFA)のチェックを外して作成します。
優先度の編集から、デフォルトのルール(MFA for ***)よりも作成したルールが上位(若番)にくるよう設定します。このルールは一致すると以降のルールはチェックされないためです。
OCI IAMでのユーザ作成(SP側)
OCI IAM内へ、ログインしたいユーザを手動で作成しておきます。
ユーザIDはログインユーザのメールアドレスと一致している必要があります。
Google Workspace側でのSAMLアプリ設定
SAMLアプリ設定時に失念していたのですが、「開始URL」にはOCI ConsoleのURLを設定していきます。
デフォルトではユーザのコンソールアプリ画面にリダイレクトされてしまうのですが、直接OCI Console
へログインさせたいためです。設定は無くてもログインすることに問題はありません。
Google Workspace側での接続テスト
接続テストを行ってみます。
OCI ConsoleのCloud Account Name選択画面が表示され、
ログイン先のアイデンティティドメインを選択して次へ、
OCI Consoleトップ画面が表示されました!
検証で発生したトラブルシューティングやおすすめの対策
SPのメタデータではなくOCIコンソール上からACS IDとエンティティIDを取得
SPでエクスポートできるメタデータファイルにもACS IDとエンティティIDが含まれています。しかしメタデータ内のACS IDとエンティティIDは特定しにくいうえ、OCIコンソール上で確認できるACS ID、エンティティIDとは差分がありました。(試したところOCIコンソール上のパラメータが正解)
ACS IDとエンティティIDはOCIコンソール上から取得することをおすすめします。
IdP側で認証成立後のリダイレクトURL設定が必要
デフォルトではSAML認証が成立したあとのOCI側接続URLはアプリケーションのURLとなっています。
OCIコンソールへ直接リダイレクトするにはIdP側でURLの指定が必要な点に注意です。
IdPのSAMLアプリは「全ユーザ」に「オン」か「オフ」しかない
SAMLアプリを有効化する際、まずは1ユーザずつ、のような操作がそのままでは出来ません。特定のグループに所属させてグループ単位で「オン」にするなどの工夫が必要です。
SPでは「IdPポリシー」と「サインインポリシー」の設定が必要
「IdPポリシー」では、”作成したIdPからのログインを許可”させ、
「サインインポリシー」では、”MFA除外や他に認証ポリシーを設定”させていきます。
サインインポリシー周りの設定は間違えると全ユーザがログインできなくなる可能性があるため、設定はテスト用のアイデンティティドメインで行うことを強くおすすめします。
今後の展開予定
SSOログインはもう少し細分化すると、
①:SAMLプロトコルによる認証
②:SCIMプロトコルによるユーザ情報の同期や作成等
に分かれます。
本ブログでは①の手順のみを実施しました。
現実の運用では②とセットで実装することが基本になると思います。
今後は②も実装し、①で認証されたユーザが自動的にOCI IAM側へもプロビジョニングされる形を目指しています!
まとめ
全体のポイントです。SAML認証までの大項目としてはこちら。
・IdPとSPでメタデータを交換
・IdP側でSAMLアプリを設定
・SP側でSAML認証されたユーザへのサインインポリシーを設定
SP側のIdPポリシーやサインインポリシーの設定がやや分かりにくかったのですが、理解すると認証プロバイダごとに柔軟な認証ポリシーが設定できることが見えてきます。
認証基盤側(IdP側)はテスト用に無償枠があるID認証基盤を使って検証してみるのも良いと思います!
おわりに
私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です! ご興味持っていただけましたらぜひお声がけください。