はじめに

なかなか暇が見つけられず投稿が滞っていましたが、やっと投稿できました。今回はOktaのPIV（Personal Identity Verification）認証を利用するために準備する証明書について記述します。

実は1年前に動作確認したことがあるのですが、最近確認したら仕様が変わっていました。
なお、OpenSSLを一度も叩いたことがないレベルから検証スタートしたため認識の甘い箇所があるかもしれません。その際は優しくご指摘いただけますと幸いです。

PIV認証とは

クライアント証明書を用いた認証方式と言ってしまうと伝わりやすいでしょうか？
Oktaでは2020年時点ではパスワードレス認証の実現手段として実装されており、実際にログインIDとパスワードの入力の代わりにクライアント証明書を用いてOkta認証することができます。

エンドユーザのPCに証明書を組み込む形となるため、特定デバイスからのみOkta認証させたいといったユースケースの「簡易的な」実装方式として利用する場合があるかと思います。

Fido2 MFAが利用できないブラウザ（IEとか）でも利用できるところは利点です。一部のネイティブアプリだと動かない場合があるのは注意ですが、そこはFido2も一緒ですね。

Oktaのドキュメントは大体このくらい。こんな証明書を準備してといった記述は今のところないんですよね。

Okta側の設定

まずはOktaの設定画面を見ていきましょう。
設定画面での設定箇所は非常に少ないので困ることはあまりないでしょう。

Certificate Chain

Certificate Chainには認証局の証明書を登録します。これはPEM形式のみなので注意。実はここの作成で一番ハマったのですが、中間認証局を挟んでいないとPIV認証が失敗します。
現在では2階層の証明書でもPIV認証可能となっております。

一年前に検証した際にはRoot証明書直の2階層でもよかったんですが、現在だとNGです。共有認証局で払い出されたサードパーティ製の証明書だとなりすましリスクがあることに対する対策でしょうか。

Cache CRL for

これはCRL（Certificate Revocation List）にOktaがアクセスする頻度ですね。
設定可能な値は1～72時間。短いほうがセキュリティは高いですが、PIV認証時にCRLのダウンロードを待たされる可能性があります。といっても数秒なのでそこまで影響はないかと。
逆に長くすると証明書の失効からOktaで認証できなくするためのリードタイムが大きくなるのでその分セキュリティは低くなります。

PIV認証をする場合、CRLをインターネット上に公開する必要があります。
HTTPでも大丈夫です。
ダウンロードに失敗した場合は、Okta上でエラーが出ます。

証明書ごとにCRLをチェックされるのでRoot認証局と中間認証局それぞれの失効リストを用意しておく必要があります。
クライアント証明書には、CDPの記述をします。

IdP Username

クライアント証明書がどのユーザに紐づけられているのかを示すための項目です。証明書のSAN値（subjectAltName）の設定がPIV認証では必須となっており、そのSAN値のフォーマットが何かをここでは設定します。

設定できる値は２つ
・idpuser.subjectAltNameUpn（UPN）
・idpuser.subjectAltNameEmail（email）

UPNはMicrosoftで利用されるOID（1.3.6.1.4.1.311.20.2.3）のもので、emailはRFC822です。
プライベート認証局を立ててやる場合はemailの方が設定しやすかったです。

クライアント証明書のSAN値には次の設定項目「Match Against」で登録する値と同じ値を設定するようにします。特殊な事をしていないならメールアドレスになるかと思います。

Match Against

SAN値と一致する値を格納するOktaの属性を設定します。大体の場合は「Okta Username」を選択します。
※ユニーク性が担保されているため

SAN値に格納されている値が「aaa@example.local」だった場合には、OktaにUsername「aaa@example.local」のユーザとしてログインします。

Okta Devices（Okta FastPass）との差別化

パスワードレス認証をしたい、デバイス制御をしたいという要件においては機能が被るところがありますが、Okta FastPassにはデバイスを制限することは機能のリリース時点ではできません。そのためOkta Devicesによるアプリケーションの認可制御も私物デバイスを制限することは難しいです。

FastPassのアクティベートにPIV認証を利用するという設計は、試してみたくはありますがエンタープライズ向けに展開するにはちょっと大掛かりな気がします。
というのもPIV認証には証明書の配布と失効、有効期限の管理など運用に影響を与える課題が大きいと思うからです。すでに配布するサービスを利用しているのであれば、Device Trustを利用したほうがより厳密に行えますしね。

とはいえPIV認証はSSOライセンスのみで実現できるので、一番の魅力はライセンスが安価であることだと思います。証明書の運用コストは発生しますけどね（笑）