機密アプリケーションの追加

機密アプリケーションの名前を入力します。最大で125文字を入力できます。

長い名前が付いたアプリケーションの場合、そのアプリケーション名は切り捨てられて「自分のアプリケーション」ページに表示されます。アプリケーション名は、できるかぎり短くすることを検討してください。

機密アプリケーションの説明を入力します。最大で250文字を入力できます。

「アプリケーション・アイコン」ウィンドウで「閉じる」(X)をクリックして、デフォルトのアプリケーション・アイコンを削除してから、アプリケーションに独自のアイコンを追加します。このアイコンは、「自分のアプリケーション」ページおよび「アプリケーション」ページのアプリケーション名の横に表示されます。

ログインの成功後にユーザーがリダイレクトされるURL (HTTPまたはHTTPS)を入力します。この値は、SAML RelayStateパラメータとも呼ばれます。HTTPS形式が推奨されます。HTTPはテスト目的でのみ使用してください。

エンタープライズ・アプリケーションの場合、アプリケーションURLは、ユーザーがエンタープライズ・アプリケーションにアクセスするために使用するURLです。アプリケーション・ゲートウェイのホスト名とポート番号を使用します。アプリケーション・ゲートウェイに複数のインスタンスがある場合は、ロード・バランサのホスト名とポート番号を使用します。

「カスタム・サインインURL」フィールドに、カスタム・サインインURLを指定します。ただし、IAMによって提供されるデフォルトのログイン・ページを使用する場合は、このフィールドを空白のままにします。

「カスタム・サインアウトURL」フィールドに、カスタム・サインアウトURLを指定します。ただし、IAMによって提供されるデフォルトのログイン・ページを使用する場合は、このフィールドを空白のままにします。

これはオプションのフィールドです。失敗した場合にユーザーをリダイレクトする必要があるエラー・ページURLを入力します。指定しない場合は、テナント固有のエラー・ページURLが使用されます。両方のエラーURLが構成されていない場合、エラーはIAMエラー・ページ(/ui/v1/error)にリダイレクトされます。

ユーザーがソーシャル認証(Google、Facebookなど)を使用してIAMにログインしようとする場合、「カスタム・エラーURL」フィールドにコールバックURLを構成する必要があります。ソーシャル・プロバイダでは、IAMをコールしてソーシャル認証後にレスポンスを返信するには、このコールバックURLが必要です。指定されたコールバックURLは、ユーザーが存在するかどうか(これが初回のソーシャル・ログインの場合)を検証するために使用され、ソーシャル認証に失敗した場合はエラーが表示されます。これは、ログインに成功したソーシャル・ユーザー・アカウントがIAMに存在しない場合に、コールバックがソーシャル登録ユーザー詳細とともに送信されるURLです。

これはオプションのフィールドです。ソーシャル・プロバイダとIAM間のユーザーのリンクが完了した後にIAMがリダイレクトできるURLを入力します。

IAMカスタムSDKを使用してカスタム・アプリケーションを作成し、IAMソーシャル・ログインと統合する場合、カスタム・アプリケーションには、ソーシャル・プロバイダとIAM間のユーザーのリンクが完了した後にリダイレクトできるリンク・コールバックURLが必要です。

このチェック・ボックスは、機密アプリケーションをユーザーの「自分のアプリケーション」ページにリストする場合に選択します。この場合、アプリケーションをリソース・サーバーとして構成する必要があります。

アプリケーションの「「マイ・アプリケーション」に表示」チェック・ボックスを選択すると、そのアプリケーションは「マイ・アプリケーション」ページに表示されますが、このチェック・ボックスを選択しても、アプリケーションに対するSSOは有効化または無効化されません。

SSOを有効化または無効化するフラグは、アプリケーション・テンプレートから取得されます。

エンド・ユーザーが「アクセス権の追加」をクリックして、「自分のアプリケーション」ページからアプリケーションへのアクセスをリクエストできるようにする場合は、このチェックボックスを選択します。セルフサービスが有効でない場合、ユーザーには「アクセス権の追加」ボタンは表示されません。

