2年ほど前に会社ブログで同じようなネタの記事を書いたのですが、仕事で再度その時の知識を活かすことになりそうです。ちょうどいい機会なので基本知識等補足説明を加えつつ、内容をアップデートします。以前の記事はこちらです。
アップデートするにあたり、私の上司（というより教官？）に多大なご支援をいただきました。いつも本当にありがとうございます。この場を借りて御礼を申し上げます。
前提
- AWSアカウントとOktaアカウントは用意している
- AWS IAM Identity Center（以下IIC）は有効化済で、AWS Organizationsの管理アカウントか委任管理アカウントにある組織インスタンスを利用できる
- IICとOktaが何のためのサービスか理解している
- 認証フローはIdP-initiatedである（ユーザー→IdP→SP）
- OktaからIICにSCIMを設定可能な状態である（有料のOkta製品を利用している場合、Oktaのライセンスがライフサイクル管理やアウトバウンドプロビジョニングを可能にする機能をサポートしているか確認が必要です）
基本知識
Single Sign-On (SSO)
一度の認証で複数サービスへログインできる仕組みです。IICや、IdP（Okta/Entra IDなど）と各SaaSの連携で実現します。
Identity Provider(IdP)
認証情報を管理しており、ユーザー認証後にその結果を他のシステムに渡す役割を担います。AWSだと例えばCognitoのユーザープール、他の外部IdPであれば今回使うOktaやEntra IDなどがそれにあたります。
フェデレーション
異なるサービス間で認証情報を連携することです。Oktaの公式サイトから引用します。
フェデレーションアイデンティティとは、複数の独立したアイデンティティ管理システムを横断してユーザーのアイデンティティを連結する方法です。これにより、セキュリティを保持しながら、システム間の迅速な移動が可能になります。
Security Assertion Markup Language(SAML)
SSOを実現するための手法の1つで、IdPとサービスプロバイダー（SP）間で認証情報を連携させる際に用います。標準化団体であるOASIS(Organization for the Advancement of Structured Information Standards)のページから引用します。
SAML consists of building-block components that, when put together, allow a number of use cases to be supported. The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship.
（自動翻訳：SAMLは、構成要素となるコンポーネントから構成されており、これらを組み合わせることで、様々なユースケースに対応できます。これらのコンポーネントは主に、信頼関係が確立された自律的な組織間で、ID、認証、属性、および認可情報を転送することを可能にします。）
ページにはSAMLの概念間の関係も記されていましたので併せて掲載します。
各コンポーネントについて解説＆引用文を掲載します。
Assertions（アサーション）
IdPが発行する署名付きのSAMLアサーション(XML)で、ユーザーの認証結果や属性情報などをSPに伝えるものです。署名検証にはIdPの公開鍵証明書を使います。SPは自身が信頼しているIdPが発行した証明書をもって、SSOを実現しています。こちらもNISTの文書から引用します。
SAML assertions carry statements about a principal that an asserting party claims to be true. The valid structure and contents of an assertion are defined by the SAML assertion XML schema.
（自動翻訳：SAMLアサーションは、アサーションを行う側が真であると主張するプリンシパルに関するステートメントを伝達します。アサーションの有効な構造と内容は、SAMLアサーションXMLスキーマによって定義されます。）
Protocols（プロトコル）
アイデンティティ管理とアサーション取得のためのリクエストとレスポンスを定義します。こちらもNISTの文書から引用します。
SAML protocol messages are used to make the SAML-defined requests and return appropriate responses. The structure and contents of these messages are defined by the SAML-defined protocol XML schema.
（自動翻訳：SAMLプロトコルメッセージは、SAML定義のリクエストを作成し、適切なレスポンスを返すために使用されます。これらのメッセージの構造と内容は、SAML定義のプロトコルXMLスキーマによって定義されます。）
Bindings（バインディング）
こちらはそのまま引用文を載せます。
The means by which lower-level communication or messaging protocols (such as HTTP or SOAP) are used to transport SAML protocol messages between participants is defined by the SAML bindings.
（自動翻訳：参加者間でSAMLプロトコルメッセージを転送するために、低レベルの通信プロトコルまたはメッセージングプロトコル（HTTPやSOAPなど）を使用する手段は、SAMLバインディングによって定義されます。）
Profiles（プロファイル）
こちらもそのまま引用文を載せます。
Profiles typically define constraints on the contents of SAML assertions, protocols, and
bindings in order to solve the business use case in an interoperable fashion.
（自動翻訳：プロファイルは通常、ビジネスユースケースを相互運用可能な方法で解決するために、SAMLアサーション、プロトコル、バインディングの内容に対する制約を定義します。）
Metadata（メタデータ）
SAMLを設定する際にSP側（IIC）でIdP（Okta）について、どのURLにSAMLリクエストを送るか、どの証明書で署名を検証するか等、設定に必要な情報があります。これらをまとめて取り込めるようにしているのがSAMLメタデータです。下記は同じくOASISからの引用です。
SAML profiles require agreements between system entities regarding identifiers, binding support and endpoints, certificates and keys, and so forth. A metadata specification is useful for describing this information in a standardized way.
（自動翻訳：SAMLプロファイルでは、識別子、バインディングサポートとエンドポイント、証明書と鍵などに関して、システムエンティティ間の合意が必要です。メタデータ仕様は、これらの情報を標準化された方法で記述するのに役立ちます。）
Entities MAY publish their metadata documents at a well known location by placing the document at the location denoted by its unique identifier, which MUST be in the form of a URL (rather than a URN).
（自動翻訳：エンティティは、メタデータ文書を一意の識別子で示される場所に配置することにより、既知の場所に公開することができます。この識別子は、URNではなくURL形式でなければなりません（MUST））
メタデータURLの形式は利用するIdPにより異なります。Oktaの場合は公式ページによるとhttps://***/sso/saml/metadataで共有されるようです。自身の環境でもそのような形になっていました。
ACS URL（Assertion Consumer Service）
SP（IIC）がSAMLアサーションを受け取るURLです。
One or more elements that describe indexed endpoints that support the profiles of the Authentication Request protocol defined in [SAMLProf]. All service providers support at least one such endpoint, by definition.
（自動翻訳：[SAMLProf] で定義された認証要求プロトコルのプロファイルをサポートするインデックス付きエンドポイントを記述する1つ以上の要素。定義上、すべてのSPは少なくとも1つのエンドポイントをサポートします。）
Issuer（Entity ID）
IdPやIICを一意に示す識別子です。
The element, with complex type NameIDType, provides information about the issuer of a
SAML assertion or protocol message.
（自動翻訳：複合型NameIDTypeを持つ要素は、SAMLアサーションまたはプロトコルメッセージの発行者に関する情報を提供します。）
System for Cross-domain Identity Management (SCIM)
IETF（Internet Engineering Task Force）が出しているRFCの文章から引用します。ユーザーやグループを作成したり削除したりした時、その情報を更新して異なるドメイン間でその情報を同期するためのプロトコルです。
The System for Cross-domain Identity Management (SCIM) specification is designed to manage user identity in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. The intent of the SCIM specification is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.
（自動翻訳：クロスドメインID管理システム（SCIM）仕様は、クラウドベースのアプリケーションやサービスにおけるユーザーID管理を標準化し、相互運用性、セキュリティ、および拡張性を実現することを目的としています。この仕様群は、既存のスキーマと導入事例の知見を基盤としつつ、開発と統合の容易さに特に重点を置いて設計されています。既存の認証・認可・プライバシー管理モデルを活用しながら、SCIM仕様の主な目的は、共通のユーザースキーマと拡張モデルを提供するとともに、標準プロトコルを用いたこのスキーマの交換パターンを示すバインディング文書を提供することで、ユーザー管理業務のコストと複雑さを軽減することにあります。要するに、クラウド内外でのユーザー移動を迅速かつ低コストで簡単に実現することを目指しているのです。）
IICの外部IdPとしてOktaを設定
AWS公式ページを参考に設定していきます。
AWS公式ブログを参考に実装イメージも作成しました。
手順➀：SAML連携を実施
信頼関係を結ぶためIdP(Okta)にSPのEntity IDとACS URLを、SP(IIC)にIdPのEntity ID、SSO URL、メタデータを入力します。
Okta側でSSO用にIICを追加
Okta Admin ConsoleからSSO用にIICを追加します。
IIC側でOktaをIdPとして指定
経験がある方は本パートのIIC設定画面の画像を見て、「あれ？」と思うことでしょう。選択する項目自体は変わらないのでこのまま掲載させていただきます。ヒントは「インスタンス」です。詳しくは「おまけ」にて。
Okta側にIICの情報を入力
再びOkta Admin Consoleから直前に入手したIICの情報を入力します。一番上のボタンは「キャンセル」になっていますが、選択する前は「編集」になっています。
以上でSAML連携が完了です。
手順➁：自動プロビジョニングの有効化
IICで自動プロビジョニングを有効化
Oktaに自動プロビジョニング用の情報を入力
Okta Admin Consoleから再度情報を入力していきます。
SCIMエンドポイントの値をベースURLに、アクセストークンをAPIトークンに入力してテストします。
テストが成功したらOKです。
これで自動プロビジョニングの準備が整いました。
手順➂：プロビジョニング動作確認
それではOktaのユーザー情報がIICにも自動で反映されるか試してみます。
Oktaでユーザーを追加
IIC側のディレクトリを確認
作成者欄がSCIMとなっているユーザーが追加されていれば、自動プロビジョニングが問題なく行われています。
上のAWSコンソール画面上に記載がありますが、自動プロビジョニングを有効化している場合、IIC側で新たにユーザーを追加したり属性を編集することはできません。Okta側で編集が必要です。
手順➃：作成したユーザーでOkta経由でAWSの環境にアクセス
ユーザーへの権限の付与
前の手順のままだとOktaからアクセスポータルへ行っても権限が無いので何もできません。なので、IIC側でユーザーに特定のアカウントに対する許可セットを付与します。
すると選択したアカウント内にユーザー用クロスアカウントロールが作成されます。権限は許可セットで指定した内容になっています。
作成したユーザーでOktaにサインインしてAWSのアクセスポータルに接続します。
問題なく操作できそうです。
最後に
2年前を振り返ってみると当時は本当に手順を調べて試すのに必死で、その記録を残すだけで精いっぱいだったんだろうなと感じました（苦笑）。復習も兼ねて、今回SAMLに関する基礎知識や、実際に実装する際に考慮すべき点について補足できて良かったです。ここまでお読みいただきありがとうございました。
おまけ
今回Oktaと連携するIICがアカウントインスタンスの場合、連携はできますが許可セットの付与（権限を与える）できないのでご注意ください。私は一発目の検証で引っかかってしまいました。先月ちょうどJAWSのLTでまとめてくださった方がいらっしゃったので、詳細を知りたい方は下記スライドをご参照ください。
参考URL