OktaのSAML証明書をOkta Workflowsを用いて指定年数で発行する方法

はじめに

こんにちは、IT本部IT戦略部テクニカルオペレーショングループの利根川です。

DeNAではIdP（アイデンティティプロバイダー）としてOktaを長く利用しており、現在400ほどのアプリがOkta連携されています。
また、そのうちの殆どがSWA、SAML、OIDCによるシングルサインオン設定されています。
運用を長く、そして規模を大きくしていく中で、様々なケースに遭遇します。

今回は、運用の中で実際に対応した特殊事例をもとに、Okta WorkflowsによるSAML証明書の発行作業のローコード運用をご紹介できればと思います。

この記事の流れ

SAML証明書のOkta Workflowsによる発行について以下の章に分けて記載します。

Oktaで発行されるSAML証明書(X.509証明書)とは
サービス側の制約
Okta公式の手順
Okta Workflowsとは
フロー記述方法
まとめ
さいごに

Oktaで発行されるSAML証明書(X.509証明書)とは

Oktaは日本語の技術記事があまり多くないので、まずはOktaでX.509証明書がどのように発行されるかをご説明します。 X.509証明書はSAML2.0プロトコルによる認証方式を選択すると、各アプリのSign Onタブの下部のSAML Signing Certificatesに自動的に作成されます。 X.509証明書は接続先のサービスにもよりますが、概ね以下の2パターンで接続先サービスに提供されます。

証明書ファイル自体をアップロードする（サーバー内に設置する）方法
Oktaの証明書URLを接続先サービスに入力する方法

いずれにしても、証明書が発行されると下記のようなコンソールで確認することができます。

上記は検証環境なこともあり、TypeがSHA-1となっていますが、SHA-1は脆弱性があるため、現在はSHA-2(SHA256)を用いています。
ご覧の通り、Created、Expiresと作成日、有効期限が表示されていますが、Actionsを選択しても、下記のように証明書のダウンロードかメタデータを確認することしかできません。

また、OIN（Okta Integration Network）の設定によっては、単純にカタログからアプリ追加をするとSHA-2の証明書が発行されないものもあります。
その場合、Generaet new Certificateを押すと、以下のようにステータスが無効化された状態で、SHA-2の証明書が作成されます。
ただし、現在の挙動では有効期限が一律作成日から10年となっており、指定することはできません。

サービス側のSAML証明書に対する制約

次に、Oktaとサービス（各クラウド製品）との連携をするにあたり、一部のサービスではこのX.509証明書の 年数が一定以上の期間の場合は「利用できない」 とするサービスも存在します。

今回の記事を書くきっかけになった特殊事例では、制約として有効期限が10年より短いものである必要があったため、UIでは発行対応ができませんでした。

Okta公式の手順

公式ではOkta APIで実行する手段のみ書かれています。

https://developer.okta.com/docs/reference/api/apps/#application-key-store-operations

curl -v -X POST \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: SSWS ${api_token}" \
-d '{
}' "https://${yourOktaDomain}/api/v1/apps/0oad5lTSBOMUBOBVVQSC/credentials/keys/generate?validityYears=2"

変数となっているのはapi_tokenとyourOktaDomain、そしてアプリケーションのGlobal IDです。
APIトークンはSecurity＞API＞Tokens＞Create tokenから発行できます。
URLを分解してみましょう。

https://
${yourOktaDomain}/　←利用しているOktaのドメイン（xxxxx.okta.com）
api/
v1/
apps/　←アプリを意味、User関連のAPIならusers,Group関連のAPIならgroupsになります
0oad5lTSBOMUBOBVVQSC/　←アプリ毎に変わるGlobal IDです。アプリの設定画面のURLに含まれているものと同じです。
credentials/　
keys/
generate?validityYears=2　←期限を2年で生成する

つまり、最後を5に変えれば実行日から5年先を期日としたX.509証明書が発行可能です。
次の節では、上記の作業をOktaのUI上で済ませてしまう方法をご説明します。

Okta Workflowsとは

Okta WorkflowsはOkta Workforce Identity Cloud（Okta WIC）向けの、いわゆるOktaを軸とした「ローコード」のオートメーション機能です。
Okta Workflowsは、管理者でOktaにログインし、Workflows＞Workflows consoleからアクセスします。
Workflows Consoleに入ると以下のような画面に遷移します。

