認証に関して調べた事を書き連ねてみる。

このページに関して

今後重要になると思い、認証や認可やSSOとかの知見を得ようとしています。調べてると用語がたくさん出てきてどれがどう関係しているのかこんがらがってしまっています。その為、自分が整理する為のメモページです。とはいえ、同じ感覚を持つ人も多いと思うのでその方たちの参考になればと思います。初心者タグつけているのはその為です。
間違っている点など多々あるかと思います。その際には指摘など頂けると有り難いです。

認証って何？

IT用語辞典によると、**認証とは、対象の正当性や真正性を確かめること。ITの分野では、相手が名乗った通りの本人であると何らかの手段により確かめる本人確認（相手認証）のことを単に認証ということが多い。**だそうです。

世の中ではどんな感じ？

大体のサービスでユーザーIDとログインパスワードを求められる形です。これは昔も今も同じかなと思います。
ただ、最近で世の中で流行っているのはシングルサインオンです。すなわちどこかのサービスでログインしておけば、それと連携しているサービスではログイン認証なしでそのサービスが使える機能です。
webサービスの世界では、FacebookログインとかGoogleログインとかが有名かと思います。

なんで他のサービスで認証するの？

基本的にセキュリティレベルを高める為かと思います。世の中で事件が色々あったかと思いますが、7Pay事件が知名度高いと思います。世の中の悪い人たちは一般の人が思いつかない様なエグい手法でセキュリティ情報、特に金銭が関わる情報を抜き出してきます。そんな悪い人たちに対応すべく色々な対策が施されていますが、それらはいたちごっこで、いつ今の仕組みを突破する悪人たちが出てくるか解りません。常にアンテナを高くして、情報収集して何かあったらすぐ対策しないといけないです。
そんな高度な事をサービス毎に管理するのは大変です。専門家に任せたい所です。また、認証の方法を統一しておくと、後述のシングルサインオンをしやすくなります。同時に認証の情報を保持する場所が少なくなり、危険性も少なくなります。

用語分類

各種用語がどの分類の単語なのか知っておかないとこんがらがり度合いがアップするのでその用語を分類します。

機能名

SSO（シングルサインオン）

一度ログインしたら、その情報を元に他のソフトウェアなどに再度ログインする必要が無い様にする為の機能です。その実現方法はいくつかあります。代行認証方式、リバースプロキシ方式、エージェント方式、SAML認証方式などがありますが、この記事では最後のSAML以外は触りません。

フェデレーション

SSOとセットで使われている事が多いかと思います。単語そのものの意味は連盟と出てきます。パスポートに例えて説明されている事が多い様に思います。国をサービス（と認証側）に例えると、国の間でお互いのパスポートを信頼する関係が確立されていれば、別の国に入国する時に、パスポートチェックで人物チェックが出来て入国できる、という感じです。

ディレクトリ・サービス

Wikiページに詳しく載ってます。コンピューターネットワーク上のリソース（人も）を一元管理して、検索などもできるサービスの様です。後述のMicrosoftのActiveDirectoryがデファクトになっているかとは思いますが、OpenLDAPなどのオープンのソフトウェアもある様です。こちらの機能を使用して前述のシングルサインオンが可能になります。

プロトコル名（やりとり規格）

OAuth

OAuthオフィシャルページがありますが、そのままだと良く解らないです。
色々解説ページあると思いますが、一番分かりやすい OAuth の説明が概要が良く解って助かりました。認証情報をやり取りする為の取り決めですね。

OpenID Connect

OAuth2.0プロトコルに認証機能を追加したプロトコルの様です。後述「プロトコルの比較」を参照ください。こちらのページも詳しく説明してくれています。
OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ

SAML

OASISによる公式ドキュメントはすごく細かい事まで書いてあって概要把握しずらいですが、こちらも認証をする為のプロトコルの様です。後述「プロトコルの比較」を参照ください。

LDAP

Wikiページに詳しくのってます。Lightweight Directory Access Protocolの略という事で、後述のActiveDirectoryなどのディレクトリサービスにアクセスする為のプロトコルの様です。

Kerberos

IT用語辞典によると、Kerberosは利用者の手元のコンピュータ（クライアント）からネットワークを通じてサーバにアクセスする際に、利用者の身元や本人確認を行う仕組みという事です。
こちらのページも解りやすいです。Kerberosを構成するのにLDAPが必要らしいです。
【図解】初心者にも分かるKerberos認証とspnegoの仕組み ～SSOのシーケンス,統合windows認証について～

