認証 URL ユーザー・レジストリーの作成

認証 URL ユーザー・レジストリーは、カスタム ID プロバイダーを参照してユーザーを認証するための単純なメカニズムを提供します。

このタスクについて

このトピックでは、組織内で新規認証 URL ユーザー・レジストリーをリソースとして作成する方法について説明します。 ユーザー・レジストリーを作成したら、そのユーザー・レジストリーをサンドボックス・カタログに追加する必要があります。

ユーザー・レジストリーを構成するには、以下のいずれかのロールが必要です。
  • 管理者
  • 組織の所有者
  • 次の役割を持つカスタム役割:Settings: Manage権限
注:
API Connect HTTP GET 認証 エンドポイントにコールを発行し、ユーザーの認証情報を送信します。 URL 次の例は、認証 URL の ID プロバイダーに対して行われる呼び出しを示しています。ここでは、エンドポイントは https://myauthurl.example.com/user/authenticate として定義されています。
GET /user/authenticate HTTP/1.1
 Host: myauthurl.example.com
 Authorization: Basic c3Bvb246Zm9yaw=
認証 URL エンドポイントが HTTP 状況コード 200 を返した場合、ユーザー認証は成功しています。 200 以外の HTTP 状況コードは、ログイン試行が失敗したことを示します。 API Connect 認証の判断を助けるために、 で始まるすべての X- HTTP ( を除く)とCookieを、 X-Client-CertificateURLのアイデンティティプロバイダーに転送します。例えば:
GET /user/authenticate HTTP/1.1
 Host: myauthurl.example.com
 Authorization: Basic c3Bvb246Zm9yaw=
 X-Forwarded-For: 8.8.9.9
 X-Custom-Header-From-Customer: special
 Cookie: MyCookie=VGhpc0lzV2lja2VkQW1hemluZw==
ユーザーがユーザー API Connect 登録を行うためのフォームを表示された際、どのフィールドが事前に入力されているかは、認証プロバイダー URL からの応答でどのフィールドが返されるかによって異なります。 以下のフィールドのいずれかが返された場合、登録フォームの該当するフィールドは事前入力されます。
  • username
  • email
  • first_name
  • last_name
username フィールドが返されなかった場合、登録フォームにはユーザーが指定したユーザー名が表示されます。 事前入力機能では、認証 URL ID プロバイダーからの応答が以下の条件を満たしている必要があります。
  • Content-Typeapplication/jsonでなければなりません。
  • 応答本体の形式は JSON でなければなりません。
サンプル応答を以下に示します。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "username":"myuser",
  "email":"myuser@example.com",
  "first_name":"My",
  "last_name":"User"
}

手順

  1. API マネージャー で、 「リソース リソース 」をクリックします。
  2. 組織内の現在のユーザー・レジストリーのリストを表示するには、 「ユーザー・レジストリー」 を選択します。
  3. Draft comment: felbin.james@ibm.com
    As part of the iPass documentation update, we're adding the audience tag. Once the portal becomes available in iPass, we can delete the Consumer Catalog and remove the audience filter from the Developer Portal. https://jsw.ibm.com/browse/APICON-10493
    ユーザー登録 」セクションの 「作成」 をクリックします。
    重要: セルフサービスによるオンボーディングが有効になっている場合、またはいずれかのサイトでアカウントの削除が予定されている場合は、 API Manager とConsumer Catalogの間、 あるいはConsumer Catalogのサイト間でユーザー登録情報を共有しないでください。 たとえ個別のユーザー登録が同じバックエンド認証プロバイダー(たとえば、 LDAP サーバーなど)を指している場合でも、それらに対して個別のユーザー登録を作成する必要があります。 この分離により、 Consumer Catalog はカタログ全体で一意のメールアドレスを維持できる一方で、 API Managerには同じ要件が課されることはありません。 また、 ユーザーが Consumer Catalogからアカウントを削除した際に、 API Manager へのアクセスに影響が及ぶという問題も回避できます。
  4. URL ユーザーレジストリを選択し、以下のパラメータを入力します。
    フィールド 説明
    タイトル (必須) 画面で使用するための説明的な名前を入力します。
    名前(必須) CLI コマンドで使用される名前です。 この名前は自動生成されたものです。 ユーザーレジストリを管理するためのCLIコマンドの詳細については、 ツールキットのCLIリファレンスドキュメントを参照してください。
    要約 (オプション) 簡単な説明を入力します。
    表示名 (必須) ユーザー・インターフェースへのログイン時または API Manager アカウントのアクティブ化時にユーザーが選択するために表示される名前。
    注: コンシューマー・カタログは、ログインページでユーザー・レジストリを表示する Title 際、ではなく、を使用します Display Name
    URL (必須) 認証サービスの URL を入力します。 認証を確立する際、 API ConnectURL に対して GET リクエストを送信します。 この呼び出しには、API Connect がその許可ヘッダー内でユーザーから収集したユーザー名とパスワードが含まれます。 いずれか200 OKまたは401 Unauthorizedが返されます。
    TLS クライアント・プロファイル (オプション) 特定の Web サーバーとのセキュア認証を可能にする TLS クライアント・プロファイルを選択します。
    大/小文字を区別する ユーザー名の大/小文字を適切に処理するために、ここでの大/小文字の区別の設定がバックエンドの認証 URL サーバーでの設定と一致していることを確認する必要があります
    • バックエンド・サーバーが大/小文字の区別をサポートする場合にのみ「大/小文字の区別」を選択してください。
    • バックエンド・サーバーが大/小文字の区別をサポートしていない場合は、 「大/小文字の区別」 を選択 しないでください
    注: Consumer Catalog では、ユーザー名の大文字と小文字の区別は行われません。
    注: 少なくとも 1 人のユーザーがレジストリーにオンボードされた後は、この設定を変更することはできません。
    E メールは必須です ユーザーのオンボーディング・プロセスの一部として E メール・アドレスが必要な場合は、このチェック・ボックスを選択します。 これを選択した場合、ソース ID プロバイダーは、オンボーディング時に認証プロセスの一部として E メール・アドレスを提供する必要があります。
    注: Cloud Manager または API Manager へのオンボーディングでは、デフォルトでメールアドレスの入力は必須ではありませんが、 Consumer Catalog へのオンボーディングでは必須となります。
    固有の E メール・アドレス E メール・アドレスがユーザー・レジストリー内で固有でなければならない場合は、このチェック・ボックスを選択します。
    注: コンシューマー カタログ内のすべてのアカウント(同一サイト内の異なるユーザー登録情報を跨ぐものを含む)は、サイト管理者アカウントを含め、一意のメールアドレスを持つ必要があります。
  5. 「保存」をクリックします。
  6. ユーザー・レジストリーをサンドボックス・カタログに追加します。 カタログの作成および構成を参照してください。

結果

このユーザー・レジストリーは、API のセキュリティー定義で基本認証に使用できます。 詳細については、 「基本認証セキュリティスキームの定義」 を参照してください。