2016年9月28日水曜日

Windows Server 2016のリリースとハイブリッドID基盤

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

アトランタで開催中のIgniteのタイミングに合わせてWindows Server 2016が正式にリリースされました。

 公式ブログでのアナウンス
 https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/

9月28日現在、評価版のダウンロードが先行して可能になっていますが、正式版の提供は10月に入ってからの様ですね。

と、いうことでとりあえず評価版をダウンロードしてセットアップし、ハイブリッドID基盤の構成を確認してみました。

以前Windows Server 2012R2のドメインコントローラとAzure AD、Windows 10を使って構成した構成ですね。

 [Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①
 http://idmlab.eidentity.jp/2016/01/windows-10azure-ad.html


結論から言うと特に変化点はありません。

以下のシナリオでいわゆるDesktop SSO(PCへのサインイン~ブラウザアプリケーションへのサインインがシームレスに行える)が実現できます。

- Windows 10へのサインインはPINで行われる
- ファイル共有へは従来通りKerberosで認証が行われる
- AD FSに関連づけられたアプリケーションへもKerberosで認証が行われる
- Azure ADに関連づけられたアプリケーションへはMicrosoft Passportで認証が行われる

軽く動画を撮ってみました。



ちなみに、このシナリオの中で1点Technical Preview 5のころのAD FSと異なるところは、ブラウザにEdgeを使ってもAD FSへのWindows統合認証ができるようになっているところです。

単純にWIASupportedUserAgentsにEdgeなどがデフォルトで追加されているだけですけどね。

PS C:\Users\Administrator> $a = (Get-AdfsProperties).WIASupportedUserAgents
PS C:\Users\Administrator> $a
MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
MS_WorkFoldersClient
=~Windows\s*NT.*Edge

そして、Technical Previewから変わらずに残念だったのが、AD FSの認証方式にMicrosoft Passportが選択できるにも関わらず、ブラウザアプリケーションでのSSOシナリオでは相変わらず使えないところです。

ここは別途、もう少し詳しく状況を解説したいと思いますので、とりあえずPINでログインしてもAD FSに関連づけられたアプリケーションへはMicrosoft Passport認証ではなく、Windows統合認証でSSOするしか現状は無い、ということだけ覚えておいてください。



設定関係も簡単に動画に撮っています。



そのうちもう少し細かく解説を加えて、Channel 9の別館の方にもアップしたいと思います。


2016年9月27日火曜日

[MIM]Microsoft Identity Manager 2016 SP1がリリースされました

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

2016年に入ってから細かくPreviewビルドが公開されてきたMicrosoft Identity Manager 2016(MIM)ですが、ついにService Pack 1がRTMとなりました。

これまでのリリースの履歴。3月、4月、6月にPreview版が出ていました。
 [MIM]June CTPで遂にExchange Onlineをサポート
 http://idmlab.eidentity.jp/2016/06/mimjune-ctpexchange-online.html

 [MIM]Microsoft Identity Manager April 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/04/mimmicrosoft-identity-manager-april.html

 [MIM]Microsoft Identity Manager March 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/03/mimmicrosoft-identity-manager-march.html


ConnectサイトやMSDNには先行して公開されていましたが、Igniteに合わせてリリースノートを含め正式に公開されました。ざっくり触った感じでは、これまでのPreview版の総まとめになっており、目玉は以下の点くらいです。(あとはPAMフォレストの構成とかコマンドレットの追加などです)
  • ワークフロー用のメールボックスにExchange Onlineのサポート
  • Chrome/Firefoxのサポート
  • 新バージョンのOS、SQL Server、SharePointのサポート

リリースノートはこちら
https://docs.microsoft.com/en-us/microsoft-identity-manager/understand-explore/microsoft-identity-manager-2016-sp1-release-notes

取り敢えずインストールして動作を見てみました。

バージョン表記は「4.4.1237.0」となっています。
しかし相変わらずForefront Identity Manager 2010 R2のままなんですね・・・
<Synchronization Service>


<Portal>



インストール中のメールボックス指定。Exchange Onlineが選択できるようになっています。



Chromeでのアクセス。Webページダイアログが以前とは変わっており、IE以外でも使えるようになっています。


Firefoxだと若干怪しいです。




後は色々とバグフィックスなどはありますが、その辺りはリリースノートが公開されてから、ということで。

2016年9月22日木曜日

[MSA]同一メールアドレスでマイクロソフトアカウントとAzure ADアカウントを利用するリスク

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

先日、職場または学校のアカウント(Azure Active Directory/Office365で管理されているアドレス)で新規にマイクロソフトアカウントをサインアップすることが出来なくなった、という話を紹介しました。

[MSA]職場または学校のアカウントで新規サインアップが不可に
http://idmlab.eidentity.jp/2016/09/msa.html


MPNやXBoxの開発関係など、まだAzure ADでのサインインをサポートしていないマイクロソフトのサービスが存在しているにも関わらず上記のような制限をかけたことについて、乱暴で性急な対応だ!という声も各国から上がっていますが、今回は逆にこれまでの様に複数のアカウントで識別子が共通になってしまっている状態だと何が起きえるのか?について考えてみたいと思います。


◆マイクロソフトアカウントでもAzure ADアカウントの両方でアクセスできるサービスを用意する

一番手っ取り早い方法として、Azure ADのOpenID Connectのv2 エンドポイントを使ったアプリケーションを開発してみます。

詳細は省くのとかなり手抜きなコードなので色々とツッコミどころはありますが、こんなコードを書きました。




◆アクセスする

v2 エンドポイントを使ったアプリケーションにアクセスし、ログインID(メールアドレス)を入力すると、ログイン用のIDをマイクロソフトアカウントとAzure ADアカウントから選択する画面が出てきます。



◆Azure ADのアカウントでログインする

まずは、Azure ADのアカウントでログインします。

職場または学校アカウントを選択すると、Azure ADのログイン画面へ遷移します。


結果、Azure ADからユーザ名をはじめとするID情報が取得できます。(id_tokenをほどいているだけですが)

preferred_usernameにログインIDが入っていることがわかります。


◆マイクロソフトアカウントでログインする

次にマイクロソフトアカウントでログインしてみます。
先ほどのID選択画面で個人のアカウントを選択すると、マイクロソフトアカウントのログイン画面へ遷移します。


結果、同じくID情報が取得できます。

同じくpreferred_usernameにログインIDが入ってきています。



◆何を注意すべきなのか?

上記の例では、どちらのアイデンティティ・プロバイダでログインしても同じ値がpreferred_usernameに入ってきてしまっています。この状態でユーザをpreferred_usernameで識別してしまうと便利な反面、セキュリティ面で問題があると言えます。個人でID登録できるマイクロソフトアカウントと管理者が登録・管理を行うAzure ADではIDの管理レベルが全く異なるからです。

上記のようなアプリケーションはB2BやB2Cのシナリオではそれほど珍しいものではありません。
アプリケーションが内部で自社のドメインのユーザからのアクセスならば管理メニューを出して、それ以外なら一般向けのメニューしか出さない、というようなロジックを書くこともあるためです。

通常は、自社ドメインのユーザは退職したら削除または無効化されログインできなくなるので、一見セキュリティ上問題はないように思われますが、退職前に自社ドメインのメールアドレスでマイクロソフトアカウントを作ってしまっていた場合、退職後も継続して管理メニューにアクセスできてしまうことになります。


今後は、マイクロソフトが新規にAzure ADやOffice365で使っているドメインのアカウントでマイクロソフトアカウントを作成することを禁止したので、すでにAzure ADやOffice365にドメインを追加している場合は、問題は減っていくとは思います。

ただ、
・現時点でAzure ADやOffice365に自社ドメインを追加していない
・すでに自社ドメインのアドレスでマイクロソフトアカウントを登録してしまっているユーザがいる
といった場合も多々あるはずなので、少なくとも「いくら信頼しているアイデンティティ・プロバイダとは言え、識別子だけで認可をすべきではない」ということを十分に認識してサービスの開発を行うべきだと言えるでしょう。

ちなみに、以前発生したOffice365のSAML SPの脆弱性も本質的には同じような問題に起因していましたね。

参考)
 Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点
 http://idmlab.eidentity.jp/2016/05/office365samlsp.html





