許可コンテキストの OpenID Connect 要求マッピング

IBM® Verifyの OAuth フローまたは Open ID Connect フローは、構成に基づいて許可アクションを実行できます。

フローには、これらのアクションを含めることができます。

  • アクセス・ポリシーを評価します。
  • 許可付与に保管され、ID トークンおよびイントロスペクション応答の作成に使用されるクレーム値を計算します。

コンテキスト要求マッピング・ルールは、許可要求から収集されるコンテキストを拡張するメカニズムを提供します。 例えば、許可要求にcontextIDというカスタム要求パラメーターを含めることができます。 カスタム・ルールでは、外部エンドポイントへの HTTP 要求にcontextIDを含めることができます。 この HTTP 要求の結果は、アンパックして、アクセス・ポリシーの評価および付与エンリッチ中に使用されるrequestContextに追加できるオブジェクトです。 r_attr_functions.html を参照

このルールは、単純な単一行の式言語を使用して作成することも、より高度な複数行の YAML ベースの文書として作成することもできます。 「複数行ルール実行機能」 を参照してください。

使用可能な入力オブジェクト

カスタム・ルールは認証後、許可前に実行されるため、使用可能な情報には、すべての可能なドメイン・オブジェクトが含まれているわけではありません。 これらは、以下のオブジェクトに限定されます。
HTTP 要求コンテキスト
ユーザーがVerifyにログインすると、要求マッピング・ルールで着信 HTTP 要求コンテキストにアクセスできます。 すべての OAuth 要求パラメーター (claimsscopeなど) は、このrequestContextで使用できます。 の requestContext 一般的な構造と使用方法については、 r_attr_functions.html の「 HTTP リクエストコンテキスト」のセクションに記載されています。
アクセスの場合、特定の値はrequestContextで事前計算されます。 通常、claims要求パラメーターは、以下の例のような JSON ファイルとして表されます。

{
    "id_token": { 
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    },
    "userinfo": {
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    }
}

この形式はアクセスが煩雑になる可能性があります。 requestContextで使用される鍵の形式は、claims_claimType_claimNameです。 claimTypeは、userinfoまたはidtokenのいずれかです (下線が欠落していることに注意してください)。 したがって、上記の例を使用すると、requestContext.getValue('claims_idtoken_claim_name')を使用してclaim_name値を取得できます。

同様に、scopeは、ストリング配列を作成するためにスペース区切り文字で分割されます。

ID ソースの資格情報
ユーザーがVerifyにログインすると、ID ソース資格情報属性がログイン・セッションに追加され、要求マッピング・ルールでアクセスできるようになります。
idsuserドメイン・オブジェクトは、ストリング・キーとストリング配列値を持つマップとして使用できます。 例えば、以下のとおりです。

{
  "realmName": ["cloudIdentityRealm"],
  "displayName": ["Jessica J. Hill"],
  "phone": ["+12324321234"]
}
r_attr_functions.html を参照してください。
その他の関数および演算子
マッピング・ルールでは、標準の演算子と関数を使用できます。 HTTP クライアントは、アウトバウンド要求を行うためにも使用できます。 サポートされるその他の機能には、ハッシュおよびタイム・スタンプが含まれます。 『 r_attr_functions.html 』の関連セクションを参照してください。

オブジェクトを返す

このカスタム・ルールは JSON オブジェクトを返すことが予期され、各 JSON プロパティーの値はストリング配列であることが予期されます。

以下の例は、戻りオブジェクトです。

{
   "ageRange": ["toddler"],
   "interests": ["sleeping", "other_misc_activities"]
}
この戻り値は処理され、後でrequestContext.ageRangeおよびrequestContext.interestsを使用して拡張ルール属性でアクセスできます。 拡張ルール属性は、{{requestContext.ageRange[0] != 'toddler'}}などのアクセス・ポリシーで、または許可付与で属性をマップするためにrequestContext.interests使用できます。

例 - ID トークンへのホビーの追加

以下のコードは、ID トークンにhobbiesを追加する要求マッピングのカスタム・ルールの例です。

statements:
- context: "contextData := hc.getAsJSON('https://jke.com/users/' + idsuser.getValue('uid'), { 'Authorization': 'apikey supersecretkey' })"
- return: >-
   {
      "hobbies": request.Context.interests.filter(x, x != 'other')
   }
この例では、ルールは外部ユーザー・エンドポイントを呼び出して、ユーザーに関する追加情報を取得します。 Verifyでのユーザーの認証済みセッションを表すidsuserオブジェクトを使用します。 最後に、ルールは応答からhobbiesを抽出します。
注: このルールは一切の検証を行わず、本番環境での使用には適していません。
hobbiesには、以下の方法でアクセスできます。
  • requestContext.hobbiesとして定義されたカスタム・ルールを使用して、my_hobbiesという名前の拡張ルール属性を作成します。 この属性のデータ・タイプは複数値ストリングです。
  • この属性の属性マッピングを追加しています。 OpenID を参照してください。Connectのイントロスペクト、IDトークン、およびユーザー情報のマッピングについて。