鍵の歴史は古く、世界で最も古い鍵はエジプト錠と呼ばれる木製の鍵で、紀元前2000年ごろには存在していたといわれ、壁画にも描かれている。それ以前は紐を複雑な結び目で結んで鍵の代わりとしていた。
⇧ 昔から鍵があったとは、隣人は信頼できないってことっすか。
その一方でエールの新製品Linusロックはさらに進化しており、物理的な鍵はありません。ドアの外側に設置されているタッチセンサー式のパネルには250種類の暗証番号を設定できるようになっています。それによって、子どもや友人、そして隣人に特定の暗証番号を割り振り、人の出入りを記録できるというわけです。
⇧ セキュリティー的にどうなんすかね？
情報通信における認証はと言うと、
技術史から見ると18世紀以降に急激に発展した電気の利用の、情報通信への応用では、同時に暗号化の要請も重要であった。エニグマのような、電気回路の接点網の断続によって信号をスクランブルするこの時期の暗号は、次に来たコンピュータの時代の暗号の、いくつかの意味で先駆となっている。
「ケルクホフスの原理」は、以上のような古典から近代までの暗号と、現代の暗号とを隔てている原理である。そして、1940年代にシャノンらによって基本的な法則などが確立された情報と通信の理論による暗号に関する定量的な議論は、こんにち、暗号の安全性を検討する基本となっている。また特に現代の暗号の特徴を示す一例としては、RSAのような復号と暗号化に非対称の鍵を利用する暗号方式は革命的であった。
⇧ 1940年代が始まりなんですかね？
と言うと、まだ、100年の歴史はないと。
By the way、職場の方に、SAML認証ってものの存在をご教授いただいたので、調査してみました。
レッツトライ～。
SAML（Security Assertion Markup Language）って？
Wikipedia さ～ん。
Security Assertion Markup Language（セキュリティ アサーション マークアップ ランゲージ、略称SAML、読み： sam-el）はOASISで標準として策定されたマークアップ言語で、主にシングルサインオンやID連携で利用されている。メッセージの送受信にはHTTPやSOAPが使われる。
⇧ OASIS の標準ですと。
OASIS って？
OASIS（Organization for the Advancement of Structured Information Standards, 構造化情報標準促進協会）は、e-ビジネス標準の開発、統合および採用を推進する非営利国際コンソーシアム。有力なコンピュータと通信に関する標準化団体の1つ。
⇧ コンピューターと通信に関する標準化団体なんですって、知らなんだ。
⇧ SAML は、「AuthXML」と「S2ML」 をガッチャンコ（合わせた）した規格なんだそうな。
そんな、SAMLは、シングルサインオンで利用されてるんだそうな。
シングルサインオン（SSO：Single Sign On）とは？
Wikipediaさ～ん。
シングルサインオン（英語：Single Sign-On、略称：SSO）は、一度のユーザ認証処理によって独立した複数のソフトウェアシステム上のリソースが利用可能になる特性である。この特性によって、ユーザはシステムごとにユーザIDとパスワードの組を入力する必要がなくなる。
⇧ 複数システムの認証を1回で済ますことができるそうな。
イメージ的には、
⇧ 上記サイト様のイメージ図が分かりやすいかと。
で、Wikipediaさんによると、イントラネットでのシングルサインオンには、
があるんだそうな。
クラウドサービスの活用が進むことで注目されている方式が、フェデレーション方式です。異なるドメイン間で、パスワード等の情報を渡すことなく、安全に認証されたユーザーの情報を連携することで、シングルサインオン(SSO)を実現します。
⇧ 「SAML」は、「シングルサインオン（SSO：Single Sign On）」の中の「フェデレーション方式」という実現方法の1つですと。
そして、まさかの総務省が「情報流通連携のためのオープンなID連携プラットフォームにおけるプライバシー保護機能の高度化の研究開発」ってPDFを公開してた。
・https://www.soumu.go.jp/main_content/000256288.pdf
⇧ IdPに「SAML」や「OpenID」を、SPに実際のアプリケーションなんかが配置される感じですかね？
⇧ 「SAML」と「OpenID」の連携もできるんだそうな。
SAMLをサポートするOSS（Open Source Software）なSSO（Single Sign On）
SAMLをサポートするオープンソースソフトウェアなシングルサインオンとしては、
- OpenAM
- Keycloak
の2つが有名らしい。
ですが、
OpenAMは、現在は商用ソフトウェアとして提供されています。そのため、オープンソース版の開発は行われていません。日本国内では、いくつかのベンダーが引き続きオープンソース版を元にサポートを提供しています。しかし、このような状態がいつまで続くのかは未知数です。
それに対して、KeycloakはRedHatが開発を行っているオープンソースソフトウェアで、コミュニティも活発に活動しています。Keycloakは、まだOpenAMに比べると機能が少ないですが、将来性を考えると安心して利用することができます。
⇧ 上記サイト様にありますように、「OpenAM」については、オープンソースとしての将来性が怪しいのですと。
ちなみに、
しかし、OAuthでは、アクセストークンが誰に対して発行されたのかは仕様に規定されておらず、これにより“トークン横取り（authorization code interception attack）”による攻撃が可能になる他、規定があいまいであることからセキュリティに問題が生じてしまいます。
このような問題を抱えるOAuthを補完するシンプルで安全な認可の仕様として「OpenID Connect（以下、OIDC）」が注目されています。OIDCはOAuthによる認可に加え、「ID Token」という検証可能なトークンを利用しています。ID Tokenには「JSON Web Token（JWT）」という改ざん耐性のある仕組みが用いられており、サービス間で認証済みユーザーやトークン発行対象などといった認可情報を安全に共有できるようになります。
⇧ 「OAuth」は脆弱性があるみたいなんだけど、「OAuth」ってバージョン2である「OAuth2」も出てた気がするけど、2も脆弱性あるのかな？
例えば、スマートフォンアプリケーションがリダイレクト URI にカスタムスコープを使っている場合に起こりうる「認可コード横取り攻撃 (authorization code interception attack)」の対応策は RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) (図解) として策定されましたが、その仕様の Abstract は「OAuth 2.0 public clients utilizing...」という書き出しとなっており、OAuth 2.0 を前提とした仕様であることが分かります。
OAuth 1.0 に対しては、このようなセキュリティー仕様が追加されることはないので、コールバック URL にカスタムスコープを使用している OAuth 1.0 スマートフォンアプリは、認可サーバーが独自仕様を策定・実装しない限り、認可コード横取り攻撃に対して脆弱性を抱えたままとなります。
⇧ 上記サイト様によりますと、「認可コード横取り攻撃 (authorization code interception attack)」については、「OAuth2」で対応策が策定されたそうな。
ただ、
そして最も重要なことは、「OAuth 2.0はUser IDの取得方法やProfile APIの仕様については定めていない」ということである。OpenID Connectでは、これらを標準化しているのである。
⇧ 上記サイト様によりますと、「User IDの取得方法」や「Profile APIの仕様」が定まってないんだそうな。
SAML が Spring Security に同梱されてる？
Javaだと、Springで、
SAML 2 サービスプロバイダー、SP（依存パーティ）のサポートは 2009 年から独立したプロジェクト (GitHub) として存在していました。
2018 年に、サービスプロバイダーとアイデンティティプロバイダー (GitHub) とスタンドアロンライブラリの両方の更新された実装を作成する実験を行いました。Spring Security チームである私たち Spring Security は、慎重かつ長期にわたる審議の結果、その努力を中止することにしました。この取り組みにより、そのスタンドアロン 1.0.x ライブラリの代替が作成されましたが、別のライブラリの上にライブラリを構築する必要はないと感じました。
代わりに、コア Spring Security (GitHub) の一部として SAML 2 認証のフレームワークサポートを提供することを選択しました。
⇧ 「Spring Security」に同梱されたらしい。
時間が取れたら、SAML（Security Assertion Markup Language）認証を試してみますかね。
今回はこのへんで。