2016年9月21日水曜日

[告知]ID Management Conference 2016で登壇します

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

先週末のID & IT Management Conference 2016に続き、10月初旬に東京と大阪でID Management Conference 2016が開催されます。

今年のID & IT Management Conference 2016では私はタイムテーブルに載らない裏トラックで新入社員~IDやセキュリティに関連する部門へ配属されて2~3年以内の方向けのセキュリティ・ID教育を担当しました。(完全招待性だったので、告知もしませんでした)



認証とID管理を新入社員向けに45分で解説するというのは中々のハードルでしたが、良い経験になりました。しかし、ID業界の老朽化や後継者問題が取り沙汰される昨今、非常に良い取り組みだと思いましたので、来年以降もこの取り組みは続けていきたいですね。



というわけで今年も無事にID & IT Management Conferenceは終了したのですが、早速次です。

次は、10月初旬に東京、大阪で開催されるID Management Conference 2016です。



以下、開催概要です。
今回、OpenIDファウンデーション・ジャパンでID連携・ID管理に関する解説をさせていただきます。東京はOpenIDファウンデーション・ジャパンの理事の林さん、大阪はEnterprise Identity Working Groupとして私が担当します。

イベント名:ID Management Conference 2016
イベントURL:
 http://www.f2ff.jp/idm/2016/

