デジタル庁の認証ポリシーがOAuth/OpenID Connect/SAMLがぶ飲みで良い感じな件

デジタル庁のテックブログのクラウドチームの記事には、認証まわりの話がほぼ無い。アプリケーションを書く立場からすると、「ログインどうするんだよ？」となってしまう。しかし、デジタル庁が抜けていたわけではなく、むしろ認証まわりはガッチリ固めていた。クラウド化と同時展開しないでくれと言う感じではあるが。

「地方公共団体情報システム共通機能標準仕様書」に方針がしっかり書いてあるが、「地方公共団体情報システム認証機能・ファイル連携機能に関するリファレンス（推奨指針）ガイド」の方が端的であった。

私が理解したところでは、まず、

1. 地方公共団体は、それぞれ認証認可サーバを一つコンテナ化して稼動

させる。サーバーソフトウェアはKeycloakが推奨されている。なお、Keycloakはコンテナイメージで配布されているぐらいなので、コンテナ化は容易だ。コンテナ化しておけば、オンプレミスでも、クラウドでも、稼動させやすい。

認証認可サーバの使い方もはっきり規定されている。

2. 職員がアプリケーションを使うときの認証は、OpenID Connect
3. 職員がログインしないで動くプログラムが、データ連携等用のWeb APIを利用するときは、OAuth 2.0/client_secret_jwt
4. 閉系ネットワークで、バックチャネル（e.g. アプリケーションと認証認可サーバの間の通信経路）が遮断されている（ファイル連携などの）場合は、SAML

を用いる。こう書かれているわけではないが、認証方式の特性から考えて、こう使い分けると想像できる。

Keycloakはこれら3つの機能を有しているので、認証認可サーバを動かすこと自体は容易だ。Windows Serverの認証機構（Active Directory）と連携することもできる。ADでシングルサインオンを既に実現しているところは、運用開始も容易だ。

導入の課題になるのは、まずはアプリケーションの対応。オープン系であればログイン部分の変更で済むのでそうでもないが、汎用機の場合は、Windows端末に代理認証アプリをインストールするような方法が要るかも知れないし、それでも対応できないかも知れない。次に問題になりそうなのは、認証認可サーバをどう公開するか。API連携をするためには、外部のアプリケーションが認証認可サーバにアクセスできなければならない。地方公共団体によっては気が重いはずだ。最後に、もしかしたら地方自治体ごとのアカウント管理方針を改める必要がある。部署ごとに同じアカウントを使いまわすような前近代的なことは改めてもらう必要がある。さすがに無くなっているとは思いたいが。しかし、順次対応していけば、システム更新もあるし、いずれ完遂できる。

パスワード漏洩などのセキュリティー上のリスクを減らしつつ、外部とのデータ連携を容易にすることができるのが、御利益になる。シングルサインオンを導入していない組織であれば、アカウント統制が一元管理で容易になり、あちこちにIDとパスワードを入れなおさなくて済むようにもなる。

デジタル庁はさらに、

5. 国民や住民の認証は、デジタル認証アプリを使ったOpenID Connect

と、認証ポリシーを定めている。デジタル認証アプリは、OAuth 2.0/OpenID Connectの認可プロセスの認証部分を担当するもので、政府が認証認可サーバを運営しサービスを提供している。デジタル庁に利用申請して認められれば、民間サービスでも使うことができる。徐々に本人確認は免許証や保険証から、個人番号カードに移行していくのであろう。OAuthを使ってTwitterに自動投稿するアプリをつくってフォロワーにうざがられていたあの日から、随分遠くまで来た感がある。

ところで、これらの認証方式は、システムのクラウド化をしなくても導入できる。