[SAML]Oracle CloudとのSSOを構成する～Azure AD（Premium）編

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

前回に引き続きOracle Cloudとのシングルサインオンを構成していきます。今回はIdentity ProviderとしてAzure ADを使ってみます。

　参考：前回の記事）
　　　[SAML]Oracle CloudとのSSOを構成する～AD FS編
　　　http://idmlab.eidentity.jp/2016/08/samloracle-cloudssoad-fs.html


尚、基本的な考え方や構成は前回の記事で解説したものと変わりませんので、前回の記事を読んでいない方は、先に前回の記事を読んでください。

◆構成するにはAzure AD Premiumが必要

尚、初めに結論を書きますが、Oracle Cloudとのシングルサインオンを構成するには、タイトルにある通りAzure AD Premiumのライセンスが必要となります。

これまでも書いてきたとおりAzure AD自身は、無償版であってもSAMLのエンドポイントが使えるのでSAML SPとのシングルサインオンを構成することが出来ます。

ただ、現在のところ何故かOracle Cloudとのシングルサインオンは無償版では動作させることが出来ませんでした。（後述しますが、Oracle CloudのAssertion Consumer ServiceへSAMLアサーションをPOSTしたところでシステムエラーが出ます。私のやり方が悪いだけかもしれませんが、POSTされているSAMLアサーションの中身はAzure AD Premiumで構成したものと変わらないので、何が違うのかよくわかっていません）

では、早速構成してみます。

◆Azure ADへOracle CloudをSAML SPとして登録する

他のアプリケーションと同様にAzure ADのギャラリーからアプリケーションを追加し、Oracle CloudのSAMLに関連するパラメータを入力、SPとして登録を行います。

カスタムアプリケーションを追加します。

アプリケーションの作成が完了したら、シングルサインオンを構成します。
まずはシングルサインオンの構成としてAzure ADのシングルサインオンを選択します。

次に、Oracle Cloudの以下の情報を登録します。

EntityID　：　Oracle Cloudの識別子
Assertion Consumer Service URI　：　SAML AssertionをPOSTする先のURI

これらの情報はOracle CloudのSSO設定の中に記載されているので、コピー＆ペーストします。

少しずつ言葉が違いますが、

• EntityID＝Oracle Cloud上の「プロバイダID」＝Azure ADにセットする「識別子」
• Assertion Consumer Service URI＝Oracle Cloud上の「アサーションコンシューマーサービスURL」＝Azure ADにセットする「応答URL」

です。

次に進むと、Azure ADに関する情報が表示されますので、メタデータのダウンロードをしておきます。ダウンロードが終わったら一番下のチェックボックスにチェックを入れてウィザードを終了させてしまっても大丈夫です。

◆Oracle CloudへAzure ADをSAML IdPとして登録する

次は、反対にOracle Cloud側へAzure ADを登録します。
SSOの構成ページを開き、先ほどダウンロードしたAzure ADのメタデータをアップロードします。

これで構成は完了です。

◆ユーザの割り当てとテスト

早速テストを行いますが、その前にAzure AD側でユーザの割り当てを行っておきます。もちろんOracle Cloud側にも対象のユーザを作っておく必要もあります。

Azure ADのアプリケーションの構成でユーザの割り当てを行います。

SSOの動作試験は前回の記事と同様にOracle CloudのSSO設定ページから行うことが出来ます。

Start SSOのボタンをクリックするとAzure ADのサインイン画面へリダイレクトされるので、ログインします。

ログインが完了するとOracle CloudへSAMLアサーションがPOSTされ、シングルサインオンが完了します。

◆他の属性マッピングのバリエーションを試す

Azure ADを使った場合もAD FSの場合と同様に他の属性を識別子にマッピングすることも可能です。

例えば、識別子を電子メールアドレスにし、NameIDに格納する場合は以下のような設定になります。尚、Azure ADではNameIDの値はUserPrincipalName（メールアドレス形式）でnameid-formatはemailaddressなので、AD FSの場合のようにカスタムプロパティの設定を行う必要はありません。

また、SAML属性に入っている値を識別子にマッピングする場合は以下のように設定します。
この場合も特別なマッピングルールを作ったりプロパティの設定を行う必要はありません。

全体にAD FSを使うよりも楽に設定できる感覚があります。

◆Azure AD Premiumがない場合はどうなるか？

冒頭に書いた通り、上記はAzure AD Premiumのライセンスを保持している場合の設定の方法です。（具体的にはPremiumライセンスがないと、ギャラリーからカスタムアプリケーションの追加が出来ません）

ただ、無償版であってもSAMLのエンドポイント自体は有効なので自力でSPを登録すれば、SAMLアプリケーションとのシングルサインオンを構成すること自体は可能です。
（現に、MS松崎さんがsimplesamlphpを使ったSPとの連携を無償版の機能だけで実現しています。関連ポストはこちら）

しかし、Oracle Cloudで同様の手順を実施したところ、SAMLアサーションの発行まではうまくいきますが、Oracle CloudのAssertion Consumer Serviceがうまくアサーションを受け取ってくれませんでした。

これは推測ですが、SAML SSOエンドポイントアドレスがPremiumでのカスタムアプリケーション追加で作成した場合はlogin.windows.net、無償版で作った場合はlogin.microsoftonline.comとなっており、自動的にリダイレクトされるので差異はないと思うのですが、微妙な機能差があるのかもしれません。（無償版のメタデータのエンドポイントをwindows.netに書き換えても同じエラーになるので違うのかもしれませんが）


参考までに手順と結果を載せておきます。（ここが間違ってるよ！という情報などあればぜひ！！）

まずはアプリケーションの追加をしますが、ギャラリーからではなく、組織で開発中のアプリケーションを選択します。

アプリケーションの種類はWebアプリケーションにします。

アプリケーションのプロパティには以下をセットします。

• サインオンURL　：　Oracle CloudのアサーションコンシューマサービスのURL
• アプリケーションID/URI　：　Oracle CloudのプロバイダID

次に、Oracle Cloud側にAzure ADの情報を設定しますが、ギャラリーからのアプリケーション追加ではないので、メタデータをウィザードから取得することが出来ません。
そこで、画面の下部にあるエンドポイントメニューよりFederationMetadataを取得し、Oracle Cloudへアップロードします。

このURLへアクセスし、表示されるXMLを保存します。

設定はこれで終わりなので、先ほどと同じ手順でテストをします。
尚、この手順で作成した場合はデフォルトではAzure AD側でのユーザ割り当ては不要です。

Start SSOをクリックすると同じくAzure ADのログイン画面へリダイレクトされます。

サインインすると、Oracle CloudのアサーションコンシューマサービスへSAMLアサーションがPOSTされますが、システムエラーが出てしまいます。

普通にOracle Access Managerなんですね。
SAML Tracerで上記のPremiumを使ったうまくいくパターンと無償版を使った失敗するパターンの両方のSAMLアサーションをトレースしてみたんですが、変わった点は見当たらず、何が原因なのかはよくわかっていません。
Oracle Cloud側へのAzure ADの情報登録もメタデータを使わず手動で構成したり、メタデータの不要な部分の削除など色々と試してはいるのですが、今のところ解決の糸口はつかめず。。。

◆まとめ

AD FSを使った場合に比べ、Azure ADをIdPとして使った場合は簡単に構成することが出来ます。しかし、以下の注意点があります。

• Azure AD Premiumライセンスが必要
• Azure ADのログインIDはUserPrincipalNameなのでOracle CloudのログインIDとマッピングする際は値のフォーマットを合わせる必要がある

[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を使ったパターンを解説したいと思います。