Interact2018参加レポその②
♯ADFSで実現するOpenIDConnectの実装
Webアプリを利用するためには、認証が必要
⇒アプリごとにばらばらな認証が必要となる環境が実際多い。
⇒まずはこれを整理しよう！
認証基盤の一元化
・IDを統合(オンプレ／クラウド問わず)
・アプリと認証基盤と連携するかの認証プロトコルを決める。
・リソースの保護
今回は以下内容で
ADにすべての認証を寄せて、
OIDCで認証連携を実現する
ADFSをO365と連携するのにしている。
その時使われるのがSAML
Webアプリを「SAML」に対応させるのか「OIDC」に対応させるのか？
⇒SAMLは死に体。。。
XMLとJSONで違いがある。 ⇒データのサイズに大きな違い
⇒JSONのほうが少ないコード
スマホなどでは大量のデータを扱いたくない。のでOIDCに移行が進んでいる。
認証・・・本人確認
認可・・・アクセスできるユーザなのか確認して許可する
プロトコルの立て付けは以下の通り
OAuth 認可
OIDC 認証
AzureADによる実装では、AzureADに実装すればよい
⇒AzureADのみで完結できる！！
ADFSサーバーでは、認証のためにADとの連携が必要
OpenIDConnectでの実装に必要なパラメーター
OIDCでログインすると、「要求されているアクセス許可」
このアプリケーションから認証の依頼来てるけど、いいよねって確認の画面
OIDCの仕様で出てきたやつや！！！
AzureAD上でアプリを登録しておくのが必要！！！
認証認可で使いたい場合はADと同様で
サーバーにアクセス権きるときにはそもそもサーバーをドメインに参加さ得ておかないといけない。
⇒それと同じでAzureADにも登録をしておかないといけない。
OIDCではAzureADに登録されていなくても、「要求されているアクセス許可」の画面でポチれば、かってにAzureADに登録される。
誰に対してのアクセス権を設定するか、の設定はこの同意の画面で行われるのがOIDC、OAuthの特徴
ADFSの場合は
ADFSの場合のログインはフォームでもできるし、ウインドウも選択できる
初めてサインインするときにはOIDCでは同意の画面があったが、
ADFSの場合は、この同意をあらかじめしてある前提となっている。
ADの場合、登録情報はすでにADに登録されていて、管理者が全て管理できているので、「もう今更同意もないよね？」って考えのもとそのような仕様になっている。
Webサーバーが認証前のアクセスに対して、ここにアクセスしてこいや！っていうそのアクセス先
「Authorizeエンドポイント」
⇒Webアプリ側のADFSサーバーの「メタデータ URL」で設定
ADFSのトークンは「認可コード」と呼ばれるもの
認証済ませたら、どこにアクセスしに行けばいいのか
⇒応答URL
⇒この情報はADFSサーバーが持っている必要がある。「認可コード」と一緒に渡されるので、ADFSサーバー側で設定
ADFSでは公開鍵方式でトークン署名を行うので、Webアプリ側にはトークン署名証明書の公開鍵も必要！！！
・クライアントIDとは？？
⇒ADでいうところのコンピュータオブジェクト
実際のADFSでの設定
・ADFSでOIDCを使うのは、ADFSの管理画面の「アプリケーショングループ」の画面で実施する。
⇒設定すると、「クライアント識別子」が払い出されるので、それをWebアプリ側のクライアントIDに設定する！！！
「アクセス制御ポリシー」がOIDCでも使える。
⇒ADFS側で制御を掛けることが可能！！！
自分で試すには、
リダイレクトURIを「https://localhost:44320」を指定してあげる！！
メタデータURLは決まっている。
⇒７P の「https：＜フェデレーションサービス名＞～」をいれる。
⇒規約？で決まっているみたい
おわりに
Webアプリ⇒APIへの連携では「認可」が発生するので、そこではOAuthが使われる。
⇒この設定はADFSの中での設定、プロパティで、「WebAPI」の部分の設定で行われる
OIDC,OAuthの場合、パケットのフローは変わる。
⇒細かく言うと、「response_type」のタイプによって変わる
まとめ
まずはバラバラな認証の仕組みを統一するところから始めていきましょう！！
⇒その過程でADFSなのかAzureADなのか
この記事が気に入ったらサポートをしてみませんか？