#はじめに
オンプレミスとの連携によるAWS環境へのアクセス認証について、改めて整理した。
#出てくるワードたち
- SAML(Security Asserrion Markup Language):
SSO(シングルサインオン)を実現する仕組みの1つ。OASISによって作成された異なるドメイン間でユーザ認証を行うための認証情報の規格 - SP(Service Provider): サービスの提供側、SAMLの認証情報を利用する
- IdP(Identify Provider): 認証情報を提供するシステムのこと(Active DirectoryやG Suiteなど)
- SAML Assertion: IdPとSPでやりとりするユーザの認証情報のこと
- SSO:１組のIDとパスワードで認証を行い、複数のサービスにログインできる仕組みのこと
#アクセス認証パターン1
〜AWSマネージメントコンソールへのアクセス
①IdPで認証を行う
②ユーザを識別するSAMLアサーションを返す
③SAMLアサーションをSSOエンドポイントにPOSTする。
④AWS STSのAssumeRoleWithSAML APIを呼び出し、一時認証情報を取得する。一時認証情報を利用して、AWS マネジメントコンソールのサインイン URLを発行する。
⑤エンドポイントからAWS マネジメントコンソールのサインイン URLがブラウザに返される。
⑥一時認証情報でAWS マネジメントコンソールへアクセス
#アクセス認証パターン2
〜AWS APIエンドポイントへのアクセス
パターン1のようにブラウザからのアクセスではなく、アプリケーションがAWSのAPIへアクセスする場合の構成
①IdPで認証を行う
②ユーザを識別するSAMLアサーションを返す
③SAMLアサーションをPOSTする。
④AWS STSのAssumeRoleWithSAML APIを呼び出し、一時認証情報を取得する。
⑤一時認証情報でAPIへアクセス
SAMLとOpenIDの違い
なぜ、SSOにSAMIL認証を使うのか?
SSOにはSAMLの他にOpenIDがあり、両者を比較してみる。
(OpenIDの説明については、本資料では省略)
| SAML | OpenID | |
|---|---|---|
| 認証結果の伝送方法 | アサーション | IDトークン |
| データ形式 | XML | JSON |
| 事前登録や事前の情報交換の要否 | 必要(SPとIdPの間で事前に公開鍵を交換が必要) | 不要 |
| ログイン情報を提供するサービスの選定 | ユーザーの同意なしで連携 | 連携する/しないはユーザ自身が判断 |
| 連携するかどうか | ユーザに同意確認しない | ユーザ自身で選択可能 |
| 最適な用途 | Enterprise | Consumer |
| #参考 |