Fiware KeyRock SCIMのAPIのバグ：_check_allowed_to_get_and_assign（）が予期しないキーワード引数「ユーザー名」我々はFIWARE IDM、両方のキーストーンとホライズンを使用したい

Question

を得ました。具体的にサインアップ時に我々は、最新のを使用してキーストーンとホライゾンがインストールされている

アプリケーションのユーザーを組織

にそのユーザーを追加し、ユーザー

を作成認可

• にしたいですドッカーハブのKeyRockドッカー画像（https://hub.docker.com/r/fiware/idm/）。 （http://docs.keyrock.apiary.io/#reference/scim-2.0）SCIMのAPIドキュメント：

  注：KeyRockのWebインターフェイスは、スペインなどのような地域でクラウド団体、コミュニティのユーザーを作成します

  ので、私は作成してユーザーを認証するためにSCIMのAPIを使用しようとすることにしましたSCIMコールがKeyRockサーバポートにあることを意味しますが、キーストーンサーバポートで利用可能です。 の代わりにhttp://[keystoneサーバー]/v3/OS-SCIM/v2/Usersの代わりにSCIMのマニュアルが明確になります。application_id = app1のアプリケーション（SCIMコンシューマ）があるとします。このアプリケーションは、Horizo​​nフロントエンドを使用するか、

  コールを使用して作成されます。私はアプリケーションを作成する2つの方法の違いを認識していませんが、まだ後者を試していません。これは1回限りの操作なので、Webインターフェイスを使用してアプリケーションと関連する役割を作成しました。

  ので、我々は= ROLE1

  アプリケーションのための役割を持っていると私は我々のアプリケーションのために彼を承認しようとすると、我々はのuser_id = user1の

  を生み出すSCIM

  POST /v3/OS-SCIM/v2/Users/ 
  

  を使用してユーザーを作成します

  PUT /v3/OS-ROLES/users/user1/applications/app1/roles/role1 
  

  次のエラーが表示されます。

  { 
      "error": { 
      "message": "_check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'", 
      "code": 400, 
      "title": "Bad Request" 
      } 
  } 
  

  次のステップは、

  POST [KeyStone server]/oauth2/token 
  

  を用いKeyRockを通じてリソース所有者トークンを取得することであろう。しかし、それはなぜなら、上記のエラーの議論の余地があります。 USER1とKeyRockのユーザーインターフェイスへのログイン

  はエラーを与える： は、「あなたはすべてのプロジェクトのために許可されていません。」これは、user1が組織に対して承認されていないためと考えられます。 user1は他のユーザーやKeyRockユーザーインターフェイスの管理者には見えないので、必要な権限を割り当てることはできません。

  user1にはどのような役割があり、KeyRockが満たされるように割り当てるべきですか？

Answer 1

あなたの問題を深く見てみると、新しいユーザーのデフォルト組織がないとに関連する可能性があることが判明しました。 SCIM APIユーザエンドポイントへのリクエストではユーザだけが作成されるはずですが、KeyRockユーザは内部から外部からは見えないデフォルトの組織を持つことが確実です。この組織を自動的に作成するのも理にかなっているので、KeyRockのSCIMコントローラでこれを担当するいくつかの改良を加えました。 our GitHub repositoryの変更を見ることができます。

私自身は、これは同じ流れに従うことによって、あなたの問題を解決する必要があることを確認しました（X-Auth-Tokenヘッダの値が管理者トークンがあることに注意してHostヘッダは、あなたのキーストーンエンドポイントでなければならないこと）：

1. SCIMのAPIを介してユーザを登録します。次の応答を返します

   POST /v3/OS-SCIM/v2/Users HTTP/1.1 
   Host: localhost:5000 
   Accept: */* 
   Content-Type: application/json 
   X-Auth-Token: 6bd914d9976c448a98b83ccaf5931c4e 
   Content-Length: 55 
   
   { 
       "userName": "foo@foo.bar", 
       "password": "foobar" 
   } 
   

   ：

   HTTP/1.1 201 Created 
   Vary: X-Auth-Token 
   Content-Type: application/json 
   Content-Length: 276 
   
   { 
       "userName": "foo@foo.bar", 
       "urn:scim:schemas:extension:keystone:2.0": { 
       "domain_id": "default", 
       "default_project_id": "c590cea2b37c4f1c9ca94a015837cde9" 
       }, 
       "active": true, 
       "id": "foo-foo-bar", 
       "schemas": [ 
       "urn:scim:schemas:core:2.0", 
       "urn:scim:schemas:extension:keystone:2.0" 
       ] 
   } 
   

2. 彼らに役割role1を割り当てることにより、アプリケーションapp1用に新しく作成したユーザー認可：

   HTTP/1.1 204 No Content 
   Vary: X-Auth-Token 
   Content-Length: 0 
   

3. ：今度は次の成功応答を返す

   PUT /v3/OS-ROLES/users/foo-foo-bar/applications/app1/roles/role1 HTTP/1.1 
   Host: localhost:5000 
   Accept: */* 
   Content-Type: application/json 
   X-Auth-Token: fd817b31444141a7a8a15d6d6afd2078 
   

   をこの後、私は最終的にを得ることができたリソースオーナーOAuth2トークン（要求者のAuthorizationヘッダーにOAuth2の資格情報が含まれていますapp1）。

   POST /oauth2/token HTTP/1.1 
   Host: localhost:8000 
   Accept: */* 
   Authorization: Basic 12345678abcdefgh= 
   Content-Type: application/x-www-form-urlencoded 
   Content-Length: 56 
   
   grant_type=password&username=foo@foo.bar&password=foobar 
   

   とトークンが最後であるが返さ：

   Iロビン

   HTTP/1.0 200 OK 
   Vary: Accept-Language, Cookie 
   Content-Type: application/json 
   
   { 
       "access_token": "JYjCV2H8QNakRPUqqdoAHZmpmD0vgQ", 
       "token_type": "Bearer", 
       "expires_in": 3600, 
       "refresh_token": "snnS8djsYw62aUtl9Szk9BBqti36jF" 
   }