<大阪会場:富士榮>
日時:10月4日(火) ※セッションは17:05~17:45
場所:グランフロント大阪、ナレッジキャピタル・カンファレンスルーム
タイトル:エンタープライズにおける次世代ID連携標準
セッション内容:
 エンタープライズ企業においてもクラウド・サービスやモバイルデバイスの利活用に伴い、ネットワーク境界を超えてセキュアにID情報を連携する「ID連携」の重要性は増大しています。本セッションでは、OpenIDファウンデーション・ジャパンのEnterprise Identity Working Groupでの最新の成果物である「OpenID ConnectとSCIMのエンタープライズ利用と実装ガイドライン」を元に、企業におけるID連携の使いどころ、次世代のID管理/認証システムが対応すべきID連携標準技術について解説します。

<東京会場:林さん>
日時:10月5日(水) ※セッションは17:20~18:00
場所:KITTE、JPタワーホール&カンファレンス
タイトル:次世代ID連携標準によるAPIエコノミーの実現
セッション内容:
 パスワードによる認証が事実上有効性を失った今、認証の世界は大きく変わろうとしています。FacebookやGoogleを始めとしたソーシャルログインなどが台頭する中、ID連携への注目が高まると同時に、アイデンティティそして認証・認可の領域では、データ駆動社会の動きと共に様々な新しい動きもあり、制度や国際的な流れを踏まえて、APIを中心とした大きな動きが出てきています。本セッションでは、アイデンティティ分野の現在の状況と、技術的な動向、標準化の現状などを踏まえつつ、次世代のID管理/認証システムが対応すべきID連携標準技術について解説します。



開催まで約2週間ですが、ぜひ事前登録の上、ご来場ください。

2016年9月20日火曜日

[MSA]職場または学校のアカウントで新規サインアップが不可に

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

ID & IT Management Conference 2016の準備などで多忙だったので、色々とスルーしていた間にあった重要な発表を少しづつキャッチアップしていきたいと思います。

以下が9月上旬~中旬で発表された割と重要な発表です。(私基準です)

  1. マイクロソフトアカウント(MSA)へ職場または学校のアカウントで新規サインアップ不可に
  2. Azure Active Directory Premium P2の提供開始
  3. 新ポータルでAzure Active Directoryの管理が可能に
  4. MicrosoftとPing Identityの提携によるレガシーアプリへのSSO拡大
  5. Azure AD Connect 1.1.281.0のリリース


取り敢えず今回は1の「マイクロソフトアカウント(MSA)へ職場または学校のアカウントで新規サインアップ不可に」をお届けします。

9月15日に公式アナウンスが出てきました。(割と突然だったので私もびっくりしました)

 Cleaning up the #AzureAD and Microsoft account overlap
 https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/


早速内容を見ていきます。

◆これまでの課題