機密アプリケーションの場合: 権限付与を認可として実施

エンタープライズ・アプリケーションの場合: ユーザーにこのアプリケーションが付与されている必要があります

IAMでユーザーおよびグループへの権限付与に基づいてアプリケーションへのアクセスを制御する場合、このオプションを選択します。このオプションの選択を解除すると、認証されたユーザーはアプリケーションにアクセスできます。

機密アプリケーションに関連付けられているアクセス・トークンの有効期間(秒)を定義します。

このチェック・ボックスは、「リソース所有者」、「認可コード」または「アサーション」権限付与タイプの使用時に取得するリフレッシュ・トークンを使用する場合に使用します。

アクセス・トークンとともに返され、機密アプリケーションに関連付けられているリフレッシュ・トークンの有効期間(秒)を定義します。

機密アプリケーションのアクセス・トークンが処理されるプライマリ受信者を入力します。

機密アプリケーションのアクセス・トークンが処理されるセカンダリ受信者を入力し、「追加」をクリックします。セカンダリ受信者は「セカンダリ・オーディエンス」列に表示され、「保護」列によってセカンダリ・オーディエンスが保護されているかどうかを確認できます。

アプリケーションで他のアプリケーションのどの部分にアクセスするかを指定するには、それらのスコープを機密アプリケーションに追加します。

アプリケーションは、外部パートナまたは機密アプリケーションと安全に対話する必要があります。また、あるOracle Cloudサービスのアプリケーションは、別のOracle Cloudサービスのアプリケーションと安全に対話する必要があります。各アプリケーションには、他のアプリケーションが使用できるリソースを決定するアプリケーション・スコープがあります。

認可スコープが、クライアントの制御下にある保護リソースに、または認可サーバーに登録された保護リソースに制限されている場合に使用します。

クライアントは、独自の資格証明を提供してアクセス・トークンを取得します。このアクセス・トークンは、特定のリソース所有者ではなく、クライアントの独自のリソースに関連付けられているか、そうでなければクライアントがアクションを許可されているリソース所有者に関連付けられています

アサーションとして表される、認可サーバーでの直接的なユーザー承認ステップのない既存の信頼関係を使用する場合に使用します。

クライアントは、ユーザーJSON Webトークン(JWT)アサーションまたはサードパーティ・ユーザーJWTアサーションとクライアント資格証明を提供して、アクセス・トークンをリクエストします。JWTアサーションは、セキュリティ・ドメイン全体でのアイデンティティおよびセキュリティ情報の共有を容易にする情報のパッケージです。

SAML2アサーションとして表される、認可サーバーでの直接的なユーザー承認ステップのない既存の信頼関係を使用する場合に使用します。

クライアントは、ユーザーSAML2アサーションまたはサードパーティ・ユーザーSAML2アサーションとクライアント資格証明を提供して、アクセス・トークンをリクエストします。SAML2アサーションは、セキュリティ・ドメイン全体でのアイデンティティおよびセキュリティ情報の共有を容易にする情報のパッケージです。

この権限付与タイプは、クライアント・アプリケーションとリソース所有者間の仲介として認可サーバーを使用して、認可コードを取得する場合に選択します。

認可コードは、リソース所有者が認可サーバーに承諾を与えた後、ブラウザのリダイレクトを介してクライアントに返されます。その後、クライアントは認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークン)に交換します。リソース所有者の資格証明はクライアントに公開されません。

アプリケーションが認可サーバーによる認証に使用するクライアント資格証明の機密を保持できない場合は、このチェック・ボックスを選択しますたとえば、アプリケーションがJavaScriptなどのスクリプト言語を使用してWebブラウザに実装されている場合です。アクセス・トークンは、中間認可ではなく、リソース所有者の認可リクエストに応答してブラウザ・リダイレクトを介してクライアントに返されます。

「デバイス・コード」権限付与タイプは、クライアントがOAuth認可サーバーからリクエストを受信できない場合に選択します。たとえば、これはHTTPサーバーとして機能できません(ゲーム機、ストリーミング・メディア・プレーヤ、デジタル画像フレームなど)。