重要ポイント：プロトコルの比較

こちらのページが解り易かったです。
SAMLとOAuth：比較と違い OpenID（OIDC）との関係
ポイントとしては、二つの同じ部分。

OAuthとSAMLはどちらも、相互運用を奨励し標準化するためのプロトコルです。

そして違ってる部分。

認証：このプロセスには、ユーザーのアイデンティティが関与します。SAMLは、家の鍵のようなものです。つまり、家に入る許可を与えます。
承認：このプロセスには、ユーザーの権限が関与します。OAuthは、その家のルールに若干似ています。つまり、家に入った後にできること/できないことを規定します。

そして、前述ページから参照できるページWhat is OpenID Connect?によると、OpenIDはOAtuhプロトコルの上に位置するプロトコルの様です。そして、前述の違いで、OAtuhが行っていない（訳ではない？）認証を行うという事だと思います。
こちらのページでも違いが分かりやすく書いてありました。OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い。
SAMLは認可が出来無さそうな雰囲気ですが、強力なSSOを実現するXML認証・認可サービス（SAML） を見ると認可機能も提供できそうです。

ちなみにプロトコル内で使用する各機能ポイントの用語も違うようです。

プロトコル	OpenID	SAML
ユーザーの認証を行うエンドポイント	OpenID Provider (OP)	ID Provider(IdP)
認証を利用するサービス	Relying Party (RP)	Service Provider(SP)

ソフトウェア・サービス名

Active Directory

認証認可専用のサービスではなく、本質的には会社などの大規模組織に属する人や組織やモノを管理する機能らしいです。Windows Serverに備わっているサービスという事です。
Active Directory（アクティブディレクトリ）をゼロから解説、関連用語もまとめて紹介
ActiveDirectoryの機能を使って、どの共有PCにもログイン出来るようになって、そのログイン情報を元に社内の使用可能なリソースを制限できるという事が出来る様です。

こちらのページがActiveDirectoryのやり取り信号を詳しく説明してくれています。認証時にはKerberosプロトコルを使い、その他情報取得にはLDAPプロトコルを使用する感じでしょうか。
【図解】Active Directory の認証プロトコルと起動/ログオンシーケンス

先にも紹介しました【図解】初心者にも分かるKerberos認証とspnegoの仕組み ～SSOのシーケンス,統合windows認証について～ によると、ActiveDirectoryに管理されているPCでは、統合 Windows 認証を使用して、それに対応したウエブページへSSO出来る様です。

Azure AD（Azure ActiveDirectory）

今さら聞けないAzure ADとは？オンプレミスのActive Directory（AD）との違い
公式ページ：Azure Active Directory と認証および同期プロトコルの統合 によるとSAMLやOpenIDを始めとする各種認証をサポートして統合出来るっぽいです。

Active Directory Federation service（AD FS）

Active Directory の認証情報（承認/認可も？）と他のサービスとの連携が出来る様にするサービス？以下のページが解りやすいかと思います。
AD FS の概要
前述の通り、せっかく社員のIDと組織管理が出来ているのでそれを他のサービスと連携できるようにしたというものかと思います。恐らくですが、営業部門の人には営業用の外部サービスをSSOで使えるようにするとかが出来そうです。

公式ページ：すべてのアプリを Azure AD と統合するための 5 つの手順 を見ると、Azure ActiveDirectoryに置き換える方向を推奨しているように見えます。

AtlassianをADFSと連携する設定
強力なSSOを実現するXML認証・認可サービス（SAML）
などのページによると、少なくともSAMLプロトコルを使用した認証が可能な様です。

LDAPサーバー

わわわIT用語辞典によると、LDAPプロトコルでディレクトリサービスを提供するサーバー、という事で、ActiveDirectoryもLDAPサーバーの一つという関係性の様です。

Kerberos 配布センター

Kerberosプロトコルで、ユーザーのアカウントを管理するサービス
先にも紹介しました【図解】初心者にも分かるKerberos認証とspnegoの仕組み ～SSOのシーケンス,統合windows認証について～ によると、

Kerberos の一番有名な実装は Microsoft Windows の Active Directory (以降 AD) です。

という事です。