マイクロソフトのサービスを利用するには、職場また学校のアカウント、つまりOffice365やAzure Active Directory(Azure AD)で管理されているアカウント、もしくはマイクロソフトアカウント(従来のLive ID。MSA)を使ってログインする必要があります。

ただし、マイクロソフトアカウントはlive.comやoutlook.comなどマイクロソフトが用意しているドメイン以外に既存のメールアドレスを使ってサインアップすることも可能でした。


ここでOffice365やAzure ADのアカウントを使ってサインアップすると同じユーザ名のアカウントが職場または学校のアカウントおよびマイクロソフトアカウントの両方に出来上がることになり、マイクロソフトの提供するサービスへログインする際に以下のようなアカウント選択画面が表示されてしまいました。



これは一般利用者にとってわかりにくく、しばしば混乱を招いてきました。


◆今回のマイクロソフトによる対策のポイント

かなり乱暴な対策ではありますが、すでにOffice365やAzure ADで管理されているドメインのメールアドレスを使って、新規にマイクロソフトアカウントへサインアップすることが出来なくなりました。

これで新規ユーザは同じユーザ名でOffice365/Azure ADとマイクロソフトアカウントの両方にIDが作成されることは無くなりますので、ID選択画面が表示されることは無くなります。


では、既に作成済みのアカウントや、後からOffice365/Azure ADにドメイン追加されたアカウントの場合はどうなるんでしょうか?

結論、既存のマイクロソフトアカウントのIDを変更する、というのが答えです。


◆既存のマイクロソフトアカウントのIDを変更する

注意点を含む詳細はこちらのページで解説されていますので、確認して対応してください。

基本は既存のアカウントに新しいメールアドレスをエイリアスとして追加、プライマリ側と入れ替えた後、Office365/Azure ADと重複しているメールアドレスを削除するという方法です。


◆影響があるサービスがあるので注意

公式ページにも記載がありますが、職場のメールアドレスでサインアップしたマイクロソフトアカウントでないと利用できないマイクロソフトのサービスが一部あるので、職場のメールアドレスがOffice365/Azure ADで利用しているドメインと一致している環境においては、マイクロソフトアカウントのメールアドレスを切り替えるとそれらのサービスが使えなくなります。(新規にはサインアップすらできないので、当該環境において新規ユーザはそれらのサービスを使うことは出来なくなっています)

例えば、
・Windows Dev Center
・Microsoft Partner Network
などに影響があるようです。

また、既存のアカウントのメールアドレスを変更することによりデバイスのリセットなどをする必要がある場合もあるので、こちらも要注意です。

例えば、
・Windows Phone 8を使っている場合はデバイスのリセットが必要になります
・一部XBox開発ツールを使っている場合は別のIDになってしまいますので、実質アカウント作成し直しとなります
などが大きな影響といえます。


◆まとめ

MSALやv2エンドポイントなどAzure ADアカウントとマイクロソフトアカウントのコンバージが進む一方で、IDの重複問題が長年の懸案事項となっていたので、今回の対策は長い目で見れば非常に有益なことだと思います。
そもそも同じ識別子を持つ複数のIdPで同じサービスが利用できてしまうというのは、保証レベルの面などセキュリティ的にも重大な問題でした。例えば、個人の自己申告でサインアップできてしまうマイクロソフトアカウントを在職中に作成、退職後も継続的に利用しているケースにおいて、いくらAzure AD側で退職アカウントを削除したとしても、MSALを使ったコンバージ・アプリケーションへ職場のメールアドレスを使ったサインインが継続的に可能になってしまう、という課題です。

他方でMPNなど重要なサービスが職場メールアドレスのMSAでしかアクセスできないなど、過渡期に解決すべき課題もあるので、若干性急な気もした今回の対策ですが、早期に各サービス側での対応をすすめ、一日も早く綺麗な姿でサービスを提供できるようになってもらいたいものです。











2016年8月22日月曜日

[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とマッピングする際は値のフォーマットを合わせる必要がある






2016年8月19日金曜日

[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
ユーザーIDNameIDurn:oasis:names:tc:SAML:2.0:consent:unspecified
SAML属性urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
ユーザーの電子メールアドレスNameIDurn: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を使ったパターンを解説したいと思います。