このフローで、クライアントは、ユーザー・コード、デバイス・コードおよび検証URLを取得します。次に、ユーザーは、個別のブラウザで検証URLにアクセスしてアクセス・リクエストを承認します。その後にのみ、クライアントはデバイス・コードを使用してアクセス・トークンを取得できます。

「TLSクライアント認証」権限付与タイプは、クライアント証明書を使用してクライアントで認証する場合に選択します。トークン・リクエストにX.509クライアント証明書が含まれ、リクエストされたクライアントが「TLSクライアント認証」権限付与タイプで構成されている場合、OAuthサービスは、リクエストのClient_IDを使用してクライアントを識別し、クライアント構成の証明書でクライアント証明書を検証します。クライアントは、2つの値が一致する場合にのみ正常に認証されます。

セキュリティを強化するには、「TLSクライアント認証」権限付与タイプを有効にする前に、OCSP検証を有効にして構成し、信頼できるパートナ証明書をインポートします。

このチェック ボックスは、[リダイレクトURL]、[ログアウトURL]、または [ログアウト後リダイレクトURL]フィールドにHTTP URLを使用する場合はオンにします。たとえば、内部的にリクエストを送信している場合、暗号化しない通信が必要な場合、またはOAuth 1.0との下位互換性が必要な場合は、HTTP URLを使用できます。

アプリケーションを開発またはテスト中でSSLを構成していない場合にも、このチェック・ボックスを選択します。このオプションは、本番デプロイメントには推奨されません。

認証後にユーザーがリダイレクトされるアプリケーションURLを入力します。

ノート: 絶対URLを指定します。相対URLはサポートされていません。

アプリケーションからのログアウト後にユーザーをリダイレクトするURLを入力します。

機密アプリケーションからのログアウト後にユーザーがリダイレクトされるURLを入力します。

クライアント・タイプを選択します。使用可能なクライアント・タイプは、「信頼できる」および「機密」です。クライアントが自己署名ユーザー・アサーションを生成できる場合は、「信頼できる」を選択します。次に、クライアントが自己署名アサーションへの署名に使用する署名証明書をインポートするために、「証明書のインポート」をクリックします。

コンテンツ暗号化アルゴリズムのいずれかを選択します。

有効にすると、この属性によって、アプリケーションに対して構成されているすべてのスコープの「同意が必要」属性が上書きされ、スコープに同意が不要になります。

クライアント・アプリケーションが認可されたリソースにアクセスできるようにするには、次のいずれかのオプションを選択します:

• すべて – ドメイン内の任意のリソース(すべて)にアクセスします。すべてのリソースへのアクセスを参照してください。

• 特定 – クライアントとリソース(特定)の間に明示的な関連付けが存在するリソースのみにアクセスします。特定のスコープを持つリソースへのアクセスを参照してください。

ノート: 認可されたリソースを定義するオプションは、機密アプリケーションでのみ使用できます。信頼スコープは、モバイル・アプリケーションに対しては定義できません。

自分のアプリケーションが他のアプリケーションのAPIにアクセスする場合は、「トークン発行ポリシー」セクションで「リソースの追加」を選択します。次に、「スコープの追加」ウィンドウで、自分のアプリケーションが参照するアプリケーションを選択します。

ノート: スコープを削除するには、スコープの横にある「x」アイコンをクリックします。ただし、保護されているスコープは削除できません。

「アプリケーション・ロールの追加」を選択します。「アプリケーション・ロールの追加」ウィンドウで、このアプリケーションに割り当てるアプリケーション・ロールを選択します。これにより、アプリケーションは、割り当てられた各アプリケーション・ロールでアクセス可能なREST APIにアクセスできるようになります。

たとえば、リストから「アイデンティティ・ドメイン管理者」を選択します。アプリケーションでは、アイデンティティ・ドメイン管理者が使用可能なすべてのREST APIタスクにアクセスできるようになります。

アプリケーション・ロールを削除するには、アプリケーション・ロールを選択し、「削除」をクリックします。

ノート: 保護されたアプリケーション・ロールは削除できません。