サインオンモードでAmazon AWS IAMロールを使用するように構成されたAWSインスタンスがある場合、そのインスタンスからオプションの子アカウントを削除すると、そのロールのプロビジョニングが削除されることがUIで警告され、システムログにイベントが生成されます。
以下の設定手順を実行する前に、Sign On Options（サインオンオプション）の手順で[Done（完了）]をクリックして、AWSアプリが作成されていることを確認してください。
Okta/AWS Account FederationのSAML統合では現在、次の機能をサポートしています。
OktaとAmazon Web Services（AWS）の統合により、エンドユーザーは1つ以上のAWSアカウントに対して認証を行い、SAMLでのシングル サインオンを使用して特定のロールにアクセスできます。Okta管理者は、1つ以上のAWSからOktaにロールをダウンロードし、それらをユーザーに割り当てることができます。さらに、Okta管理者は、Oktaを介してユーザーの認証済みセッションの期間を設定することもできます。
AWSにログインすると、エンドユーザーにAWS画面が表示され、1つ以上のAWSアカウントで割り当てられているAWSロールのリストが表示されます。エンドユーザーはログイン時のロールを選択することができ、そのロールによって認証されたセッションの期間中のアクセス権限が定義されます。
複数のAWSアカウントを接続する場合は、こちらの手順に従ってください：OKTAをユーザーグループを介して複数のAWSインスタンスに接続する
この方法では、サポートできるアカウント数に上限はありません。特定のAWSアカウントへのアクセスは、Okta内、またはADやLDAPなどの別のレコードシステムからのグループ割当を介して管理されます。AWSアカウントを追加するたびに、そのアカウントを代表する新しいグループを作成し、アクセスを許可する必要があります。ADまたはLDAPでは、ネストされたグループを使用して、ユーザーロールに基づいたアクセスの割り当てを簡素化できます（このドキュメントの構成セクションで詳しく説明します）。
以下の単純な4つのステップのプロセスを行って、OktaをAWSインスタンスに接続して、ユーザーのAWSロールにSSOを提供することができます。
AWSにてSAMLを使用するには、AWSでIDプロバイダーとしてOktaを設定し、SAML接続を確立する必要があります。このセクションの手順では、このプロセスについて説明します。
AWSコンソールにサインインします。
[Identity and Access Management（IAM）]サービスに移動します。
メニューバーにある[Identity Providers（IDプロバイダー）]を選択します。
[Create Provider（プロバイダーを作成）]をクリックし、新しいインスタンスを作成します。
[Configure Provider（プロバイダーを構成）]画面で、以下を入力します。
Provider Type（プロバイダー タイプ）：ドロップダウンメニューから[SAML]を選択します。
Provider Name（プロバイダー名）：例えばOktaなど、好みの名前を入力します。
Metadata Document（メタデータドキュメント）：次のメタデータファイルをアップロードします。
Okta管理者ダッシュボードにサインインして、この値を生成します。
プロバイダーの構成を終了します。
IDプロバイダーのリストで作成したIDプロバイダーを見つけ、その[Provider ARN（プロバイダーARN）]の値をコピーします。これは、この後の構成で必要になります。
AWSでOktaをIDプロバイダーとして構成したので、Oktaが取得してOktaのユーザーに割り当てることができる既存のIAMロールを作成または更新できます。Oktaは、前のステップ（ステップ1：AWSアカウントでOktaをIDプロバイダーとして構成する）で構成したOkta SAML IDプロバイダーへのアクセスを許可するように構成されたロールにのみ、ユーザーにSSOを提供できることに注意してください。
アカウントの既存ロールにSSOアクセスを許可するには：
そのロールの[Trust Relationship（信頼関係）]タブを選択し、[Edit Trust Relationship（信頼関係を編集）]をクリックします。
ここで、IAM信頼関係ポリシーを変更して、前の手順で構成したSAML IDPを使用してOktaへのSSOを許可する必要があります。
SSOアクセスを新しいロールに許可するには：
[Roles（ロール）] > [Create Role（ロールを作成）]に移動します。
信頼できるエンティティの[SAML 2.0 federation（SAML 2.0フェデレーション）]のタイプを使用します。
[Okta（IDプロバイダーの名称）]を[SAML provider（SAMLプロバイダー）]として選択し、[Allow programmatic and AWS Management Console access（プログラムによるアクセスとAWSマネジメント コンソールへのアクセスを許可）]し、[Permissions（権限）]に進みます。
作成するロールに割り当てる優先ポリシーを選択します。
ロールの構成を終了します。
Oktaがアカウントから利用可能なロールのリストを動的に取得できるように、特定の権限を持つAWSユーザーを作成する必要があります。これにより、管理者はユーザーとグループを特定のAWSロールに簡単かつ安全に割り当てることができます。
AWSコンソールから、[IAM > Users（ユーザー）]に移動します。
[Add user（ユーザーを追加）]を選択します。
User name（ユーザー名）（例：OktaSSOuser）を入力し、[Access type（アクセスタイプ）]として[Programmatic access（プログラムによるアクセス）]を選択し、[Permissions（権限）]に進みます。
[Attach existing policies directly（既存のポリシーを直接付与）]、続けて[Create Policy（ポリシーを作成）]を選択します。
JSONを使用して[Policy Document（ポリシードキュメント）]を入力し、内容を次のように置き換えます。
{ "Version"： "2012-10-17", "Statement"： [ { "Effect"： "Allow", "Action"： [ "iam：ListRoles", "iam：ListAccountAliases" ], "Resource"： "*" } ] }[Review policy（ポリシーをレビュー）]します。詳細は必要に応じてAWSドキュメントを参照します。
希望する[Policy Name（ポリシー名）]を入力し、ポリシー構成を完了します。
[Add user（ユーザーの追加）]タブに戻り、新しく作成したポリシーを付与します。
リストを更新します。
今作成したばかりのポリシーを検索し、選択します。
[Secret access key（シークレット アクセスキー）]と[Access key ID（アクセスキーID）]が表示されている最後の画面に進みます。後でOktaでAWSアプリを構成する際に必要になるため、これらの値をコピーしておきます。ユーザー作成を終了します。
AWSコンソールで実行する必要のある手順が完了したので、OktaでAWS Account Federationアプリ統合の構成を開き、次の手順を実行してセットアップを完了します。
OktaでAWS Account Federationアプリの[Sign On（サインオン）]タブを選択し、[Edit（編集）]をクリックします。
Join all roles（すべてのロールを結合）：このオプションにより、ユーザーに割り当てられたすべての利用可能なロールを次のように結合できます。
例えば、ユーザーに[Role1]と[Role2]が直接割り当てられ（ユーザーからアプリへの割り当て）、そのユーザーが、[RoleA]と[RoleB]が割り当てられたグループGroupAWSに属している場合（グループからアプリへの割り当て）、次のようになります。
引き続きOktaで、AWSアプリの[Provisioning（プロビジョニング）]タブを選択し、[Edit（編集）]をクリックします。
注：AWS Account Federationアプリ統合はプロビジョニングをサポートしません。[Provisioning（プロビジョニング）]タブでのこの設定は、OktaにAPIアクセスを提供して、ユーザー割り当て時に割り当てるAWSロールのリストをダウンロードするために必要です。これにより、ユーザーに複数のロールを割り当て、SAMLアサーションでそれらのロールを渡すことができます。
Connected Accounts ID（接続済みアカウントID）（任意）：接続済みアカウントのすべてのIDのコンマ区切りリストを提供します。これは、AWSコンソールの左上隅にある[My Accounts（マイアカウント）]ページの各AWSアカウントで確認できます。
注：サインオンモードとしてAmazon AWS IAMロールを使用するように構成されたAWSインスタンスがある場合、そのインスタンスからオプションの子アカウントを削除すると、そのロールのプロビジョニングが削除され、[System Log（システムログ）]にイベントが生成されます。
API認証情報が機能していることを確認するには、［Test API Credentials（APIをテスト）]をクリックします。
AWSからロールと権限を更新できるようにするには、[Create Users（ユーザーの作成）]と[Update User Attributes（ユーザー属性の更新）]を有効にする必要があります。
注：AWSでユーザーを作成または更新していませんが、これによりAPIの必要な部分がアクティブ化され、OktaがAWSアカウントからOktaが信頼するロールを取得できるようになります。
[User Assignment（ユーザーの割り当て）]画面で、[SAML User Roles（SAMLユーザーロール）]に移動し、このユーザーに割り当てるすべてのロールを選択して、[Save（保存）]をクリックします。この例では、テストユーザーに2つのロールを割り当てました。
重要：属性[IdP and Role Pairs（IdPとロールのペア）（内部属性）]が表示されている場合は、無視してください。これは内部属性であり、ユーザーの割り当てには影響しません。
ユーザーには、Oktaで割り当てられたロールのリストが記載されたAWS画面が表示されます。ここで、AWSログイン時を想定したロールを選択します。
APIを介した複数のAWSアカウントの接続は、現在ではサポートが終了していますのでご注意ください。次の手順を使用して、グループを介した複数のAWSアカウントのロール管理に切り替えることができます。
以下の手順は、プロファイルソースであるAD / LDAPを含むすべてのアプリケーションに適用されます。ローカルOktaグループも使用できます。
アクセスを提供する特定のアカウントとロールの組み合わせごとに、Oktaにグループが存在する必要があります。これらのグループは、AWSロール固有のグループとして考えることができます。グループ名は特定の構文に従う必要があります（詳細については、設定手順を参照してください）。
これらのロール固有のグループのメンバーであるすべてのユーザーには、単一のエンタイトルメントが付与されます。つまり、1つの特定のAWSアカウントの1つの特定のロールへのアクセスです。これらのグループは、スクリプトで作成するか、AWSからリストとしてエクスポートするか、手動で作成できます。
ただし、各ユーザーを特定のAWSロールグループに割り当ててユーザーアクセスを管理するように拡張することはできません。管理を簡素化するために、組織内のさまざまなAWSエンタイトルメントのセットを必要とするすべての個別のユーザーセットに対して多数のグループを作成することもお勧めします。
これらのグループは、異なる部門固有のグループの形式でOktaまたはAD / LDAP階層に既に存在している場合がありますが、AWS専用に作成することもできます。
各AWSアカウントは、SAMLアクセス用に構成する必要があります。これには、信頼できるIDPとしてOktaをAWSアカウントに追加し、この新しいIDPを介したアクセスを許可する各ロールの信頼関係を作成する必要があります。これらは、単一のAWSアカウントにSAML SSOを提供するために従う手順と同じですが、すべてのアカウントで実行する必要があります。高度な組織の場合、これは各アカウントでの簡単なSAML設定においてCloudFormationまたはAWS APIスクリプトを使用して自動化できます。
このタイプの統合は、プロビジョニング機能を使用しません
AWSアカウント/ロール数に制限はありません
まず、OktaでのSAMLアクセス用にすべてのAWSアカウントを設定します。
Oktaで新しいAWSアプリを作成することから始め、[Single Sign-On（シングルサインオン）]のタブからSAMLを選択します。
OKTAを単一のAWSインスタンスに接続するのステップ1と2を実施します。
ユーザーにアクセスを許可するすべてのAWSアカウントとロールに対してこれを行い、すべてのアカウントが同じ正確なSAMLメタデータで設定され、同じ正確な名前が付けられていることを確認します。SAMLプロバイダー名またはメタデータドキュメントが異なるアカウントにはアクセスできません。
すべてのAWSアカウントがSAML用に構成されたら、ユーザーにアクセスを許可する各アカウントのAWSロールごとにグループをADに作成する必要があります。これは、いくつかの異なる方法で実現できます。
オプション 1：各アカウントの各ロールに対しADグループを作成する、Oktaに接続されたAWSとAD / LDAP間のスクリプト
これは自動化の最大の可能性を提供しますが、スクリプトを構成するには、AWS管理チームとAD / LDAP管理チームの間の調整が必要です。Oktaは、将来的にはこの設定の簡素化に役立つサンプルスクリプトを提供することを視野に入れていますが、現在はご利用いただけません。
オプション 2：AWSからのCSVエクスポート
AWSとAD / LDAP間のスクリプトによるアプローチが不可能な場合、CSVで各AWSアカウントのロール名のリストをエクスポートしてからOktaにインポートするのがより楽なアプローチになることがあります。
オプション 3: 手動での作成
Oktaにて手動でAWSロールグループを作成することも可能です。このモデルは最も単純ですが、各アカウントのロールごとにOktaでグループを作成するには、充分なセットアップの時間と維持管理が必要になります。
これらのAWSロール固有のグループをディレクトリにどのように作成するかに関わらず、グループ名は以下の形式を推奨します。
aws#[account alias]#[role name]#[account #]
例：
aws#northamerica-production#Tier1_Support#828416469395
独自のグループ構文を使用する場合は、アカウントエイリアス、ロール名、およびアカウント番号を、それぞれの間に認識可能な区切り文字を入れて含めるようにしてください。これには、後の手順でカスタム正規表現を作成できる必要があるため、これらの高度なトピックに慣れている場合にのみ実行すべきです。
グループが作成されてOktaにインポートされたら、以前にセットアップしたAWSアプリを、AWSがAWSロールグループ メンバーシップを構文的に理解できるエンタイトルメントに変換するように構成する必要があります。
前に設定したAWSアプリに移動します。
[Sign On（サインオン）]タブを選択し、[Edit（編集）]をクリックします。
[App Filter（アプリフィルター）]、[Group Filter（グループフィルター）]、および[Role Value Pattern（ロール値パターン）]フィールドを見つけます。これらのフィールドは、OktaがAWSロールグループをこの機能のエンタイトルメントにマッピングする方法を制御します。これらのフィールドは以下のように構成します：
App Filter（アプリフィルター）：このフィルターは、Oktaが特定のアプリまたはディレクトリへのAWSエンタイトルメント マッピングに使用できるグループのリストを絞り込みます。これはセキュリティの目的で存在し、不正な管理者が特定のAWSアカウント/ロールへの不正アクセスを意図的に取得するために、特定の構文に従ってグループを作成する可能性を回避します。Active Directoryでグループを作成した場合、active_directoryと入力し、ローカルOktaグループによる使用に制限したい場合はoktaと入力します。他のアプリケーションについては、例えばBamboo HRアプリにはbamboohr、またはOkta + Egnyteグループにはokta、egnyteなどの値を使用することができます。
Group Filter（グループフィルター）：このフィルターフィールドは、正規表現を使用して特定の構文に従う、選択したアプリフィルターからのグループのみを検査します。上記のOkta推奨のデフォルトのAWSロールグループ構文を使用することを選択した場合は、次の正規表現文字列を使用できます。
^aws\#\S+\#(?{{role}}[\w\-]+)\#(?{{accountid}}\d+)$ この正規表現は論理的には次を行います：AWSで始まり、次に#、空白以外の文字のみを含む文字列、次に#、単語文字またはマイナス記号を含むAWSロール、次に#、AWSアカウントIDとなっているグループを検索する
デフォルトの推奨AWSロールグループ構文を使用しなかった場合は、AWSロールグループを適切にフィルター処理し、{{role}}と{{accountid}}という2つの異なるRegexグループ内のAWSロール名とAWSアカウントIDをそれぞれキャプチャする正規表現を作成する必要があります。
Role Value Pattern（ロール値パターン）：このフィールドは、AWSロールグループの構文内でキャプチャされたAWSロールとアカウントIDを取得し、ユーザーがサインインしたときにアカウントとロールを表示できるようにするために、AWSがOktaのSAMLアサーションで必要とする適切な構文に変換します。
このフィールドは常にこの特定の構文に従います：
arn：aws：iam：：${accountid}：saml-provider/[SAML Provider Name],arn：aws：iam：：${accountid}：role/${role} [SAML Provider Name]を、すべてのAWSアカウントで設定したSAMLプロバイダーの名前に置き換えます。他の文字列は変更せずに、そのままコピーして貼り付けます。
最後に、これでAWSロールグループをエンタイトルメントにマッピングするようにAWSアプリが適切に構成されたので、すべてのAWS管理グループをOktaのアプリケーションに割り当てます。これにより、適切なすべてのユーザーがAWSアプリに自動的に割り当てられ、上記ステップで完了した手順により、アクセスする必要のある適切なエンタイトルメントのみが表示されるようになります。
設定はこれで完了です！ユーザーがOkta End-User DashboardからAWSアプリにアクセスでき、サインオンがシームレスであることを確認してください。
OktaでAPI統合を設定した後に別の新しいIAM Role（IAMロール）を作成しても、Oktaに自動的に入力されません。この新しいロールを反映するには、以下を実施します。
[Applications（アプリケーション）]タブに移動し、[More（その他）]をクリックして、[Refresh Application Data（アプリケーションデータを更新）]をクリックします。
これにより、ユーザーのプロビジョニングで構成されたアプリから最新のロール、プロファイル、およびグループがダウンロードされます。これらのアプリでの新規ユーザー作成の際、Oktaはこのデータを使用します。
[Role（ロール）]属性は、Federated User Login（フェデレーションされたユーザーログイン）およびAmazonのIAMロールのSSOモードに使用されます。SAML User Roles（SAMLユーザーロール）が選択されていない場合は、SAML 2.0のデフォルト値として使用することもできます。
SAMLは複数のロールをサポートしているため、SAML User Roles（SAMLユーザーロール）の属性はSAML 2.0で使用されます。SAML User Roles （SAMLユーザーロール）の値が選択されていない場合、[Role（ロール）]のドロップダウンリストからの値がデフォルトのロールとして使用されます。
ロールは複数選択が可能です。
