はじめに背景的なこと
- 結構前からですが、クラウドサービスを多く使ってシステムを作る機会が多くなりました。
- 当然一つのクラウドサービスだけではないので複数使ったりします
- メールや資料の共有とかも、もはやGoogle Apps For Workで完結します
そういった流れの中でID,PW管理が非常に煩雑になり、且つ結構重要なセキュリティ項目になってたりします
（AWSのID,PWとか外に出たらヤバイですよね）
このクラウドサービスを当たり前に使うようになったこのご時世に、セキュアに効率的にアカウント管理をしようってなって色々調べたメモ的なまとめ。
こう言ったのを統合認証とかっていうのかな。
ちょっと間違った理解になってる可能性ありですが、、、まとめていきます
まずはよく出てくる用語を整理する
統合認証とは
社内のシステムや複数のクラウドサービスを利用する際に各システムにそれぞれ認証を行うのではなくて、統合的に認証を管理する仕組み的な感じ。
そこで出てきたのがシングル・サインオン(Single Sign-On=SSO)という考えがあります。
SSO(Single Sign On)とは？
一回の認証手続き（ID/PW等でユーザ認証）で複数のアプリケーションに認証を引き継げてそのまま利用できる。
フェデレーション（Federation)って呼んだりします
SSOには下記のメリットがあったりします。
管理的視点のメリット
- 日々煩雑になるID、PWの管理工数の低減（追加・削除・変更とか）
- 人の入退社があるたびに大変ですよね
- 一元管理による作業の効率化できます
ユーザ的視点のメリット
- 複数回に渡るログイン操作から解放される
- 数秒で終わるとはいえ、毎日同じ操作を強いられるストレスは特にエンジニアとしてはツライですよね。
- ID,PWが減るので覚えられる
SSOの流れでよく出てくる「SAML」って？
SSOを実現するために業界標準的なプロトコルがSAML(Security Assertion Markup Language)
標準化団体OASISによってつくられた仕組み
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
業界標準的な手法SAMLだけど同列には下記の方法もある
- エージェント方式
- リバースプロキシ方式
- 代理認証方式
まぁ特殊な事情がない限り、SAMLがあるならSAML一択なのでここではこんなのもあるんだ的な理解で収めておく
いろいろとググると詳しい説明が出てくるのでそちらに任せる
SSOの流れでよく出てくる「OpenID」、「OAuth」に触れる
- そもそもSSOは社内のイントラネットの認証の仕組みをインターネットへ拡大していった流れがあったっぽ
- LDAPとか
- 一方「OpenID」とか「OAuth」とかはそもそもインターネット上で完結する認証しようぜ的な流れ？考え？があってできたっぽ
- Facebook、Twitterでログインするサイトとかです
その「OpenID」、「OAuth」でも違いはある
OpenID
各ウェブサービスで共通で使えるアカウントの認証を提供する
OAuth
Aというサイトで使ってる機能をBというサイトでも使えるようにアカウントの認証と認可を提供する
備考
- 「OpenIDは認証でOAuthは認可」なんてよく言われましたよね。このへんは細かく言うといろいろとツッコミがありそうなので大枠の理解で
- SAMLはOpenIDと同じ枠組みに入る。つまり、アカウント認証のみの機能
一旦整理すると下記のような概要図かな
- SSOという言葉の意味で言うとOpenIDもOAuthもSSOとも言えるけど、出来上がった歴史的背景があって別理解のがいいのかなと思って分けて理解してみた
- SSOには色々と実現方法があるけど、今なら業界標準的なSAMLの一択
- SSO(SAML)、OpenIDはアカウント認証のみ
- OpenIDとの違いはよりセキュアなのがSAML
- メタデータの交換、証明書の交換を事前に行ってるのでSAMLのがセキュア
- OAuthはアカウント認証＋機能の許可
- SSOとOpneID,OAuthは歴史的な背景が異なり、得意分野が異なるイメージ
- OpneID,OAuthはwebの世界でいうとFacebookやTwitterのIDでログイン、会員登録ができるサービスがこれを活用している
備考
AWSではフェデレーティッドシングルサインオンと呼んでAWSのAPIも呼び出せるようですね。OAuth的な要素がちょっと入ってる感じなのだろうか。
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_saml.html
やっと本題です
Google AppsのSAMLでAWSへログインのフロー図
- 下記の図で言うところのYour Organization(Identity Provider)がGoogle Apps
- Google Appsのログインアカウント（email）、PWを認証するとAWSのコンソール画面へログイン済の状態でリダイレクトします
参照） http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html
設定の話
参考URLの方が詳しいのでざっくりいきます
Google App側の設定
- Google Appsの管理画面に入る
- メニューからアプリを選択
- SAMLアプリを選択
- Amazon Web Serviceを選択
- 基本的にデフォルトのままで進む。途中でXMLのメタデータをダウンロードする
- 属性のマッピングで
従業員の詳細 > 役職へ設定する
AWS側の設定
- IAMの画面を開く
- IDプロバイダ画面から新SAMLプロバイダを登録
- 先ほどのGoogle Apps側のXMLのメタデータを一緒に登録する
- 新SAMLプロバイダにWebSSOを付与
-
role ARNとprovider ARNをメモ
再びGoogle Apps
- AWSへ認証ログインさせたいユーザを選択
- アカウントの設定 > 基本情報の編集 > のタイトルに
role ARN,provider ARNを記入- カンマも必要
でok
参考
下記あたりの情報のがわかりやすいかもです
- https://blogs.aws.amazon.com/security/post/TxT8XK9DVM0MGP/How-to-Set-Up-Federated-Single-Sign-On-to-AWS-Using-Google-Apps
- http://www.k-staging.com/?p=1573
設定が終わると許可したGoogleアカウントのアプリ一覧に出てくる
- Amazon Web ServieをクリックしてGoogleアカウントの認証をするとAWSのコンソール画面へログイン済の状態でリダイレクトされる
- 細いけど、上記のAmazon Web Servieのアイコン画像をカスタムできる
まとめ
- Google AppsのSAMLアプリでカスタムも可能なので社内で使ってるツールにも適用可だと思った
- SAML認証に対応していないクラウドサービスの扱いはどうしようかな、、、
- ついでに周辺技術を調べて理解するきっかけになったので何事も学ぶ姿勢は大切ですね
- SAMLの認証プロバイダーは
OpenAMも有名なんだ。知らなかった。というかこっちが先か - こーいった標準化は使い手にはとてもありがたい