登録チュートリアルのサンプル

この記事では、仮想スマート カードのセルフサービス登録を実行するために必要な手順について説明します。 自動承認の要求とユーザー設定の PIN を示します。

  1. クライアントは、ユーザーを認証した後、認証済みユーザーが登録できるプロファイル テンプレートの一覧を要求します。

    GET /CertificateManagement/api/v1.0/profiletemplates.
    
  2. クライアントは、結果の一覧をユーザーに対して表示します。 ユーザーは、"仮想スマートカード VPN" と UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1という名前の vSC (仮想スマート カード) プロファイル テンプレートを選択します。

  3. クライアントは、前の手順で返された UUID を使用して、選択されたプロファイル テンプレートの登録ポリシーを取得します。

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
    
  4. クライアントは、返されたポリシーの DataCollection フィールドを分析し、"Request Reason" というタイトルの単一のデータ収集項目が表示されることを示します。 また、クライアントは collectComments フラグが false に設定されているため、ユーザーに何も入力するように求められません。

  5. ユーザーが証明書を要求する理由を入力した後、クライアントは要求を作成します。

    POST /CertificateManagement/api/v1.0/requests
    
    {
        "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
        "type":"Enroll",
        "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
        "comment":""
    }
    
  6. サーバーは要求を正常に作成し、要求の URI をクライアントに返します。 /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5

  7. クライアントは、返された URI を呼び出すことによって、要求オブジェクトを取得します。

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
  8. クライアントは、要求の state プロパティが approved に設定されていることを確認します。 要求の実行を開始できます。

  9. クライアントは要求を調べて、 newsmartcarduuid パラメーターの内容を分析して、要求に既に関連付けられているスマート カードがあるかどうかを確認します。

  10. 空の GUID のみが含まれるため、クライアントは MIM CM でまだ使用されていない既存のカードを使用するか、プロファイル テンプレートが仮想スマート カード用に構成されている場合は作成する必要があります。

  11. 登録可能なプロファイル テンプレートの最初のクエリによって後者であることがクライアントに示されているため (手順 1)、クライアントは仮想スマート カード デバイスを作成する必要があります。

  12. クライアントは、プロファイル テンプレートからスマート カード ポリシーを取得します。 手順 3 で選択したテンプレートの UUID を使用します。

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    
  13. スマート カード ポリシーには、 DefaultAdminKeyHex プロパティのカードの既定の管理キーが含まれています。 スマート カードを作成するとき、クライアントはスマート カードの初期管理キーをこのキーに設定する必要があります。

  14. スマート カード デバイスを作成した後、クライアントはそれを要求に割り当てる必要があります。

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    
  15. サーバーは、新しく作成されたスマート カード オブジェクト () api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644への URI を使用してクライアントに応答します。

  16. クライアントは、スマート カード オブジェクトを取得します。

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644
    
  17. 手順 12 で取得したスマート カード ポリシーで 、その値を確認 することで、クライアントは管理キーを多様化する必要があることを認識します。

  18. クライアントは、提案された管理キーを取得します。

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/diversifiedkey?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9
    
  19. クライアントは、管理キーを設定するには、管理者としてカードに認証する必要があります。 これを行うには、クライアントは、スマート カードからの認証チャレンジを要求し、サーバーに送信します。

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/authenticationresponse?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9&challenge=CFAA62118BBD25&diversified=false
    

    サーバーは、HTTP 応答本文でチャレンジ応答を送信します。 16 進数のチャレンジ文字列を見つけて base64 に変換し、URL でパラメーターとして渡します。 URL は別の応答を返します。これは 16 進形式に変換する必要があります。

  20. サーバーは HTTP 応答の本文でチャレンジ応答を送信し、クライアントはそれを使用して管理キーを展開します。

  21. クライアントは、スマート カード ポリシーの UserPinOption フィールドを調べることで、ユーザーが目的のピンを指定する必要があることを示します。

  22. ユーザーが目的のピンをダイアログに入力すると、クライアントは手順 19 で説明したようにチャレンジ応答認証を実行します。唯一の違いは、分散フラグを true に設定する必要があるということです。

    GET /CertificateManagement/api/v1.0/ requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/authenticationresponse?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9&challenge=CFAA62118BBD25&diversified=true
    
  23. クライアントは、サーバーから受け取った応答を使用して目的のユーザー PIN を設定します。

  24. クライアントは、証明書の要求を生成する準備ができます。 クライアントは、プロファイル テンプレート証明書生成パラメーターをクエリし、キー/要求の生成方法を決定します。

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
    
  25. サーバーは、JSON でシリアル化された単一の CertificateRequestGenerationOptions オブジェクトで 応答します。 オブジェクトには、キーのエクスポート可能性、証明書のフレンドリ名、ハッシュ アルゴリズム、キー アルゴリズム、キー サイズなどのパラメーターが含まれます。 クライアントはこれらのパラメーターを使用して、証明書の要求を生成します。

  26. 単一の証明書要求がサーバーに送信されます。 さらに、証明書テンプレートが CA での証明書のアーカイブを指定する場合、つまり CA がキー ペアを生成してクライアントに送信するときに、PFX BLOB の暗号化を解除するために使用する必要がある PFX パスワードをクライアントで指定することもできます。 また、クライアントはコメントを追加することもできます。

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata
    
    {
       "pfxpassword":"",
       "certificaterequests":[
           "MIIDZDC…”
        ]
    }   
    
  27. 数秒後、サーバーは JSON でシリアル化された 1 つの Microsoft.Clm.Shared.Certificate オブジェクトで応答します。 isPkcs7 フラグを確認すると、クライアントは、この応答が PFX BLOB ではないことを学習します。 クライアントは、pkcs7 文字列をデコードして base64 によって BLOB を抽出し、それをインストールします。

  28. クライアントは要求を完了としてマークします。

    PUT /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
    {
        "status":"Completed"
    }