2013年12月31日火曜日

[OAuth]年末大掃除。Facebookへのアクセス許可の整理

番外編です。
年末なので色々とPC環境やFacebook等の設定の整理をしています。

Facebookを使っていると、色々なアプリケーションやWebサイトに「いいね!」をしたり、プロフィール情報の読み取りや投稿許可を与えたりしてしまう(せざるを得ない)事があると思います。(この辺りがOAuthです)

あんまりアクセス許可を与えっぱなしにしておくのも気持ちが悪いのでいい機会なのでまとめて整理をしてしまいましょう。

まずは、「いいね!」をしてしまったWebサイトやFacebookページの整理です。

自分のプロフィールのアクティビティを開きます。

左下に「ページと趣味、関心」があるので、開きます。

色々なページに「いいね!」をしているのがわかります。
「いいね!」を取り消すにはそれぞれにある鉛筆マークをクリックします。
※実際にJICSのサイトの「いいね!」を消したらダメですよ(これ重要)



次に、アプリに与えてしまった許可の整理です。

こちらはプライバシー設定の中にあります。
画面右上のメニューからプライバシー設定を開きます。


続いてプライバシー設定画面の左下のアプリを開きます。

すると許可を与えたアプリの一覧が表示されます。
結構な数のアプリを使ってます。


ここで編集をクリックすると具体的にどんな許可を与えているのかをみることができます。

Amazonアプリ、結構な権限を要求してきています。。。。
ここで不要だと思ったら×をクリックして権限ごとに削除してしまうのも良いですし、アプリケーション単位で許可を取り消してしまうこともできます。

でも、消す前に具体的にアプリがいつ、何をしたのか?について見たければ、最終アクセスの中の「詳細を見る」をクリックすると履歴が見れます。

ちょこちょこ覗かれてますね。

信頼できるアプリやページであればいいですが、間違って許可を与えてしまった場合などはこの辺りで適切に管理をしてあげましょう。



と、いうことで年末の大掃除の一環でFacebookの権限周りを整理してみました。
皆さんもこの機会にぜひ大掃除をして良い年をお迎えください。

今年もお世話になりました。

2013年12月22日日曜日

出ました!「OpenID Connect と SCIM のエンタープライズ利用ガイドライン」

OpenID、OpenID Connect、OAuth、SCIM なんていうキーワードが出てくると中々一般企業での利用のイメージがわかないのが現実だと思います。

OpenIDファウンデーション・ジャパンでは、そんな危機感の元、エンタープライズ・アイデンティティ・ワーキンググループというものを立ち上げて、企業内で OpenID Connect や SCIM の利用を促進するにはどうすれば良いのか?の検討を重ねてきました。
(以前から私も参加している日本ネットワークセキュリティ協会 / JNSA のアイデンティティ管理ワーキンググループとの共同ワーキングなので、私は両方の顔で参加しています)

実は本業が忙しく、それほどどっぶりと成果物を作成する作業には入れなかったのですが、みなさんの努力の結果、「OpenID Connect と SCIM のエンタープライズ利用ガイドライン」という形で資料を公開することが出来ました。

OpenID ファウンデーション・ジャパンの Web ページからダウンロード出来ます。

 OpenID ファウンデーション・ジャパンのお知らせページ


目次を一部ご紹介しますと、、
  • エンタープライズITにおけるフェデレーション標準プロトコルとアイデンティティ・プロビジョニング標準プロトコルの有用性
  • フェデレーション標準プロトコル~OpenID Connect解説
  • アイデンティティ・プロビジョニング標準プロトコル~SCIM解説
  • フェデレーションとアイデンティティ・プロビジョニング標準プロトコルの日本エンタープライズITへの適用
  • OpenID Connect/SCIMユースケース
  • 関連技術/概念

内容的に、日本のエンタープライズITの独自の事情について記載があったり、OpenID Connect / SCIM の技術解説があったり、関連技術としてのトラストフレームワークの話があったり、と盛りだくさんなので技術者の方にも、そうでない方にとっても役に立つ資料になっていると思われます。

