[SAML]Oracle CloudとのSSOを構成する～AD FS編

こんにちは、富士榮です。

色々なクラウドサービスとフェデレーション、シングルサインオンを構成してみるコーナーです。
今日はAD FSを使ってOracle CloudへのSSOできるように構成してみたいと思います。（別途Azure AD編も公開予定です）

◆Oracle Cloudとは

POCO（Power Of Cloud by Oralce）ってやつですね。SaaS、PaaS、IaaS、DaaS領域でOracleが提供しているソリューションをクラウドで提供しているものです。（DaaSがあるあたりがOracleらしいですね）
例えば、SaaSだったらHRとかSCM、ERPなど、PaaSだとJava実行環境、IaaSならCPU、ネットワーク、ストレージ、DaaSはデータそのものだったりします。

この辺りに概要が説明されており、30日間のトライアルを申し込むことが出来ます。
http://www.oracle.com/jp/cloud/overview/index.html

◆Oracle Cloudのユーザ情報の持ち方とシングルサインオン対応

Oracle Cloudではユーザを識別するのに、ユーザIDもしくは電子メールアドレスを使います。
（この電子メールアドレスは実際にメールが届くアドレスである必要があります）

そして、シングルサインオンを行うための手段としてエンタープライズ・クラウドらしくSAMLに対応しており、上記の識別子であるユーザIDもしくは電子メールアドレスをIdPから受け取ることでシングルサインオンが成立する仕組みになっています。

ユーザ情報の持ち方と識別子の考え方、IdPで発行されるSAML Assertionの中の値との関係性は以下の図の通りとなっています。

◆シングルサインオンを構成する

では、早速SSOの構成をしてみたいと思います。最初に書いた通り、今回はSAML IdPとしてAD FSを使います。（手元にあったのがWindows Server 2016 Technical Preview 5のAD FSなので本稿ではPreview版のAD FSを使いますが、Windows Server 2012R2でも基本的には変わりません）

まず、Oracle Cloud側の設定を行います。

管理者アカウントでログインし、まずはSSOさせるユーザを作ります。
尚、デフォルトで電子メールとユーザ名は同じもの（電子メール）を使うようになっているのですが、色々なパターンを確認したいので、今回は電子メールとユーザ名は別々の文字列を使うことにします。

次にSSOの構成画面へ遷移します。
SSO設定は何故かユーザメニューの中にあります。

ユーザメニューを開くとSSO構成というタブがあります。

シングルサインオンを構成する画面が出てきます。

早速IdPの設定を入れてみたいと思います。
Oracle CloudはMetadataを使った設定をサポートしているので、まずはAD FSのFederationMetadataを取得します。
https://ADFSサーバ名/FederationMetadata/2007-06/FederationMetadata.xml
にアクセスするとXMLがダウンロードされてきますので、これを使います。
ちなみに、Internet ExploreだとXML自体が開いて表示されてしまうので、私はいつもFireFoxを使っています。FireFoxだと直接ダウンロードが走るので。

MetadataをダウンロードしたらOracle CloudのSSO構成画面を開き、Metadataをアップロードします。

次に、先にも説明したとおり、識別子としてユーザIDを使うか電子メールアドレスを使うか、SAML Assertionのどこに識別子の値が入ってくるのかを指定します。

まず、識別子を選択します。

次に格納場所を選択します。

ちなみに、SAML属性を選択した場合はAssertionの中のAttribute Statementにある属性名URIを指定する必要があります。

尚、ここで重要な注意点です。
Oracle Cloudは識別子にユーザIDを、格納場所にNameIDを指定した場合にはnameid-formatとしてunspecifiedでよいのですが、それ以外の設定を行った場合はnameid-formatにemailaddressを指定する必要があります。
また、格納場所にSAML属性を選択したとしてもNameID自体には値を入れてあげる必要があります。（実際のユーザの識別には使われないので任意の値でOKです。ただし、nameid-formatにはemailaddessを指定する必要があります）

ケース毎に以下の通りのフォーマット指定が必要になります。

ユーザー識別子	格納場所	NameID Format
ユーザーID	NameID	urn:oasis:names:tc:SAML:2.0:consent:unspecified
	SAML属性	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
ユーザーの電子メールアドレス	NameID	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
	SAML属性	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

さて、話が逸れましたが、以上でSP側（Oracle Cloud側）の設定は終わりなので、次はIdP側（AD FS側）の設定を行います。

同じく、AD FSもMetadataを使った設定ができるので、Oracle CloudからSP側のMetadataをダウンロードし、AD FSへ読み込ませます。