グループ分け

沢山用語が出てきましたが、独断と偏見で機能群としてグループ分けすると以下の様になると思います。

• ActiveDirectory：オンプレミス環境でSSOを提供するサービスで、その構成要素にLDAP、Kerberosがある。
• Azure ActiveDirectory：ActiveDirectoryをクラウド化して、他のOpenIDやSAMLでも連携できるようにしたサービス。
• OpenIDベースサービス：OAuthと合わせる事で認証認可の両機能を提供する。Facebook、Twitter、Googleなどが提供している。
• SAMLベースサービス：OpenID以外のweb系Saasで使用されてる？前述引用のAtlassianはSAML認証している

勢力図調査

OpenID SAML - 総務省 によると

民間デファクトであるOpenID

との事で、Web系サービスではOpenID、それ以外はSAMLという勢力図なのかと想像します。
Azure ActiveDirectory はOpenIDともSAMLとも連携していると思います。AzureはMicrosoftオンリーなので、OpenID系とSAML系でそれぞれID Providerはどれぐらいあるのかちょっと調べてみます。

OpenIDに関しては既に調べている方がいました。
OpenID Connect 対応してるWebサービス/製品のログイン認証関連のドキュメントリンク集

AWS SSOのページで多数のSAML対応業務アプリが確認できたり、前述資料によると大学などはSAMLで構築しているので、世の中の勢力としてはSAMLの方が高そうです。OpenIDはOpenと言っているぐらいなので、不特定多数にオープンにしているサービスに合っているのでしょう。業務系のシステムではSAMLを意識しておいた方が良いかもしれません。

OpenID

Google
Paypal
Auth0
LINE
Yahoo!!

OAuth

Github
Facebook
twitter

SAML

LINE Works
Salesforce
AWS SSO 多数のSAML対応アプリケーションがあるようで、SAMLIDプロバイダーとして動くと思っていいと思います。
HENNGE ONE
ArcGIS Enterpriseのドキュメント によると以下もSAML IDプロバイダーとして動作するようです。最初の二つ以外はオープンソースですね。

• Azure Active Directory
• NetIQ Access Manager 3.2 以上
• OpenAM 10.1.0 以上
• Shibboleth 2.3.8 以上
• SimpleSAMLphp 1.10 以上

OSSの存在調査

SSOではなく、OpenSourceSoftwareの方です。何かテストしようとして、社内の認証サーバー使ったらシステム管理者に怒られます。テスト用の認証サーバーが欲しいです。OSSの存在チェックです。

OpenAM （OpenID、SAML）：CDDL
Keycloak（OpenID、SAML）：Apache-2.0 License
SimpleSAMLphp（SAML）：GNU LESSER GENERAL PUBLIC LICENSE
Shibboleth 2（SAML）：Apache 2.0
OpenLDAP（LDAP）：The OpenLDAP Public License
Samba（ActiveDirectory）：GNU General Public License

OpenID関係では前述ページで紹介されていたものしか見つけられませんでした。SAMLとOpenID両方に対応しているOSSもあるようです。Keycloakの方が新しい様で、これからSSOなどを開発用で試す時にはKeycloakを使って試すのがよさそうです。Shibbolethは学術系でデファクトらしいです（Shibboleth, 学認 を知ろう）。
（Azureでない方の）ActiveDirectoryを使ってこれから何かする事はあまりなさそうですが、一応準開発用に備する事は可能そうです（GPLっぽいので開発テストに使用するぐらいでしょうか）。

実装例

OSSで構築する時１から調べると大変なので先達の知恵は得ておきたいです。

OpenID Providerの実装例 ～OpenAM～
Keycloakのインストールと構築例

AWSでの認証周り機能

AWSとの関係は外せません。AWSで認証と関係するサービスも調べてみます。

Cognitoユーザープール

ユーザープールは、アプリユーザーのサインアップとサインインオプションを提供するユーザーディレクトリです。

AWSのコンソールでCognitoを開くとこんな説明が現れます。ユーザー情報を扱うディレクトリサービスという事でしょうか。
実際にはログインユーザー情報や認証方法を管理しているので、認証を行うIDプロバイダーと考えてよいと思います。
Cognitoユーザープール単体でも認証は可能ですが、別サービスとの連携も出来る様です。AWSのユーザープールにてフェデレーション>IDプロバイダーを選択した時の画面です。

