Help us understand the problem. What is going on with this article?

ついでに認証周りを理解してGoogle AppsのSAMLでAWSへログインを設定してみる

More than 3 years have passed since last update.

はじめに背景的なこと

  • 結構前からですが、クラウドサービスを多く使ってシステムを作る機会が多くなりました。
  • 当然一つのクラウドサービスだけではないので複数使ったりします
  • メールや資料の共有とかも、もはや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と同じ枠組みに入る。つまり、アカウント認証のみの機能

一旦整理すると下記のような概要図かな

zuu.png

  • 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のコンソール画面へログイン済の状態でリダイレクトします

saml-based-sso-to-console.diagram.png

参照) 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 ARNprovider 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アカウントのアプリ一覧に出てくる

メール.png

  • Amazon Web ServieをクリックしてGoogleアカウントの認証をするとAWSのコンソール画面へログイン済の状態でリダイレクトされる
  • 細いけど、上記のAmazon Web Servieのアイコン画像をカスタムできる

まとめ

  • Google AppsのSAMLアプリでカスタムも可能なので社内で使ってるツールにも適用可だと思った
  • SAML認証に対応していないクラウドサービスの扱いはどうしようかな、、、
  • ついでに周辺技術を調べて理解するきっかけになったので何事も学ぶ姿勢は大切ですね
  • SAMLの認証プロバイダーはOpenAMも有名なんだ。知らなかった。というかこっちが先か
  • こーいった標準化は使い手にはとてもありがたい
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした