2013年9月21日土曜日

ID&IT Management Conference 2013 が終わりました

9/18@大阪、9/20@東京で開催された「ID&IT Management Conference 2013」が、無事終了しました。
 公式サイト
  http://nosurrender.jp/idit2013/

先日投稿した通り、私は JNSA の IdM-WG のメンバでのパネルディスカッションを担当しました。

時間が限られてたのでなかなか多くは伝えられませんでしたが、とりあえず無事に終了して良かったかな、、と思っています。
当日使った資料を公開しましたので、よろしければご覧ください。






後、一番のジェネラルセッションの資料もExgen江川社長が公開していらっしゃいましたので、紹介しておきます。 今後エンタープライズがどういう方向に進んでいくのか?についてわかりやすく解説されているので、ぜひご覧ください。




最後に、OpenID Foundation Japanのエヴァンジェリスト @nov が togetter で当日のまとめを作っているので参加できなかった方はこちらを見ると雰囲気がつかめると思います。

 ID & IT 2013 - Osaka #idit2013
  http://togetter.com/li/565725

2013年9月14日土曜日

[FIM2010]gacutil.exeを使わずにカスタムワークフローをGACへ取り込む方法

Forefront Identity Manager(FIM 2010)のカスタマイズのポイントを大きく分けると以下の4つになります。


  1. カスタムクライアント
  2. カスタムワークフロー
  3. ユーザインターフェイス(UI)
  4. 管理エージェント



これまでこのブログで紹介したことがあるのは3番目のUIのカスタマイズと、4番目の管理エージェントの作成方法でした。

ユーザインターフェイス(UI)
 [FIM2010] ポータルのナビゲーションバーをカスタマイズする
 http://idmlab.eidentity.jp/2012/05/fim2010.html

管理エージェント
 [FIM2010]Google Apps MA 1.1.0 をリリースしました
 http://idmlab.eidentity.jp/2012/10/fim2010google-apps-ma-110.html


1のカスタムクライアントはWindows PhoneやiOSなどで承認フローを回すような製品などが世の中にはリリースされていたりしますし、カスタムワークフローについても実際の導入を行う際は確実に実装をする対象になってくると思います。

と、いうことで今後カスタムワークフローの紹介も本ブログでしていこうと思っています。今回はその中で環境面の話なので順番的には微妙なのですが、ちょうどFIM MVPのCraigさんとSorenさんが作成したカスタムワークフロー(dll)をグローバルアセンブリキャッシュ(GAC)へ取り込む方法について紹介していたので、その方法を紹介します。

通常、作成したdllをGACに取り込むには.NET Framework SDKをインストールして、その中に含まれているgacutil.exeを使うことになるのですが、あんまり環境を汚したくない人向けにgacutilを使わなくても取り込むためのスクリプト(PowerShell)を先の二人が公開してくれています。

Craig Martin氏のブログ - Identity Trench
 Use PowerShell to GAC a FIM Workflow DLL without gacutil.exe
 http://www.identitytrench.com/2013/09/use-powershell-to-gac-fim-workflow-dll.html?utm_source=dlvr.it&utm_medium=facebook

Soren Granfeldt氏のブログ - The Identity Management Explorer
 Use Powershell to put your assemblies in the GAC
 http://blog.goverco.com/2012/04/use-powershell-to-put-your-assemblies.html?m=1


参考にしてみてください。

2013年9月7日土曜日

Bearer Token とは?

先日の OpenID Technight の後の懇親会で OpenID Foundation 理事長の崎村さんと飲みながら話をしていて、「言われてみれば・・・」と思ったのが、「OAuth などの Bearer Token の Bearer ってなんのことだと思う?」という話題でした。

OAuth 2.0 では通常 Bearer もしくは MAC というタイプのトークンが使われ、単純に違いは Secret や署名の要否という理解だったので、Bearer が何を意味するのか?を考えたことはなかったんですが、言われてみると気になります。

辞書を引くと
・運ぶ人[もの],運搬人
・持参人
などという意味があるようです。
weblio より

相変わらずこの手の用語は直訳しても良くわからないです。。。

ということで、崎村さんによる解説です。

・Bearer は「持参人払い」から来ている
 ※大辞林によると「持参人払い=小切手などの証書で,特定の者を権利者として指定せず,それを持参した人に支払うこと」
・つまり、トークンを持ってきた人に対して支払う(API 利用を許可する)、という意味である
・例えば、飛行機のチケットは持ってきた人が権利者かどうかの確認を行うが、演劇のチケットは持ってきた人が観劇できる。この演劇のチケットが Bearer である

なるほど。わかりやすい。

OAuth などのトークンに置き換えると、Bearer トークンを使う場合、使用されるトークンが誰に対して発行されたのかを確認せずに、「トークンを持っていること」をベースに API 利用を許可する、ということですね。


RFC などの仕様や実装における用法を勉強するのはもちろん大事ですが、使われる用語の意味にはちゃんと設計思想が反映されているので、ちゃんと理解しておきたいところです。

2013年9月5日木曜日

JWx 仕様の日本語翻訳版が公開されました

以前より OpenID Authentication や OAuth 2.0 などの仕様の日本語化を行ってきた OpenID Foundation Japan の翻訳・教育ワーキング・グループにより JWx の翻訳版が公開されました。



本当は昨日(9/4)の OpenID Technight での発表の現場へ駆けつけたかったんですが、残念ながら大雨で足止めをされてしまい、間に合わず。。。


今回公開されたのは、以下の3点です。




Windows Azure Active Directory の API や Google Apps の API、Salesforce.com の API を Forefront Identity Manager(FIM)をはじめとする IdM 製品から実行するようなケースではこれまで各接続先に対する設定に管理者の ID とパスワードを埋め込んだりする必要がありましたが、JWT を使った OAuth 2.0 の認可を行う形へ各社の API が対応してきているので、今後はそのようなリスクのある運用はしなくても良くなると思われます。今のうちに JWx に慣れ親しんでおく良い機会になると思いますので、ぜひ参考にしてください。
(私は JWT の部分で協力させていただいています)


参考)これまでに翻訳された仕様一覧はこちらから。
 http://openid-foundation-japan.github.io/