AWS SSOなどを使いマネジメントコンソールや外部Webサービスをシングルサインオン化する（各種サービス設定）

# はじめに

この記事は以下の記事の続きとなります。
https://qiita.com/morin_river/items/0a36fd5c02976f6cb774

が、ここではSAML 2.0の認証方法を書いているので
AWS SSO以外のSAML 2.0認証アプリケーションの参考になるでしょう。

## 補足

SAML 2.0規格のサービスであれば
One LoginやGoogle SSOなどでも同じように使えると思います。
現時点ではOne Loginがサービスとしては一番使い勝手が良さそうです。
ユーザ数などで私は要件に会いませんでしたが
SSOサービスはAWS SSO以外も含めて検討するとよいでしょう。

## 共通の内容

### 用語

今回は、AWS SSOを利用するために最小限の説明になります。
そのため、正確には間違っている可能性はあります。
SAML 2.0の詳細は奥深いので、調べて見てみるのも面白いでしょう。

#### SP

Service Providerの略です。
SAML 2.0によって認証されるサービスを指します。
ここでは、RedashやJenkinsなどになります。

#### IdP

Identity Providerの略です。
IDの正当性を評価するものを指します。
ここでは、AWS SSOとなります。

SPとIdPに関してはこちらのページに詳しくあるので、参照してください。
http://nantonaku-shiawase.hatenablog.com/entry/2016/07/13/081053

#### ACS

AssertionConsumerServiceの略です。
SAML 2.0のセッションを確立するために使われます。
SAML 2.0アプリケーション上から提供されるURLを使うことが多いようです。

正確には、以下のページを参照してください。
https://wiki.shibboleth.net/confluence/display/CONCEPT/AssertionConsumerService

#### Audience 

SAML 2.0アプリケーションの要素を検証するのに利用される値です。
通常はSPで設定するEntityIDかACSのURLになります。
正確には、以下のページを参照してください。
https://support.okta.com/help/Documentation/Knowledge_Article/Common-SAML-Terms

### 手順

#### Active Directoryの属性マッピング情報を入力

ダッシュボードから「Connected Directory」を選択し、「Attribute mappings」を表示します。
ここでは、Active DirectoryからSAML 2.0アプリケーションに渡す属性をマッピングします。

