サービスの認証フローを開発する
製品をIBM Cloud®にオンボードするときPartner Centerでは、ユーザーがサービスにアクセスする際に安全に識別および検証するための認証フローを開発できます。 認証フローを開発することで、製品を保護し、IBM Cloud内でサービスが安全に統合されるようにすることができます。
開始前に
認証フローの開発を開始する前に、クライアント ID と秘密鍵を構成しておく必要があります。
クライアントIDとシークレットの設定
認証フローを作成するには、クライアント ID と秘密鍵、およびリダイレクト URL が必要です。 クライアント ID は、サービスを識別するために、サービスのパスワードであるシークレットとともに生成されます。 お客様 ID は公開されているため、機密ではありません。 ただし、秘密は機密であり、アプリケーションと許可サーバーにのみ認識されます。 Partner Center でクライアント ID を作成および管理できます。 リダイレクト URL は、認証が成功した後にユーザーがリダイレクトされるサービスのホスト URL です。
以下の例は、リダイレクト URL を示しています。
https://<myapp>.cloud.ibm.com/integrate/auth/callback
http://localhost:3000/auth/callback <-- for testing locally
クライアントIDを生成するには、以下の手順に従ってください:
-
IBM Cloudコンソールで、ナビゲーションメニューアイコン
>Partner Center > My produtsをcクリックします。
-
オンボーディングする製品を選択し、 「ブローカー」 ページに移動します。
-
IBM Cloud SSO のセットアップ をクリックします。
-
クライアント ID を管理できる所有者を追加します。
所有者のみが、クライアント ID セットアップの表示、編集、削除、または追加のリダイレクト URL の追加を行うことができます。 クライアント ID を作成したユーザーは、自動的に所有者リストに追加され、自分自身を削除することはできません。
-
リダイレクト URL を追加し、 次へ をクリックします。 複数の URL を追加して、それらを今後のタスクで
redirect_uriとして使用できます。redirect_uri値はリダイレクト URL を参照します。 -
資格情報を保存します。 クライアント ID とともに生成されたサービスのパスワードをコピーします。 後でパスワードを取得することはできません。
パスワードをお持ちでない場合は、以前に作成したクライアント ID を削除して再作成し、別の ID を生成することができます。
-
「完了 (Done)」 をクリックします。
ステップ 1: 地域エンドポイントの検索
クライアント ID が正常に生成されたら、 oAuth フローの開発を開始できます。 まず、以下のエンドポイントを呼び出して、デプロイされたアプリケーションに近い UI ログイン用の IAM 地域エンドポイントを見つけます。
https://iam.cloud.ibm.com/identity/.well-known/openid-configuration
例として以下のcurlコマンドを参照:
curl -X GET \
https://iam.cloud.ibm.com/identity/.well-known/openid-configuration
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer": "https://iam.cloud.ibm.com/identity",
"authorization_endpoint": "https://iam-region2.cloud.ibm.com/identity/authorize",
"token_endpoint": "https://iam-region2.cloud.ibm.com/identity/token",
...
}
このリクエストは、アプリケーションの起動時に行うことができ、「authorization_endpoint 失敗した場合は再度行うことができる。 authorization_endpoint 値を短時間キャッシュに入れて、キャッシュの有効期限が切れた後、またはエラーが発生した後にリフレッシュすることができます。
ステップ 2: dashboard_url へのユーザーのリダイレクト
ユーザーが dashboard_url にナビゲートするときに、ブラウザーを以下の URL にリダイレクトして、アプリケーションにログインしているかどうか、およびアクセス・トークンを持っているかどうかを確認します。
<authorization_endpoint>?client_id=<your-client-id>&redirect_uri=<your-redirect-uri>&response-type=code&state=<your-resource-instance-id>
redirect_uri 値は、「 クライアント ID とシークレットの構成 」ステップでセットアップしたリダイレクト URL を参照します。
-
ユーザーがログインしている場合、即時にリダイレクトされます。 ブラウザは「
codeレスポンスパラメータと「state値を持つURIをリダイレクトするコールバックを行う。 -
ユーザーがログインしていない場合、ログインプロンプトが表示されます。 ログインに成功すると、ブラウザはコールバックを行い、'
codeレスポンスパラメータと'state値でURIをリダイレクトする。
ステップ 3: アクセス・トークン・エンドポイントの呼び出し
ユーザーが正常にログインした後、ステップ 2 で受け取ったコードを、アクセス・トークン・エンドポイントを呼び出してユーザーのアクセス・トークンと交換します。
トークン・エンドポイントへの POST 要求
アクセス・トークンを取得するには、以下のヘッダーとパラメーターを含める必要があります。
ヘッダー
Authorization: Basic [client id]:[client secret]Content-Type: application/x-www-form-urlencodedAccept: application/json
パラメーター
必須
grant_type=authorization_coderesponse_type=cloud_iamredirect_uri=[this parameter refers to the same URL from Step 1]code=[code from callback]
オプション
account=<account ID for the token>アカウントスコープのトークンを取得することを強くお勧めします。ip_address=<IP address of the user>ユーザーのIPアドレスがクライアントのIPと異なる場合は、それを渡します。
以下の POST 要求の例に含まれている必須ヘッダーとパラメーターを参照してください。
curl -k -X POST \
-u "<your-client-id>:<your-client-secret>" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "Accept: application/json" \
--data-urlencode "grant_type=authorization_code" \
--data-urlencode "response_type=cloud_iam" \
--data-urlencode "account=<account ID for the token>" \
--data-urlencode "ip_address=<IP address of the user>" \
--data-urlencode "code=<code-from-the-callback>" \
--data-urlencode "redirect_uri=<redirect_uri>" \
"https://iam-region2.cloud.ibm.com/identity/token"
アクセス・トークン応答
前のタスクで POST 要求を実行依頼すると、アクセス・トークンを含む応答を受け取ります。
以下の正常なアクセス・トークン応答の例を参照してください。
{
"access_token": "eyJraWQiOiI......XmpBTIDdR5w",
"refresh_token": "SPrXw5tBE3......KBQ+luWQVY=",
"token_type": "Bearer",
"expires_in": 3600,
"expiration": 1473188353
}
サード・パーティー・サービス・プロバイダーの IAM トークン・スコープ設定
あなたのクライアントIDで作成されたユーザアクセストークンは、あなたのサービスAPIのみにアクセスするために使用することができます。 このトークンを使用する他の'IBM CloudAPIへのリクエストは、たとえユーザが適切なポリシーを設定していたとしても、アクセスを拒否される。
サード・パーティー統合の一部として、ユーザーの目的を実現するのに必要な最小アクセス・スコープをトークンが持っていることを確認するために、トークンのスコープ指定が使用されています。 これを可能にするために、IAM トークンのアクセス権限は、トークンを作成したクライアント ID に基づきます。