AWS再入門ブログリレー Amazon Cognito編 によると、Cognitoユーザープール本体のログインも別IDプロバイダーとの連携でのログインもCognitoユーザープールに登録されて一元管理される模様です。世の中では、サービス毎のサインアップも出来るしGoogleやFaceBookでもログインできるサービスをよく見かけますが、この機能を使用する事で実現できるのだと思います。

Cognito IDプール

ID プールは、ユーザーに別の AWS のサービスへのアクセスを許可する AWS 認証情報を提供します。

いわゆる認可機能でしょうか。Cognitoユーザープールも含めた認証プロバイダーから得た情報を元にそのユーザーにどの機能を許可するかを処理するサービスですね。IDプールの設定画面です。

認証されてない場合と認証されている時のロールを指定できます。webサービスだと認証されているかどうかはクライアント側で処理するかと思いますが、APIなどでアクセスされた時のサーバーサイドバリデーションに使えそうです。
そして認証プロバイダの部分では、Cognitoを含めた認証プロバイダーを選択出来る事が解ります。どれか一つを選択と言うよりかは、それぞれの認証プロバイダーで認証された時の処理が設定できそうです。

自分が知る限りでは、DynamoDBとS3は以下の様な指定で、フォルダやキー指定でユーザー毎のアクセス範囲を指定できます。

認証された場合に使用するロールでのResource指定例

    "Resource": [
        "arn:aws:s3:::hogehoge-bucket/cognito/fugafuga/${cognito-identity.amazonaws.com:sub}",
        "arn:aws:s3:::hogehoge-bucket/cognito/fugafuga/${cognito-identity.amazonaws.com:sub}/*"
    ]

両方にSAML？

ユーザープールとIDプール両方にSAMLとの連携が出来る様ですが、違いは何でしょう。

ユーザープール側でフェデレーション>IDプロバイダーにてSAMLを選択するとメタデータを読み込む様になってます。

IDプール側だと、以下の様に出てきます。まずはIAMでSAMLプロバイダーを登録する必要がある様です。

ID プールでの認証には、以下の SAML ID プロバイダーを選択します。Amazon Cognito は、任意の SAML 2.0 ID プロバイダーを通じた認証をサポートします。SAML プロバイダーの使用の詳細を参照してください。
このアカウントに対して設定されている SAML プロバイダーはありません。
SAML プロバイダーを作成して管理するには、AWS IAM コンソールにアクセスしてください。

IAMの画面で、IDプロバイダを追加する画面です。プロバイダ名とメタデータドキュメントを指定するという点では同じですね。

前述 AWS再入門ブログリレー Amazon Cognito編 に書いてありますが、ユーザープールでの連携の方が新しいサービスの様です。新しく構成するならユーザープール側で連携した方がよさそうです。認証に使うライブラリもユーザープールとIDプールのセットで使われる事を想定しているようです。
また、外部サービスとの連携は試した事ないので勝手な想像ですが、ユーザープール側で認証しておけば、その後はトークン有効性確認とかの各処理をAWS側で行う時に、外部IDプロバイダでなくCognitoで処理できるので高速化が見込めるとかもあるのではと想像します。

AWS SSO

公式ページ：AWS Single Sign-On 紹介 によると、オンプレのActiveDirectoryと連携して、AWS内のサービスはもとより外部のクラウドサービスやSAML対応アプリケーションとのシングルサインオンを可能にするようです。そうするとAzure ActiveDirectoryと同じような事が出来そうです。

使い始めるには、まず社内の Active Directory を AWS Directory Service を使って AWS SSO に接続します。社内のディレクトリを接続するには AWS Directory Service の AD Connector を使用する方法と、AWS Directory Service for Microsoft Active Directory (Microsoft AD) とオンプレミスの Active Directory と信頼関係を設定する方法の２つ選択肢があります。

とも書いてあり、DirectoryServiceは必須の様です。ActiveDirectoryをAWS内に作るか、外部のActiveDirectoryとの連携をするかという選択肢という事かと思われます。

公式ページ：アイデンティティソースの選択 では、AWS SSO単体でもユーザー管理できそうですが、
AWSSSOでのID の管理 によるとActiveDirectoryを使っているならそちらで管理してくださいという事で、ActiveDirectoryを薦めているようです。

AWS Directory Service