Oracle Cloud側でMetadataのエクスポートを行います。

このMetadataを使ってAD FSにSP登録（証明書利用者信頼）を行います。

設定ウィザードの中で先ほどダウンロードしたMetadataを指定します。

これで登録自体は終わるので、あとはAD上のユーザのどの属性をAssertion上にどうやって乗せるか？の設定を行います。

まず、AD上のユーザですが、以下のように作成してあります。
・sAMAccountName : nfujie
・mail : naohiro.fujie@eidentity.jp

まずは、Assertion内のNameIDにログインID（nfujie）をマッピングしてみます。
SPのセットアップが終わると、要求発行ポリシーのウィザードが起動するので、新規ルールを作成します。

ADのユーザを元にAssertionを構成するので、LDAP属性を要求として送信というテンプレートを使用します。

AD上のsAMAccountNameをNameIDにマッピングするので、以下のようなルールになります。

これで設定は完了です。

Oracle Cloudの管理画面に戻り、SSOのテストを行います。

テスト用の画面が開くので、Start SSOをクリックします。

クリックするとAD FSのログイン画面へリダイレクトされるので、ADのユーザでログインします。

すると、Authentication Failed。。。。エラーですね。

これが2つ目の注意点です。
Oracle CloudからダウンロードしたMetadataを見ると署名アルゴリズムにSHA1を使うように指定がされているのですが、AD FSで発行されたSAML Assertionの中を見るとSHA256で署名されており、このアンマッチが原因で検証に失敗し、エラーとなっているようです。

Oracle CloudのMetadata内の署名アルゴリズムの指定

AD FSで発行されたAssertionの中身

これはAD FSの昔からのバグ？でMetadataを読み込んでRPを作成する場合、署名アルゴリズムがMetadataの中の指定を無視して自動的にSHA256になってしまいます。
と、いうことでAD FS上で署名アルゴリズムをSHA1に設定し直します。

これで再度テストを行うと、今度は成功しました。

これで全ての設定が完了したので、Oracle Cloud側でSSOを有効にします。

確認が求められます。

◆実際にSSOでログインする

テストもうまくいったので先に作成したユーザをログオンしてみます。
ログオン画面を開くと、SSOが有効になっている環境ではCompany Sign Inというボタンが出てきますので、SSOしたい場合はこのボタンをクリックします。

すると、AD FSにリダイレクトされるので、ADのユーザでサインインします。

ログオンに成功するとOracle Cloudへ戻ります。意図したユーザでログインできていることがわかります。

◆他のバリエーションも試してみる

ここからはオマケですが、識別子と格納場所を他のパターンにした場合にどの様な設定を行う必要があるか確認してみます。

まずは、識別子に電子メールアドレスを使うパターンです。格納場所はNameIDのままにします。
この場合は、先の表にもある通り、nameid-formatを指定する必要があります。

AD FSではnameid-formatを指定するにはプロパティを当該クレームに対して付加する必要があるので、クレームを発行するルールのあとにプロパティを付加するルールを追加します。

まずは、電子メールをNameIDにマッピングするルールを設定します。

この後に、カスタム規則のテンプレートを使いルールを一つ追加します。

設定するルールはクレーム記述言語で記載する必要があります。
以下の内容を設定します。

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

これで、問題なく動作します。

ちなみにこのnameid-formatの追加をしない状態でSSOテストを行うと、Invalid NameIDFormatというエラーが出ます。

うまくいった場合のAssertionにはちゃんとnameid-formatと値が入っていることがわかります。

次に格納場所をNameIDからSAML属性へ変更してみましょう。

先のSSO設定で格納場所をSAML属性にし、属性名にAssertion上の属性URIを設定します。

後は、AD FS側もこれに合わせて属性のマッピングを作ればOKです。上記例ではwindowsaccountnameという属性にユーザIDの値がマッピングされていればOKなので、NameIDのルールに加えて、一つルールを設定します。

これを既存のNameIDおよびフォーマット設定のルールのあとに追加します。

テストするとAssertionに意図した属性が乗ってきており、SSOに成功することがわかります。

◆まとめ

AD FSを使ってOralce Cloudとのシングルサインオンを構成する場合、以下に注意が必要ですが、割と簡単につながります。
・AD FS側に設定する署名アルゴリズムを手動でSHA1に修正する必要がある
・識別子にユーザID、格納場所にNameIDのパターン以外ではnameid-formatにemailaddressを指定する必要がある



次回は、Azure ADを使ったパターンを解説したいと思います。