OpenIDファウンデーション・ジャパンの会員企業になるともう少し深い内容について情報入手が可能ですが、今回一般に公開されたものでもかなり有用なので是非、ご覧下さい。


2013年12月18日水曜日

[FIM2010]いよいよ次世代へのロードマップが見えてきた

MIIS(Microsoft Identity Integration Server)からILM(Identity Lifecycle Manager)、ILMからFIM(Forefront Identity Manager)へと名前を変えてきたこのプロダクトですが、次の方向性がようやく見えてきました。

参考)FIMの歴史。以前.NETラボのセミナで使ったスライド


2013/12/17付けの Technet の Server & Cloud Blog で次の製品の方向性が発表されています。

 Important Changes to the Forefront Product Line
 http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx


blog によると、2015年の第1半期にメジャーリリースが出て、

  • Windows Azure Active Directoryとのハイブリッドシナリオ
  • ユーザとアクセス管理
  • 監査とコンプライアンス

というあたりがキーワードになりそうです。

追って詳細情報も出てくると思われるので、続報があれば書いていきたいと思います。


2013年12月10日火曜日

[WAAD/IDMaaS]SaaSアプリケーションのID管理をクラウドで行う「ハイブリッド ID 管理」

# Windows Azure Advent Calendar 向けポストです。

Windows Azure Active Directory(WAAD)のアプリケーション統合の機能を使うと Google Apps や Salesforce.com などの各種 SaaS アプリケーションへのシングルサインオンやプロビジョニングを WAAD 経由で実施することができます。いわゆる、IdMaaS(Identity Management as a Service)というやつです。

WAAD のアプリケーション・パネル(https://myapps.microsoft.com


今回はこの機能をうまく使って、企業などの組織が行ってきた各種サービスへの個別の ID 管理やシングルサインオン環境構築をどこまで省力化できるか、を検証してみたいと思います。


前提となる環境、利用する機能は以下です。

  • WAAD のアプリケーション統合機能
  • 先日発表された WAAD Premium の機能である、アプリケーションへのグループの割り当て機能(現在プレビュー)
  • 社内の ID 情報ソースと WAAD のアカウントおよびグループ同期(ディレクトリ同期ツールや Forefront Identity Manager/FIM の WAAD コネクタなど)もしくは WAAD Graph API によるアカウント・グループ管理(今回は Graph API を利用)



では早速始めます。

◆IdM をオンプレミスで構築する(おさらい)

例えば、Google Apps や Salesforce.com などのクラウド・サービスの ID を社内から管理したいと考えた場合、FIM をはじめとする ID 管理製品の各種サービスとのコネクタを構築(もしくは購入)して、それぞれのサービスと接続して ID 情報を同期する必要がありました。

参考)FIM2010 用の GoogleApps コネクタ
 https://fim2010gapps.codeplex.com/


◆IdMaaS の登場

各種 SaaS サービスと個別に接続する、というアプローチは非常に柔軟ですが、一方で各サービスのインターフェイスや API の変更へ追従していくのが非常に大変、、という側面を持ちます。
そこで、各種 SaaS サービスとの接続自体をクラウド・サービスとして提供しよう、という考え方である、Identity Management as a Service(IdMaaS)という考え方が登場し、Microsoft の Windows Azure をはじめ、PingIdentity の PingOne や Salesforce の Salesdorce Identity や Intel/McAfee の Intel Cloud SSO など各種サービス業者がサービスを展開し始めています。