そのAWS SSOに必要なActive DirectoryServiceです。AWSもディレクトリサービスを提供しているようです。4種類ある様です。

AWS Directory Service とは にそれぞれのユースケースが記載されていました。

AWSManaged Microsoft AD

AWSManaged Microsoft AD は、実際の Active Directory 機能が必要な場合は、が最適な選択肢です。AWSアプリケーションや Windows ワークロード (for Microsoft SQL Server の Amazon Relational Database Service 含む) を使用します。また、AWS クラウドで Office 365 をサポートするスタンドアロンの AD が必要な場合や Linux アプリケーションをサポートする LDAP ディレクトリが必要な場合にも最適です。詳細については、「AWSManaged Microsoft AD」を参照してください。

名前の通り、フルマネージドのActiveDirectoryの様です。

AD Connector

AD Connector は、既存のオンプレミスディレクトリをAWSのサービス。詳細については、「Active Directory Connector」を参照してください。

前述のAWS Single Sign-On 紹介 から引用した文章からすると、オンプレのActiveDirectoryを活用してAWSのSingleSignOnを使いたい時に使用するようです。

Simple AD

Simple AD をクラウド内でスタンドアロンのディレクトリとして使用すると、基本的な AD 機能を必要とする Windows ワークロードをサポートし、互換性のある ADAWSアプリケーションを使用したり、LDAP サービスを必要とする Linux ワークロードをサポートしたりできます。詳細については、「Simple Active Directory」を参照してください。

また、詳細画面では以下の様に書かれていました。Sambaのフルマネージドサービスという事の様です。

Simple AD は、AWS クラウドでホストされるマネージド型の Samba 4 Active Directory Compatible Server であり、Microsoft Active Directory の機能のサブセットを提供します。

Amazon Cognitoユーザープール

カスタム登録フィールドを作成し、そのメタデータをユーザーディレクトリ内に格納する必要があるときにも Amazon Cognito を使用できます。このフルマネージド型のサービスは、拡張して何百万というユーザーをサポートします。詳細については、「ユーザープールの作成および管理」を参照してください。

ちなみにユーザープールを選択して「次へ」に移ると、Cognitoユーザープール作成のページに移動します。ディレクトリサービスは階層的に各種リソースを管理できると思いますが、このモードだとユーザー情報をActiveDirectory形式で取得できるようになるという事になるのではと思います。

次へ向けて

今回、記事にまとめる事で大分自分の中での機能や用語の関係性が解ってきました。これから各種サービスへアクセスする時には、あぁ、ここはあそこへ認証へ行って開いているんだなとか感じそうです。
テスト的にCognitoは使った事あるのですが、業務システムとしての使い方は考えた事無い状態です。実際にSAMLを使用してログイン処理や機能認可を実装してみる事で理解を深めていきたい所です。

引用させて頂いたり参考にさせて頂いたページ

オフィシャルページ

OAuth
OASISによるSAML公式ドキュメント
Microsoft公式ページ：Azure Active Directory と認証および同期プロトコルの統合
Microsoft公式ページ：AD FS の概要
Microsoft公式ページ：すべてのアプリを Azure AD と統合するための 5 つの手順
AtlassianをADFSと連携する設定
AWS Single Sign-On 紹介
アイデンティティソースの選択
AWS Directory Service とは

Wikiページ

ディレクトリ・サービス
LDAP

解説ページ

一番分かりやすい OAuth の説明
SAMLとOAuth：比較と違い OpenID（OIDC）との関係
OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ
OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い。
What is OpenID Connect?
IT用語辞典：Kerberos
Active Directory（アクティブディレクトリ）をゼロから解説、関連用語もまとめて紹介
【図解】初心者にも分かるKerberos認証とspnegoの仕組み ～SSOのシーケンス,統合windows認証について～
【図解】Active Directory の認証プロトコルと起動/ログオンシーケンス
今さら聞けないAzure ADとは？オンプレミスのActive Directory（AD）との違い
強力なSSOを実現するXML認証・認可サービス（SAML）
OpenID SAML - 総務省
OpenID Connect 対応してるWebサービス/製品のログイン認証関連のドキュメントリンク集
OpenID Providerの実装例 ～OpenAM～
Keycloakのインストールと構築例
AWS再入門ブログリレー Amazon Cognito編

その他

7Pay事件