![aws_sso_start_01.PNG](https://qiita-image-store.s3.amazonaws.com/0/146781/d53fc038-dbb0-dec9-892d-9f2d6c003cea.png)


そこで、「Edit attribute mappings」ボタンから
「Active Directory」と「AWS SSO」のマッピング設定が行えます。

**ただ、この属性マッピングには罠があり、Active Directoryのデータをすべて使える訳ではありません。**
Active Directoryでは多くの属性を定義できるのですが、
AWS SSOで利用できるActive  Directoryの属性は以下の限りとなります。
https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/attributemappingsconcept.html

以下引用です。

> Supported Directory Attributes

| Supported attributes in your connected directory |
| ---                                              |
| ${dir:email}                                     |
| ${dir:displayname}                               |
| ${dir:distinguishedName}                         |
| ${dir:firstname}                                 |
| ${dir:guid}                                      |
| ${dir:initials}                                  |
| ${dir:lastname}                                  |
| ${dir:proxyAddresses}                            |
| ${dir:proxyAddresses:smtp}                       |
| ${dir:proxyAddresses:SMTP}                       |
| ${dir:windowsUpn}                                |

ここに記載されいる属性のみがサポートされている属性となります。

そして、このパラメータがすべて使える訳ではありません。
AWS SSOに繋ぎこむときは、以下のパラメータのいずれかマッピングする必要があります。

> Supported AWS SSO Attributes

| Supported attributes in AWS SSO |
| ---                             |
| ${user:AD_GUID}                 |
| ${user:email}                   |
| ${user:familyName}              |
| ${user:firstName}               |
| ${user:middleName}              |
| ${user:name}                    |
| ${user:preferredUsername}       |
| ${user:subject}                 |

少ない…せめてpositionとかの属性は欲しい…。
この通り、AWS SSOではグループに相当するパラメータがありません。
Redashなどユーザごとでグルーピングされたパラメータが欲しかったので、苦し紛れに私はActive Direcoryのemailの値にグループ属性をもたせました。
これは余り良い方法じゃありません。
SSOのパスワード再発行機能が利用できない可能性があります。

私は要件としてパスワード再発行を利用しなかったのでこの運用で問題なかったのですが、
ここは早くアップデート来て欲しいな…。


#### 新規AWS SSOのアプリケーションの追加

ダッシュボード上から「Applications」を選択し、「Add a new application」ボタンで
新規にアプリケーションを追加します。

![aws_sso_0625_01.png](https://qiita-image-store.s3.amazonaws.com/0/146781/94a6e7ce-23c7-8be0-d340-f4dc7420d70b.png)
![aws_sso_0625_02.png](https://qiita-image-store.s3.amazonaws.com/0/146781/273b9382-8e44-e70f-6970-c97b950c3f92.png)

一覧に追加したいSAML 2.0アプリケーションがない場合
「Custom SAML 2.0 application」を選択してください。
2018年6月時点ではそこまで初期設定済みのアプリケーションが多い訳ではありません。
（今回の記事内のアプリケーションで記載があるのはG Suiteのみです）

#### 基本パラメータ入力

設定の入力画面はこのような画面になります。

![aws_sso_0625_04.png](https://qiita-image-store.s3.amazonaws.com/0/146781/2515ad5e-35b0-359a-2b1e-0eb6853c2ca9.png)

以下のようにAWS SSOの設定にSPのパラメータを入力します。

| 項目         | 内容  | サンプル            |
| --- | --- | --- |
| Display name | SSOポータル上の表示名を入力します                                  | SAMPLE APP          |
| Description  | 説明を入力します。（恐らく）マネジメントコンソールでのみ参照します | sample application. |

これ以降は、アプリケーションごとに個別となります。

#### アサインするユーザの入力

作成したアプリケーションにアサインさせるユーザを指定します。

ダッシュボードから、「Applications」「Assigned users」と遷移します。

「Assign user」ボタンを押し追加するユーザを選択します。

![aws_sso_0625_08.png](https://qiita-image-store.s3.amazonaws.com/0/146781/8e516686-50b4-d6ca-5811-05a02acdc4db.png)

ここでは、Active Direcoryのユーザ単位ではなくグループ単位でも指定できます。
マッチするユーザ/グループ名を入力し、「Search Connection direcory」ボタンを入力し検索します。
その結果から追加対象を選択し、「Assign users」ボタンでアサインを完了します。

![aws_sso_0625_09.png](https://qiita-image-store.s3.amazonaws.com/0/146781/8e350599-5f57-68f5-49e4-25809f483af9.png)

一度GUI上で設定が完了すれば、次回移行はAD上のグループにユーザを追加するだけでユーザ登録ができますね。
私はADのユーザ登録はAnsible化しているので、
初期設定さえ完了すればCUIのみの作業で完結するようにしています。

https://qiita.com/morin_river/items/62330d02df92f2492860

この記事でグループ所属にこだわっていたのはこのような理由があるからでした。
ここで登録すれば、AWS SSOのユーザポータル画面に追加したアプリケーションが表示されます。

もちろん、実際にSSOが使えるのはアプリケーション固有の設定が終わってからですが
なれないうちは切り分けの為にここで確認するのも良いでしょう。

## Redashへの導入

### 前提

Redashのv0.11以上が必要です。
現行バージョンでは既存のユーザは維持されますが
後方互換性が維持されるかどうかは不明です。

また、v4.00からGUIの画面でSAML 2.0の設定ができるようになりました。
https://redash.io/help/user-guide/users/authentication-options

~~そうかー…一時期ドキュメントがなかったのはこの切り替え時期だったから…大変だったのに~~
v4.00より上のバージョンの場合、.envファイルに記載する手順をGUI操作に置き換えても良いかもしれません。

また、RedashでSAML 2.0が使えるようになるには
Cybozuのエンジニアの方の大きな貢献があったようです。
http://blog.cybozu.io/entry/2016/12/19/080000

感謝しながら使わせて頂くようにしましょう。:pray:

### 手順

他のアプリケーションと同じく共通手順からカスタムアプリケーションを作成しておきます。

#### アプリケーションパラメータ切り替え

Application metadataを設定します。
Redashでは、2018年6月現在metadataファイルはありません。
そこで手動でmetadataの値を入力します。

以下の画面から、切り替えボタンを押します。
~~わかりにくい…。~~

![aws_sso_0625_05.png](https://qiita-image-store.s3.amazonaws.com/0/146781/33cddcc1-878a-1d86-d06f-fe9a8840b341.png)

そうすると、画面がこのように切り替わります。

![aws_sso_0625_06.png](https://qiita-image-store.s3.amazonaws.com/0/146781/68dd9fd1-1a2f-38d4-af6a-5572c5f617e1.png)


#### アプリケーションパラメータ入力

出てきた入力欄に、以下のように入力します。


| 項目                      | 内容                                                                                                              | サンプル                                 |
| ---                        | ---                                                                                                                | ---                                       |
| Application ACS URL       | Redashでは、自ホストの末尾に/saml/callbackをつけたものをACSのエンドポイントとするようです。                       | https://redash.example.com/saml/callback |
| Application SAML audience | ここでは、Application ACS URLと同じにします。                                                                     | https://redash.example.com/saml/callback |
| Application start URL     | Redashでは、自ホストの末尾に/saml/loginをつけたものをSAMLアプリケーションのログインエンドポイントとするようです。 | https://redash.example.com/saml/login    |

ここで設定する値は、特にドキュメントに乗っておらずソースから探して設定したので
将来変更される可能性はあります。
ですが、ホスティングRedashのドキュメントに似た値を設定する手順が追加されていたので大丈夫かな…。

#### 属性のマッピング情報を入力

Redash固有のマッピング情報を入力します。

| 項目         | 内容                                                                                                                                            | フォーマット | サンプル           |
| ---           | ---                                                                                                                                              | ---           | ---                 |
| Subject      | WindowsUPNが設定されるsubjectを入力します。                                                                                                     | transient    | subject            |
| FirstName    | ユーザのFirstNameを入力します。AWS SSO上ではgivenNameに相当します。                                                                             | nonescaped   | ${user:givenName}  |
| LastName     | ユーザのLastNameを入力します。AWS SSO上ではfamilyNameに相当します。                                                                             | nonescaped   | ${user:familyName} |
| RedashGroups | ユーザの所属するRedash上のグループを指定します。私は、共通項目のマッピング項目に記載している通り、ADのemailにグルーピング情報を入力しています。 | nonescaped   | ${user:email}      |

#### アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

#### Redash上の設定

AWS SSOの「configuration」タブからAWS SSOのmetadataが記載されているURLを取得します。
このURLはアプリケーションごとに新しいものが発行されます。

通常の画面からは~~なぜか~~ダウンロードボタンしか表示されません。
が、「Edit Configuration」ボタンを押すことでmetadata fileのURLがコピーできようになります。
まぁ、Redashではローカルのmetadata fileを指定できるので
ダウンロードしたものをサーバに配ってもよいでしょう。

Redash上で設定が記載される「.env」ファイルに以下の項目を追加します。
上記の通りRedash v4.0以上のバージョンでは設定画面に同じ項目があるようです。
（私は未検証です）

```bash
export REDASH_SAML_METADATA_URL="YOUR_AWS_SSO_METADATA_URL"
export REDASH_SAML_ENTITY_ID="YOUR_REDASH_APPLICAITON_ENTITY_ID"

# example

export REDASH_SAML_METADATA_URL="https://portal.sso.us-east-1.amazonaws.com/saml/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
export REDASH_SAML_ENTITY_ID="https://redash.example.com/"
```

REDASH_SAML_ENTITY_IDは、本来ならSAML audienceとあわせて末尾に/saml/callbackを加えた方が良いかもしれません。
上記設定を記載したあと、Redashプロセスを再起動します。

そうすると、通常のRedash設定画面の上に「SAML Login」という項目が現れます。

![aws_sso_0625_11.png](https://qiita-image-store.s3.amazonaws.com/0/146781/ac7c09cf-247e-d78a-b173-11ed78f37363.png)


ここで、AWS SSOにログインしているとSAML 2.0の認証を使いRedashにログインが可能です。
また、AWS SSOのユーザポータル上のアイコンをクリックすることでもログインができるようになります。

この時、すでに既存のユーザでRedashにログインした状態だと既存ユーザのログインセッションを使ってログインします。
必ずログアウトし、別ユーザでログインできているか確認しましょう。
成功していれば、AWS SSO用のユーザが作成されています。

## G Suiteへの導入

### 前提

G SuiteへSSOを導入することで
GCPなどのサービスも同じようにSSOで管理することができます。

G Suiteへの導入は、いくつか注意しておくべき点があります。
サービスのSSO化はしますがG Suiteだけ要件に合わないから
以前の運用のままにしておくというのもひとつの方法かもしれません。

#### 他のGoogleサービスを利用している場合の問題

**GoogleのサービスはGoogleアカウントに紐付かれます。**
また、SAML 2.0のログインを有効にすると、
**全てのユーザでSAML 2.0を要求されるようになります。
そして、恐らくGoogleアカウントはサービス利用時にユーザ認証が行われます。
つまりID + パスワードの認証ができなくなります。**

**その結果、導入しようとしているG Suiteにログインしているクライアント（ブラウザなど）では
SSOの認証が終わるまで他のアカウントのGoogleサービスも利用できなくなります。**

組織のGoogleアカウントのSSOアカウントが発行しおわるまで
個人で利用しているGoogleドライブが使えない、みたいなことが発生します。
導入が終わると大変便利に使えるのですが
切り替えまでの周知や確認はしっかり行っておくといいでしょう。

GoogleによるSSOの公式リファレンスは以下となります。
https://support.google.com/a/answer/60224?hl=ja

#### ユーザアカウントの問題

G Suiteアカウントは、SSOから作成する事はできません。
アカウントごとに課金されるので仕方ないのですが
他のSSOアプリケーションはアカウントが無い場合作成する挙動をすることが多いので
注意が必要です。

#### AD上のユーザのメールアドレスの問題

AWS SSOからG Suiteに渡されるE mailパラメータと
G Suite上のアカウントで登録されているアカウント名が一致している必要があります。
これだけであれば特に問題はないのですが
SSOに登録できるパラメータが少ない点を考えると悩ましい事になります。
私はRedash上のグループパラメータとしてE mailパラメータを利用する必要があったため
G Suite用にパラメータを1つあけることができませんでした。

そのため、ADのdisplay name欄をG Suiteのアカウント部分と一致させて
演算子でドメインを追加するという強引な方法を取っています。

ADのパラメータを自由に設定できる場合でも考える必要があるため
既存のADにつないでSSO管理する場合はパラメータを前もって考えておきましょう。

### 手順

他のアプリケーションと同じように、Applicationを作成しておきます。
Applicationの種類は「Custom SAML 2.0 application」ではなく「G Suite」を選択します。

#### G SuiteのSSO設定

https://support.google.com/a/answer/6349809

上記手順にしたがって設定を行います。

> [セキュリティ] > [シングル サインオン（SSO）の設定] をクリックします。

![aws_sso_0628_02.png](https://qiita-image-store.s3.amazonaws.com/0/146781/c34e454b-3f89-7cb4-bd1c-6782eba86ccc.png)

![aws_sso_0628_03.png](https://qiita-image-store.s3.amazonaws.com/0/146781/ff3a5cdd-7b04-385b-35c5-98f1855fa5ca.png)


> [サードパーティの ID プロバイダで SSO を設定する] チェックボックスをオンにします。

![aws_sso_0628_04.png](https://qiita-image-store.s3.amazonaws.com/0/146781/a6b7024b-3f2b-305e-e354-53c4af2a7692.png)

> サードパーティの ID プロバイダ（IdP）に対して次の URL を入力します。


AWS SSOコンソールの「AWS SSO metadata」欄から以下のように入力します。

| G Suite上の項目            | AWS SSO metadata上の項目                                              |
| ---                         | ---                                                                    |
| ログイン ページの URL      | AWS SSO sign-in URL                                                   |
| ログアウト ページ URL      | AWS SSO sign-out URL                                                  |
| パスワード変更 URL         | 以下に記載                                                    |
| 認証の確認                 | AWS SSO certificate から証明書をダウンロードし、G Suiteにアップロード |
| ドメイン固有の発行元を使用 | 必要なら入力してください（未検証）                                    |
| ネットワーク マスク        | 必要なら入力してください（未検証）                                    |

パスワード変更 URLに関しては、不明です。
パラメータから類推すると「AWS SSO issuer URL」が該当しそうですが、G Suite上のドキュメントには言及がありません。
そして、後述するAWS SSOのG Suiteドキュメント上にも言及がありません。
実際の入力欄には記載があります。
挙動も確認できていないので、私は未入力にしています。
（こちら、ご存知の方がいればお教えください）

#### AWS SSO上のG Suiteの設定

AWS SSOのG Suiteアプリケーション「Configure」タブ上の「Edit Configure」ボタンを押します。
ここで、「Configure G Suite」ページの上部にG Suite用のドキュメントが出てきます。
~~何故か~~URLにアプリケーションのIDが入っているので
こちらにはリンクを張りません。

![aws_sso_0628_06.png](https://qiita-image-store.s3.amazonaws.com/0/146781/34394936-ec2e-befe-5998-48e29864f540.png)

以下、ドキュメントに従い設定を行います。

#### アプリケーションパラメータ入力

「Application metadata」欄まで移動します。

「If you don't have a metadata file, you can manually type your metadata values.」ボタンを押し
手動設定に切り替えます。

![aws_sso_0625_05.png](https://qiita-image-store.s3.amazonaws.com/0/146781/0ef85272-8a94-ce44-0c04-9bf90a2728f2.png)

出てくる入力欄に以下のように値を入れます。

| タイトル                  | 値                                                                            | サンプル                                |
| ---                        | ---                                                                            | ---                                      |
| Application ACS URL       | https://www.google.com/a/ + G Suiteで運用しているドメイン + /acs              | https://www.google.com/a/example.jp/acs |
| Application SAML audience | google.com/a/ + G Suiteで運用しているドメイン                                 | google.com/a/example.jp                 |
| Application Start URL     | https:// + ( mail or drive ) + .google.com/a/ + G Suiteで運用しているドメイン | https://drive.google.com/a/example.jp   |

G Suiteのドメインですが、ドキュメント上では**<YOURDOMAIN>.com**という記載だっために
「example.jp.com」みたいな入力ルールの必要があるのかと試したのですがドキュメントの記載が違うようです。
通常運用しているG Suiteのドメインで良いでしょう。

また、Start URLはG MailかG Driveしか選択できません。
GCPダッシュボードやBigQueryが入力できたら便利だったのですが…。

ユーザポータルを介せず認証のみで使う場合には問題はないのですが
このあたりはアップデートでの対応待ちとなります。

#### 属性のマッピング情報を入力

注意点でも書いてますが、G Suiteへは登録済みのG Suiteのアカウント名を渡す必要があります。
最初から入力されてはいますが、SubjectとEmailパラメータにG Suiteのアカウント名を渡せるようにしておきましょう。

![aws_sso_0628_07.png](https://qiita-image-store.s3.amazonaws.com/0/146781/d3d6b347-243b-fbae-f8e7-a52eaa1219e0.png)


上記のようにパラメータと文字列をつなげることは可能です。
実際にどのようなパラメータが渡されるか確認したい場合は
ユーザポータルからShiftを押しながらアプリケーションを選択してデバッグすることも可能です。

#### アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

他のアプリケーションと同じです。
共通の欄を参照してください。

## Jenkinsへの導入

### 前提

JenkinsにSSOを導入することで、Jenkinsの管理を容易にすることができます。
特にJenkinsサーバが大量にある場合
ユーザポータルでまとめて管理することができるので
使い勝手がぐっと上がるでしょう。

JenkinsのSSO化にも注意があります。
SSO化すると、既存のユーザは利用できなくなり
SSO認証されたユーザのみが許可されます。

ユーザでの利用だけならいいのですが、
Jenkinsのコールを別システムなどから呼んでいる場合は注意が必要です。

### 手順

他のアプリケーションと同じく共通手順からカスタムアプリケーションを作成しておきます。

#### JenkinsのSAMLプラグインを導入

https://plugins.jenkins.io/saml
このプラグインをJenkinsに導入します。
Ansibleなどで導入するのがスマートですが
ここではGUIから設定する方法を記載します。

「Jenkinsの管理」から「プラグインの管理」に進み「利用可能」タブをクリックします。

![aws_sso_jenkins_01.png](https://qiita-image-store.s3.amazonaws.com/0/146781/ae1732c7-f43e-b022-4488-bc7f0b63fd19.png)

![aws_sso_jenkins_02.png](https://qiita-image-store.s3.amazonaws.com/0/146781/214b6df0-f671-7fe1-9016-c85a6fdffcbe.png)

![aws_sso_jenkins_03.png](https://qiita-image-store.s3.amazonaws.com/0/146781/e0ee03d2-a8cc-cd44-b314-757ad59700bf.png)

フィルターに「saml」と入力するとSAMLのプラグインが出てきます。
ここで、バージョンのアラートが表示される事があります。
要件にあうかは確認しておいた方がよいでしょう。

![aws_sso_jenkins_04.png](https://qiita-image-store.s3.amazonaws.com/0/146781/88f8e50f-a72c-f20d-f6fd-147bab3ce8d8.png)


大丈夫なら、インストールします。
私の環境では再起動は不要でした。

#### Jenkinsのセキュリティオプション変更

同じく「Jenkinsの設定」から「グローバルセキュリティの設定」を選択します。
		
「アクセス制御」から「ユーザー情報」を「SAML 2.0」に変更します。
この変更完了後、今までのユーザID・パスワードは利用できなくなるので注意してください。

![aws_sso_jenkins_06.png](https://qiita-image-store.s3.amazonaws.com/0/146781/a87e8c2f-2936-03d3-a483-1feb5e765e2b.png)

以下、パラメータを入力します。


| 項目                            | 説明                                                                                                                                                                     | サンプル                                       |
| ---                              | ---                                                                                                                                                                       | ---                                             |
| IdP Metadata                    | IdP(AWS SSO)のMetadataを入力します。AWS SSOのアプリケーションの設定から「AWS SSO SAML metadata file」をダウンロードし、貼り付けます。                                    | <?xml version ...                              |
| IdP Metadata URL                | IdP(AWS SSO)のMetadata URLを入力します。AWS SSOのアプリケーションの設定から「AWS SSO SAML metadata file」のURLをコピーし貼り付けます。上記どちらかで良いかもしれません。 | https://portal.sso.us-east-1.amazonaws.com/... |
| Refresh Period                  | IdPのMetadata更新間隔です。0だと更新しないようです。                                                                                                                     | 0                                              |
| Display Name Attribute          | Jenkinsのユーザ表示名に使われるSSOの属性です。                                                                                                                           | preferredUsername                              |
| Group Attribute                 | Jenkinsのユーザが所属するグループに使われるSSOの属性です。上記注意項目にあるように、emailを利用しています。                                                              | email                                          |
| Maximum Authentication Lifetime | userの認証保持期限だと思われます。初期値で運用しています。                                                                                                               | 86400                                          |
| Username Attribute              | Jenkinsのユーザ名に使われるSSOの属性です。                                                                                                                               | preferredUsername                              |
| Email Attribute                 | userのemailに利用するSSOの属性です。                                                                                                                                     | email                                          |
| Username Case Conversion        | Usernameを大文字小文字変換するかどうかです。                                                                                                                             | None                                           |
| Data Binding Method             | DataのBinding方法が選べるようです。AWS SSOの場合は標準の「HTTP-Redirect」で問題ありませんでした。                                                                        | HTTP-Redirect                                  |
| Logout URL                      | IdP(AWS SSO)のsign-out URLを入力します。AWS SSOのアプリケーションの設定から「SSO sign-out URL」をコピーし入力します。                                                    | https://portal.sso.us-east-1.amazonaws.com/... |
 		
入力が終わったら左下の「保存」ボタンを入力します。
また、この画面の中にSPのmetadataがダウンロードできる項目があります。

![aws_sso_jenkins_07.png](https://qiita-image-store.s3.amazonaws.com/0/146781/18c33da2-114c-38fe-d35a-ee063da1c113.png)

ここからSP metadataをダウンロードし保存しておきます。

#### アプリケーションパラメータ切り替え

AWS SSOのJenkinsアプリケーション「Configure」タブ上の「Edit Configure」ボタンを押します。
「Application metadata」欄まで移動します。

「Application SAML metadata file」に先ほどダウンロードしたSP metadataをアップロードします。
「Application start URL」欄にはJenkinsのエンドポイントを入力します。

#### 属性のマッピング情報を入力

マッピング情報を入力します。

| 項目    | 内容                                        | サンプル        | フォーマット |
| ---      | ---                                          | ---              | ---           |
| Subject | WindowsUPNが設定されるsubjectを入力します。 | ${user:subject} | unspecified  |

特に設定が不要に見えるのですが
初期設定のままSubjectの値が空白だと「Something went wrong and we could not sign you in ${APPLICATION NAME}」というエラーが出ます。
このエラーは直感的にわかりにくいのですが、マッピングがきちんと入力されているか確認しましょう。

#### アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

## Wordpressへの導入

### 前提

WordpressへのSSL認証は「OneLogin SAML SSO」プラグインを利用します。
このプラグインはOneLoginで使うために作られているのですが
SAML 2.0準拠のプラグインの中では一番しっかりと作られていそうです。

https://github.com/onelogin/wordpress-saml/blob/master/LICENSE
MITライセンスで作られているので、
ここではWordpressをSAML 2.0準拠のIdPに導入するという体で紹介します。

SAML 2.0を強制するかどうか、細かい権限設定など細かく設定できるので
他のサービスに比べSSO化のハードルは低そうです。

### 手順

#### Wordpressプラグインを導入

https://github.com/onelogin/wordpress-saml/releases
ここから、リリースのプラグインのzipをダウンロードします。
そして、Wordpressのプラグインのフォルダに展開します。

``` bash
$ ls -la /your/dir/wp-root/wp-content/plugins/onelogin-saml-sso/
total 48
drwxr-xr-x 4 user group 4096 Jun  1 00:00 .
drwxrwxr-x 9 user group 4096 Jun  1 00:00 ..
-rw-r--r-- 1 user group  219 Jun  1 00:00 alternative_acs.php
-rwxr-xr-x 1 user group 1554 Jun  1 00:00 icon.png
drwxr-xr-x 4 user group 4096 Jun  1 00:00 lang
-rw-r--r-- 1 user group 7260 Jun  1 00:00 onelogin.png
-rwxr-xr-x 1 user group 4083 Jun  1 00:00 onelogin_saml.php
drwxr-xr-x 5 user group 4096 Jun  1 00:00 php
-rwxr-xr-x 1 user group 5454 Jun  1 00:00 readme.txt
-rw-r--r-- 1 user group  249 Jun  1 00:00 version.json
```

#### Wordpressプラグインを設定

Wordpressの管理画面に入ります（一般的にはWordpressのエンドポイント＋wp-adminをつけたURLです）。
「設定」項目から「SSL/SAML Settings」項目を選択します。

![aws_sso_wordpress_01.PNG](https://qiita-image-store.s3.amazonaws.com/0/146781/b7ebfb27-ac07-eaf0-c825-5ca8b637a606.png)


![aws_sso_wordpress_02.PNG](https://qiita-image-store.s3.amazonaws.com/0/146781/dbacdee7-fe9d-4bd4-b1b0-bfb3c879b7b4.png)

以下の項目を設定します。

| 項目                                             | 説明                                                                                                                         | サンプル                                                            |
| ---                                               | ---                                                                                                                           | ---                                                                  |
| Enable                                           | チェックをつけるとSAML 2.0が有効になります。                                                                                 | :ballot_box_with_check:                                                                 |
| IdP Entity Id                                    | issuer URLを入力します                                                                                                       | https://portal.sso.us-east-1.amazonaws.com/...                      |
| Single Sign On Service Url                       | sign-out URLを入力します                                                                                                     | https://portal.sso.us-east-1.amazonaws.com/...                      |
| Single Log Out Service Url                       | 私はsign-out URLと同じ値を入力しました。                                                                                     | https://portal.sso.us-east-1.amazonaws.com/...                      |
| X.509 Certificate                                | IdPの証明書を入力します。AWS SSOの場合はダッシュボードからダウンロードしたものを貼り付けます。                               | -----BEGIN CERTIFICATE-----\n...                                    |
| Create user if not exists                        | ユーザが存在しない場合、新規ユーザを作成します。                                                                             | :ballot_box_with_check:                                                                 |
| Update user data                                 | IdPから送信された情報を元にユーザデータを更新するかどうかを設定します。                                                      | :ballot_box_with_check:                                                                 |
| Force SAML login                                 | SAML loginを強制するか選択します。チェックが外れている場合、既存のid/passwordでもログインできます。                          | :white_medium_square:                                                                 |
| Single Log Out                                   | ログアウト時にSSOポータルに移動するか選択します。チェックが外れている場合通常のログイン画面に遷移します。                    | :white_medium_square:                                                                 |
| Keep Local login                                 | 通常のログインフォームを維持するか選択します。チェックを入れている場合、通常のログインフォームにSAMLログインが追加されます。 | :ballot_box_with_check:                                                                 |
| Alternative ACS Endpoint                         | 別のログイン認証を有効にするときに必要なオプションのようです（未検証）                                                       | :white_medium_square:                                                                 |
| Match Wordpress account by                       | Wordpressのアカウントをどの属性でマッチさせるか選びます。「Username」と「Email」から選択できるようです。                     | Username                                                            |
| ATTRIBUTE MAPPING                                | SSOから渡された属性をどのパラメータにマッピングするか指定できます。                                                          | Username -> username  E-mail -> email Role -> email                 |
| ROLE MAPPING                                     | Roleが設定されているユーザをどの権限にするか設定できます。                                                                   | このサンプルではEmailがRoleになります。Administrator -> infra-group |
| Multiple role values in one saml attribute value | 権限を複数のロールベースにすることができるようです。（未検証）                                                               |                                                                     |
| Regular expression for multiple role values      | Multiple role values in one saml attribute valueを正規表現で表現できるようです。（未検証）                                   |                                                                     |


以下細かい設定ができます。
要件に合わせて適宜必要なものを選択してください。

#### IdP（AWS SSOなど）にmetadataを設定する。

WP上のSAMLプラグインの設定の上部から、SPのmetadataをダウンロードできるようになっています。
![aws_sso_wordpress_03.PNG](https://qiita-image-store.s3.amazonaws.com/0/146781/904f035c-ee9e-2af9-1066-ad5084ffd17b.png)

これをIdPの設定画面に入力します。
AWS SSOの場合は、上部Jenkinsの設定を参照してください。

「Application start URL」に関してはWordpressの管理画面のURLを入力してください。

#### 属性のマッピング情報を入力

マッピング情報を入力します。
One login Pluginの場合はWP上でもマッピングが設定できるので
ある程度柔軟に設定が可能です。

| 項目     | 内容                                        | サンプル        | フォーマット |
| ---       | ---                                          | ---              | ---           |
| Subject  | WindowsUPNが設定されるsubjectを入力します。 | ${user:subject} | unspecified  |
| username | WPのアカウントにあたる名前です。            | ${user:subject} | unspecified  |

#### アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

# さいごに

このように、SAML 2.0は各サービスごとに独自の実装や設定があるので
直感的には分かりづらいところもあります。
が、一度設定さえしてしまえばアカウントの運用がすごく楽になります。
みなさんも、ぜひSSO生活を！

AWS SSOのAD connection mapping、サポートするパラメータだけは増やしてほしいなぁ…。