【読書メモ】「成長する企業はなぜ SSO を導入するのか」

この記事は個人ブログと同じ内容です

---

最近チームのメンバーが誕生日で、よくバラエティ番組で流れる曲「Happy Birthday - Stevie Wonder」が頭から離れない sekitats です。

今月は個人的に認証について学ぶ月間で、本を3冊読みました。認証周りわからんことばかりだったので。

OAuth については、別記事を書いてみたのでそちらも興味があれば読んでみてください。

ratatatat30.hatenablog.jp

2冊目の Auth0 + Nuxt + Rails のデモも試した。

本記事は3冊目「成長する企業はなぜ SSO を導入するのか」の要約となります。
引用元：日本ヒューレット・パッカード株式会社 (著) . 『成長する企業はなぜSSOを導入するのか』. 日経BP, 2017

なぜ、この本を読んだのかというと、SSO に関する本を amazon で検索したら、本書しかなかったからです。（あとはミリタリーバックパック）

認証はすでに経営課題

以下のような企業における認証の課題があげられている。

社員のパスワードの使い回しによってパスワード盗難リスクが高まる。企業側の危機意識が低い

厳しすぎるパスワードポリシーが返って生産性を低下させる

個々の業務システムの担当者は、自分が担当している業務システムだけを考えて対策を立ててしまう傾向にある → サイロ化

サイロ化した中で認証強化してもそれは「部分最適化」でしかない。「全体最適化」とは程遠い。

※ サイロ化：企業内にある部門が他部門との連携をすることなく、自らの業務の部分最適化のみを優先するようになった状態をいう。元々サイロとは穀物などを貯蔵するタンクのことだが、英語圏では「窓がなく周囲が見えない」という意味も含んでいる。

出ました。サイロ化。大規模になればなるほどサイロ化の弊害は大きくなっていく。

企業経営にまで影響を与える問題となっているということ。

パスワード認証の課題

ユーザーの本人確認を行う認証にも問題は多い。

他人に知られた場合になりすましが可能

安易なパスワードの場合類推や解読が容易

忘れたり間違えたりしやすい

複雑なパスワードは記憶が困難

パスワードの使い回しにより、安全性が低下

パスワード認証は、「知られない」、「推測されない」、「同じものを使い続けない」、「同じものを使わない」といった「努力」をユーザーに強いていて、その「努力」には限界がある。

パスワード認証を強化する他要素認証（ワンタイムパスワード、生体認証）も導入が難しい。

そんな、企業の課題、ユーザーの課題を SSO（シングルサインオン）が解決してくれると言うてます。

SSO 導入メリット

SSO とは、業務システムで個別に行っている認証を一元化し、ユーザーがいずれかのシステムを利用する際に認証を一度行えば、連携している全てのシステムが利用できるようになる。ユーザー ID,パスワード、ユーザー属性などのユーザー情報の管理や、問い合わせ対応の負荷が軽減される。

SSO が導入されるということは、入口が１カ所で管理されるということ。唯一の入口に防犯対策をを一本化できる。情報漏洩の防止策として SSO は役に立つ。

新規に導入する業務システムだけでなく、既存の業務システムにも SSO は効果を発揮する。既存の業務システムで管理されているユーザー情報に大きな変更を加えないため、導入も用意で短期間かつ少ない労力で導入できる

導入によってユーザーの利便性が向上するだけでなく、認証に関する管理の負荷も軽減される。

今後登場する未知のクラウドサービスの導入と行った変化にも柔軟に対応できる

各業務システム間のサイロ化の課題も、個々の業務システム担当者に大きな負担を強いることなく解決でき、IT 投資を効率化できる。

なんのことはない。一つのユーザーID・パスワードだけ管理できるようになれば問題は解決する。

SSO の 4 つの方式と特徴

方式には「リバースプロキシ方式」、「エージェント方式」、「クライアントエージェント方式」「フェデレーション」の 4 つ紹介されているが、最初の 3 つはオンプレミスでSSOを用意する方式。クラウドサービスを利用するものが「フェデレーション」。SSO = フェデレーションと捉えてしまってよい。

フェデレーションの仕組み

フェデレーションの仕組みの一つとして「SAML」や「OpenID Connect」といった。「標準規約」が用意されている。
SAML とは（Security Assertion Markup Language）の頭文字で、OASIS（Organization for the Advancement of Structured Information Standards）が定めた、クラウドサービスと企業の間で認証の連携を行う標準規格のこと。ほとんどのクラウドサービスがこの SAML に対応しており、クラウドサービスと認証の連携を行う場合は、SAML を利用することが多い。

OpenID Connect つまり JWT を使うこともできるのだろう。が、SSO では SAML を使う。

SSO（フェデレーション）はシンプル

本書では、フェデレーションの仕組みをパスポートの仕組みに例えて説明している。

パスポートは所持する本人の国籍の国で発行され、その発行には比較的厳格な本人確認、つまりユーザーの認証が求められる。ただし、一旦パスポートが発行されれば、渡航先の国ではパスポート自体が本人確認となる。入国の際にパスポート以外の本人確認の手続きは必要とされない。

f:id:sekilberg:20210713002050p:plain

IdP（IdentityProvider）で厳格な本人確認をする
IdP がアサーション（SAML = パスポート）を発行
アサーションがブラウザを介して SP（Service Provider = アプリケーション）に提示される
アサーションの正当性と信頼した IdP による発行かどうかを SP が確認する
SP がユーザーに利用を許可する

SAML のアサーションがパスポートと異なるのは、一度発行されたアサーションは特定の SP へのログインにしか使えないこと。SP 毎にアサーションを発行することが必要。（これは SAMLの仕様）

IdP による厳格な審査を通過していることとSPとの信頼関係によって成り立っているわけですね。

おまけ

いきなり、IdP（IdentityProvider）、SP（Service Provider）といった用語が出てきました。 OAuth（= 認可）の世界での登場人物は、リソースオーナー、クライアント、認可サーバー、リソースサーバーですが、OpenID Connect や SAML（= 認証）の世界になるとユーザー、SP、IdPといった用語になるところも混乱しがちなところです。（トークン→アサーションとか）

まとめ

そもそも技術書ではないし、SSO導入事例、オンプレ導入方法といった企業の経営者や情報システム担当者向けの内容だったので、OneLogin, okta などの IDaaS に関するお目当ての情報はなかった。
ただ、SSOの概要は理解できました。特にパスポートに例えた説明がわかりやすく、OAuth に比べずっとシンプルに感じました。（どう実装するかは別として。。）SSO=パスポートの仕組みということがわかっただけでも収穫アリですね。

SAML に関してはほとんど説明されていませんが、id token のような個人情報が XML 形式になっただけと捉えれば良いかと思います。

近い将来 SSO による生体認証が当たり前になって、フォームに E メール, パスワードを入力していたことが時代遅れになる未来もそう遠くないのかもしれません。