画面上部のFlowsを押すと、下記画面に移ります。
Default Foldersがありますが、ここは任意に作成して問題ありません。

New Flowボタンを押して、フローの作成に入ります。

フローの作成画面では、各種ローコードアプリ同様、「トリガー」と「その時のアクション」や「機能」を呼び出して設定します。

Add app actionでは様々なクラウド製品を参照することができます。

たとえばGoogle Workspaceを選択してみましょう。
下記のようにCreate Userなど様々な機能が直接指定できるようになっています。

Add functionでは具体的に実行する処理を指定します。

作成したフローはExportし、別のOkta環境でImportすることも可能です。
例えば「グループ会社各社でOkta環境が分かれているが処理は共通化したい」といった場合にこの手段は使えます。

フロー記述方法

今回は、API処理をOkta Workflowsで実行しますが、至ってシンプルです。
利用しているのはFunction「Compose」とapp action「Okta>Custom API Action」のみです。

それでは1から作ってみましょう。

Add functionからText＞Composeを選択します。

作成されたComposeアイテムは以下のように空欄に

Type text and drop fields hereの欄に、発行するためのAPIを記入します。

/api/v1/apps/{アプリケーションID}/credentials/keys/generate?validityYears={作成する年数}

※実際のサンプルは
/api/v1/apps/0oaXXXXXXXXXXXXXX/credentials/keys/generate?validityYears=5
という表記です。

{}の中身は対象によって変化します。

次に、Add app action からOktaのCustome API Actionを選択します

以下のフィールドが生成されます。

複数のOkta環境を持ち、Okta間を跨いで連携させたい場合は、OIDCの設定を行うことで、上の ✔Okta のところを選択すると別環境を参照することもできます。

Choose an optionから実行したいリクエストを選択します。

今回はOktaのサーバーに対し、証明書を新規発行するリクエストを送るので「POST」を選択します。

Saveを押すと、下記のようにInput/Outputの内容が出てきますが、そのままSaveします。

Saveすると、Relative URLが*（必須項目）として赤字表記されます。

先に作ったComposeのOutputをドラッグし、Okta Custom API ActionのRelative URLのところにドロップすると、以下のように紐づいたことが分かります。

あとはフロー自体をSaveし、Testを実行すると、対象のアプリに証明書が作られます。

Testといいながら実体はRunであり、CustomAPIがComposeで入力された値でRequestを作成し、OutputとしてRequestをOktaのサーバーにHTTP Responseとして流しています。
対象のアプリのSign Onタブ＞SAML Signing Certificatesに作られていることを確認してください。

ただし、作られた証明書はそのままでは使えません。
通常のサーバー証明書（SSL証明書）などと同様に、置き換え作業が必要になります。
置き換え作業は以下の手順で行います。

1.新規発行した証明書をサービス管理者に提供します
2.サービス管理者は証明書をサービスにアップロードします
3.Okta管理者は発行した証明書をActionからActivateします

注意事項

※旧証明書は新規発行した証明書をActivateした時点でInactiveとなりますが、失効したわけではないので再利用することは可能です
※X509証明書はいずれか1つしかActiveにできません

証明書を複数保持可能なサービスの場合はOktaのActiveな証明書を切り替えるのみなのでダウンタイムは発生しませんが、一つしか持てない場合は一時的にダウンタイムが発生しますので、ご注意ください。

まとめ

いかがだったでしょうか？
Okta Workflowsを用いてローコードでSAML証明書を発行する手順を解説させていただきました。
証明書管理はどのサービス管理者も行っているかとは思いますが、年々期間が短くなってきていますし、必要性が高いため管理工数が膨大になっています。

そこで、さらなる活用方法としては

トリガーを毎月実行にし
アプリを走査して失効期限を確認し
現在有効な証明書の失効期限が○カ月以内なら証明書を作成し
SlackやGmailに作成したことを通知する
ということをすれば、更新漏れに伴う証明書失効でSSOが出来なくなる、といったことが避けられます。

ただし、OktaのAPIはアプリを参照する1回のリクエストで走査できるのは最大20アプリまで、という上限が設けられています。
400アプリある弊社では20回ループさせる処理が必要になりますが、その仕組みについてはいくつかのフローを組み合わせるMain flow+Helper flowという構成になるので、別途ご紹介できればと思います。