参考)これまで紹介してきたエントリ
Windows Azure Active Directory(http://www.windowsazure.com
 [WAAD] IDaaS としての機能が充実してきた
 http://idmlab.eidentity.jp/2013/07/waad-idaas.html

PingOne(https://www.pingone.com/
 [IDaaS]PingIdentity Cloud Desktop で便利ライフ
 http://idmlab.eidentity.jp/2013/10/idaaspingidentity-cloud-desktop.html

Intel Cloud SSO(http://www.intelcloudsso.com
 [IDaaS] Intel Cloud SSO を試してみた
 http://idmlab.eidentity.jp/2012/05/idaas-intel-cloud-sso.html


◆IdMaaS で ID 管理を楽にする

WAAD をはじめ、各種 IdMaaS サービスには各種 SaaS サービスへのプロビジョニング機能があるため、こんなことが成立します。



これであれば、社内の ID 管理システムは IdMaaS とさえ接続しておけば、あとは IdMaaS 側でインターフェイスの保証などをしてくれるので、社内の ID 管理システムを個別に各システムと接続する必要も、各サービスのインターフェイスや API の更改に神経をとがらせる必要もありません。


◆IdMaaS の運用をどこまで自動化できるのか

ここまでで勘の良い方ならお分かりだと思いますが、IdMaaS への ID 同期とその先の各種サービスへのプロビジョニングをどこまで細かく制御できるのか?という課題が出てきます。
一般的な ID 管理システムではここでいう IdMaaS への接続と同期はコントロールできても、その先のコントロールについては IdMaaS 側にお任せ、ということになるはずです。

となるとオンプレミスの ID 管理システムや運用システムから IdMaaS の管理をどこまで自動化できるかがポイントになってきます。


◆WAAD の場合。Graph API の活用?

WAAD の場合は個人 ID などのディレクトリ上のオブジェクトの操作をプログラムから行うための API として Graph API を提供しています。

参考)[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
 http://idmlab.eidentity.jp/2012/12/office-365-waad-graph-api.html
 ※ちょうど一年前の Advent Calendar 向けの記事

例えば、特定のユーザに Google Apps など WAAD と統合されたアプリケーションを使わせたい、と考えた場合はこの Graph API で、対象ユーザへアプリケーション割り当てを行うことができれば、オンプレミスの ID 管理ツールから WAAD およびその先にあるサービスへのプロビジョニングまでをコントロールすることが出来そうです。

先月新バージョンがリリースされた Graph API の機能の概要を metadata エンドポイントを探索することで確認してみます。

2013/11/08 版 API)
 http://blogs.msdn.com/b/aadgraphteam/archive/2013/11/14/announcing-the-new-version-of-the-graph-api-api-version-2013-11-08.aspx


要するに WAAD と統合したアプリケーションに Graph API からアクセスできれば良いので、アプリケーションに関するどんな操作が可能かを調べてみます。

アクセストークンを WAAD の OAuth2.0 の Token エンドポイントから取得して Authorization ヘッダにセットした状態で、Graph API の metadata にアクセスしてみます。

metadata の確認は以下の URL へ GET します。
https://graph.windows.net/<テナントドメイン名>/#metadata?api-version=2013-11-08

すると、以下の答えが返ってきます。
{
    "name" : <テナントドメイン名>",
    "services" : [
       "https://graph.windows.net/<テナントドメイン名>/users",
       "https://graph.windows.net/<テナントドメイン名>/applications",
       "https://graph.windows.net/<テナントドメイン名>/contacts",
       "https://graph.windows.net/<テナントドメイン名>/groups",
       "https://graph.windows.net/<テナントドメイン名>/roles",
       "https://graph.windows.net/<テナントドメイン名>/servicePrincipals",
       "https://graph.windows.net/<テナントドメイン名>/tenantDetails",
       "https://graph.windows.net/<テナントドメイン名>/devices",
       "https://graph.windows.net/<テナントドメイン名>/subscribedSkus",
       "https://graph.windows.net/<テナントドメイン名>/permissions",
       "https://graph.windows.net/<テナントドメイン名>/directoryObjects"
    ]
}


Windows Server 2012 R2 から実装された Device Registration Service(DRS)に関するエンドポイントも存在しています。いよいよ WAAD 側でも DRS が実装されるようです。

今回はアプリケーション統合関係なので /appication というエンドポイントを見てみます。
まずは一覧を GET してみます。

https://graph.windows.net/<テナントドメイン名>/applications?api-version=2013-11-08

を GET すると、WAAD に統合したアプリケーションに関する情報が JSON 形式で出てきます。

が、ここで表示・管理できるのは、組織で開発中のアプリケーション、つまり Google Apps や Salesforce.com などの SaaS アプリケーション以外の自作アプリケーションや API に関してのみの様です。

これでは、特定のユーザを WAAD を経由して Google Apps を使わせる、ということが出来ません。


◆WAAD Premium のグループ管理機能の登場

Graph API で個別のユーザに直接 SaaS アプリケーションを割り当てることは難しそうです。
そこで登場するのが、現在プレビュー公開されている WAAD Premium の機能である、SaaS アプリケーションの割り当てを個人単位ではなく、グループ単位で実施する機能です。

これであれば、グループへのメンバ登録は Graph API で実行できるので、あらかじめ特定のグループを SaaS アプリケーションへ割り当てておけば、結果的にユーザに対してアプリケーションを割り当てることが出来そうです。

まずは、グループを作成し、アプリケーションへグループを割り当てます。


すると、グループメンバになっているユーザにアプリケーションが自動的に割り当てられます。(継承としてアサインされる)


どうやらうまくいきました。
Google Apps 上にもユーザが作成されています。

注1)現在の仕様では WAAD から Google Apps 上に新規作成されたユーザは「停止済み」状態になっているので、個別に有効化する必要があります)
注2)現状、グループ単位でのアプリケーション割り当ては Salesforce では使えません。


