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

機密アプリケーションの名前を入力します。最大で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を入力します。

When you create a custom app using IAM custom SDK and integrate with IAM Social Login, the custom app needs to have the Linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.

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

アプリケーションの「「自分のアプリに表示」チェックボックスを選択すると、そのアプリケーションは「自分のアプリ」ページに表示されますが、このチェックボックスを選択してもアプリケーションへの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」フィールドにHTTPURLを使用する場合は、このチェック・ボックスをオンにします。たとえば、内部的にリクエストを送信する場合、暗号化されない通信が必要な場合に、またはOAuth 1.0との下位互換性が必要な場合は、HTTP URLを使用できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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