API Connect v10 での相互TLS認証検証② - アプリケーション認証

# はじめに

こちらの記事：[API Connect v10 での相互TLS認証検証① - トラストストア認証](https://qiita.com/ryota_n/items/997550f6525002d7559f)では、API ConnectがTLS認証のサーバーサイドとなり、トラストストアに登録されているクライアント証明書を使用して、相互TLS認証を実装する例を紹介しました。この場合は、API Connectのサーバー管理者がクライアント証明書を設定する必要があります。

この記事では、前回のようにトラストストアを使用せずに、API利用者のアプリケーションに設定したクライアント証明書を利用して相互TLS認証を設定する例を紹介します。この場合は、API利用者がセルフサービスでクライアント証明書を登録することができます。


# 事前準備

クライアント証明書の作成は前回と同様なので割愛します。


# サーバー設定

## ゲートウェイ・サービスが使用しているTLSサーバー・プロファイルの設定

アプリケーション認証の場合でも、Cloud Managerからゲートウェイ・サービスのAPIエンドポイントに対して相互認証を有効にする設定は必要になります。
手順は前回と同様ですが、今回は、デフォルトのサーバーTLSプロファイルを変更しています。トラストストアは使用しませんので、新規登録・設定は不要となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/cb80957d-7f7c-fc06-4fb8-635bf793af50.png)

## アプリケーション設定

API Managerから新規APIを登録します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/f44540bc-bc3f-ddd8-f6be-6f44c28240b2.png)




ゲートウェイタブからアプリケーション認証ソースを選択し、「追加」をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/9565a93b-b992-93b2-d819-08b603e551bd.png)

認証対象として、ヘッダー（要求時のHTTPヘッダー）、または、tls-cert（クライアント証明書）を選択できます。両方追加することも可能です。検証は、前回同様、tls-certで認証を実施します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/9bd37fa1-df11-6240-2ffc-f79daca2e11f.png)


アプリケーション認証を有効化します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/536168d5-660b-a723-b5e3-256b794729ad.png)

ゲートウェイおよびポータルの設定からアプリケーション認証設定を確認できます。
ヘッダーを使用する場合は、こちらでHTTPヘッダー名をカスタマイズすることができます。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/6ce0244e-821c-d5ad-b4fd-3dea6934c11d.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/5822a7b0-d1af-3648-6de3-feadfc7e61b9.png)

以上で設定は完了です。

# 動作確認

## クライアント証明書がない場合

そのまま、テスト機能からAPI呼び出しをすると以下のように401エラーとなります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/0fdf2b00-027f-30d6-630e-5b01403075a1.png)

## クライアント証明書を登録する場合

カタログに登録されているアプリケーションにクライアント証明書をアップロードすることができます。
以下の例では、カタログのテスト用のアプリケーションに、前回の事前準備で作成したクライアント証明書（client_certificate.pem）を登録しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/62296315-abed-a4fc-c131-cb3187804976.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/403443/fffb32f8-0cc8-370e-7e5e-45f9fcdd5a88.png)

Curlからクライアント証明書を利用して、API呼び出しを実施することができます。

```
$ curl -ki  -E client_certificate.p12:admin \
--url "https://ademo-gw-****-cloud/ddd-demo-test/sandbox/v1/app" \
--header "x-ibm-client-id: c04e0373be16a5888e2c14996****"
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
User-Agent: curl/7.79.1
Accept: */*
X-Client-IP: ***.**.**.***
X-Global-Transaction-ID: 242b99606229929000258ae2
Date: Thu, 10 Mar 2022 05:54:24 GMT
Content-Type: text/plain
uber-trace-id: ba38c2f3921d7add:ba38c2f3921d7add:0:1
uberctx-consumerAppName: sandbox-test-app
uberctx-consumerOrgId: e3c57a75-bec1-4ccf-995f-e5994b11f92a
uberctx-productName: app-auth-api-auto-product
uberctx-responseSize: 18
uberctx-productId: ba9a7c25-78fc-411d-be8f-95d5fafe62b8
uberctx-consumerOrgName: sandbox-test-org
uberctx-clientId: c04e0373be16a5888e2c149964e04556
uberctx-httpRequestMethod: GET
uberctx-apiNameVerAggKey: app-auth-api%7C~%7C1.0.0
uberctx-httpRequestUrl: https%3A%2F%2F172.30.***.**%3A9443%2Fddd-demo-test%2Fsandbox%2Fv1%2Fapp
uberctx-gtidInternal: 242b99606229929000258ae2
uberctx-tid: 2460386
uberctx-tmz: %2B00%3A00
uberctx-domain: apiconnect
uberctx-httpVersion: HTTP%2F1.1
uberctx-appliance: ademo-gw-2
uberctx-objectName: apiconnect
uberctx-objectType: apigw
uberctx-apiName: app-auth-api
uberctx-httpRequestUri: %2Fddd-demo-test%2Fsandbox%2Fv1%2Fapp
uberctx-clientIp: 172.30.80.220
uberctx-providerOrg: ddd-demo-test
uberctx-catalogName: sandbox
uberctx-isError: false
uberctx-planName: default
uberctx-planVersion: 1.0.0
uberctx-planId: app-auth-api-auto-product%3A1.0.0%3Adefault
uberctx-apiVersion: 1.0.0

{"app auth": "ok"}

```

以上です。