◆再度自動化にチャレンジ

ここまで管理画面から実行した操作を Graph API で自動化できればオンプレミスの ID 管理システムから WAAD を経由して SaaS アプリケーションを使える状態にする、というところまで持っていけそうです。

ここは実は非常に簡単で、対象のグループの URI に対してメンバとして参加させたいユーザの URI をリンクする、という操作で実現できます。

エンドポイント:https://graph.windows.net/<テナントドメイン名>/groups/<グループのオブジェクトID>/$links/members?api-version=2013-11-08
メソッド:POST
ボディ:
{
"url":"https://graph.windows.net/<テナントドメイン名>/users/<ユーザのオブジェクトID>"
}

これで、先ほど手動で実施したユーザのグループへの追加(結果としてアプリケーションへの割り当て)が自動化できました。
グループへの追加の条件をオンプレミスの ID 管理ツールで調整してやれば、割り当て後のユーザの状態など少々課題は残りますが、かなり柔軟にアプリケーションへのアクセス制御が実現できそうです。

いかがでしょうか?
IdMaaS というと全面的にアイデンティティ情報をクラウドに預けてクラウド上でのみ ID 管理をする、というイメージがあるかもしれませんが、このようにうまくオンプレミスと連携することで、効率の良い環境構築が出来る可能性がある、と言うことが出来ますので、今後 SaaS アプリケーションを企業内から活用する、というシーンを想定する場合はこのようなハイブリッド ID 管理シナリオも検討してみる価値はあるかも知れません。

2013年12月7日土曜日

[WAAD]アップデートラッシュ

最近、Windows Azure Active Directory(WAAD) 周りの機能がどんどんアップデートされています。
例えば、
・アプリケーションアクセス機能の正式リリース
・Graph API のバージョンアップ
・WAAD Premium のプレビュー版のリリース
など、楽しい?機能がたくさん登場してきています。

ちょうど今月は昨年に引き続き Windows Azure Advent Calendar に参加する予定なので、徐々にネタ探しをしているのですが、今回はウォーミングアップということで軽く小ネタを。

先にあげたアップデートのうち、アプリケーションアクセス機能については、以前のポストでも紹介しましたが、2つほど小ネタを紹介します。

一つ目は、アプリケーションパネルへのアクセス URL です。

前回のポストでは以下のような長い URL を紹介していました。
 https://account.activedirectory.windowsazure.com/applications

しかし、結構長いのでエンドユーザに展開するのが面倒、という方には以下の短い URL を使ってもアクセスできるのでこちらがおススメです。
 https://myapps.microsoft.com


次に、利用者がアプリケーションパネルを使っている最中に管理者が新しいアプリケーションを割り当てたらどうなるのか?という話です。
ログアウト~再ログインするまでアプリケーションが使えないのか、単純にページをリロードすれば使えるようになるのか???

答えは単純にリロードすれば OK です。

この状態で、、、


管理者がアプリケーションにユーザを割り当てると、、、


ページをリロードすると新しいアプリケーションが表示されます。



それだけです。
ほんとに小ネタでした。