昨日の夜中(1/29 2:00am-3:00am JST)にensynchのWebinarがあったので、参加しました。
Agendaは以下の通り。
■Identity Lifecycle Manager "2" general overview
・ILM Roadmap
・Managing Lifecylcle of Identities
・ILM 2 Features
・ILM Synchronization Service
・ILM Service Database
・ILM Web Service
・ILM 2 Portal "End User"
・Overview of what's new, features available -
・Workflows
・Management Policies
・Codeless Provisioning
・Synch Rule
・Attribute Flow
・Easy Attribute Flow
・Functions
・Group and Set Management
・User Manaement
■Specific ILM " Scenarios and "Gotcha's"
・End User experience for Password Reset Registration
・Behind the Scenes - Policies and Workflows involved
・End user Password Reset Experience
・Behind the Scenes - Policies and Workflows involved
・What can you configure
・Lockout
・QA Gate
・Guidelines for Password Reset
・"Gotcha's" with Password Reset
■Question and Answer
彼ら(アリゾナ)の10:00am-11:00amという時間帯が設定されたおかげで日本では夜中・・・
眠い中でのLiveMeetingというあんまり良い環境ではなかったので、ざっくりしか聞けませんでしたが、まぁ一発目ということなのか本当に触りレベルの話ばっかりでした。
(しかも最初の15分は主催者側のオーディオの調子が悪かったみたいで、Toll Freeの電話番号が案内されて、スライドはWeb、音声は電話で。。みたいな話になってました。日本からもToll Free?なんて聞くのも馬鹿らしかったので、ノイジーなLiveMeeting環境でそのまま我慢しましたが)
製品概要の話は置いておいて、面白かったポイントを2,3あげると、
・参加者数
・パスワードリセット時にどんな質問(秘密の答え)が良いか?のアンケート結果
・参加者からの質問の内容からうかがえる参加者のプロファイル
です。USのILM事情を垣間見た気がしました。
まず、参加者数ですがMaxで50名くらいでした。Webinarという媒体とensynchという会社のプレゼンスとILM"2"への現段階での興味度合の複合された結果の数値だとは思いますが、USの事情がわからないだけに多いのか少ないのか微妙な感じでした。
次に、パスワードリセット時にどんな質問(秘密の答え)が良いか?のアンケート結果です。
LiveMeetingでは参加者にその場でアンケートを取ることが出来るので、こんなアンケートが出ました。
選択肢が面白くて、こんな感じでした。カッコ内は回答。
・First kiss?(17%)
・What is your name?(3%)
・What is your quest?(10%)
・What is your favorite color?(28%)
・Airspeed of unladen swallow?(39%)
日本ではこの中だと「好きな色は?」が一番しっくりくるんだろうな~と思ったのですが、最後の「荷物を持たないツバメの飛行速度は?」というアーサー王ネタがトップになるあたりがお国柄?
日本だと「山?→川」見たいなものなんだと思います。「秘密の質問」っていう主旨忘れてます。完全に。
最後に、参加者からの質問の内容からうかがえる参加者のプロファイルです。
出た質問として、
・ライセンス関係の話
→参加していたMSの方が回答していました。
あんまり聞き取れませんでしたが、未決だがCALモデルになりそう?みたいな感じでした。
・ILM2007からの移行の可否
→既存のRulesExtensionはある程度そのまま持ってこれるだろうが、新しい実装(ISRやOSR)での再実装を奨めていました。
がありました。
ということで、想像ですが既存でILM2007をすでに持っているユーザさんもしくは管理者/開発者の方たちなんだろうな~と思いました。
また来週も同じ時間に今度はビジネス面からみたILM"2"というテーマでROIの話などを取り上げるそうなので、気力が持てば参加してみます。
2009年1月30日金曜日
2009年1月26日月曜日
識別、認証、認可におけるIdMの役割
たまにはプロダクトの話ではなく、IdMそのものについて書いてみようと思います。
さて、この手のシステムをやっているとお客様を含めついつい混同されがちなのが、識別と認証と認可というキーワードだと思います。そのような混同があるのでIdMツールを入れればシングルサインオンまで含め全部何とかなる、といった勘違いが起きるのだと思います。
そこで、今回は識別、認証、認可といったキーワードの定義とIdMはそれらのキーワードに対して何をしてくれるものなのか?について整理をしてみようと思います。
まずはそれぞれの言葉の定義を見てみましょう。
識別:物事の相違を見分けること
認証:何らかの知識を元に対象の正当性を確認すること
認可:認めて許すこと
たとえば、グリム童話の「7匹の子ヤギ」に当てはめてみましょう。(コンセプトはサルでもわかるIdMの役割!です)
■識別
オオカミ:お母さんだよ。扉を開けておくれ。
→識別情報「お母さん」を与えている
子ヤギ :(ああお母さんか)
→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別①
■認証(失敗の例Ⅰ)
子ヤギ :(本当にお母さんかな?声がおかしいぞ)
→名乗った名前(お母さん)と声(オオカミの声)という属性を使って正当性を確認
子ヤギ :お母さんはそんな声じゃない。おまえはお母さんじゃない!
→認証失敗②
■認証(失敗の例Ⅱ)
オオカミ:(チョークを食べて声を変えて再び)お母さんだよ。扉を開けておくれ。
→識別情報「お母さん」を与えている
子ヤギ :(ああお母さんか)
→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
→ここまでは先ほどと同じ
子ヤギ :(本当にお母さんかな?声はお母さんの声に似ているな。ん?扉から見える手が黒いぞ。おかしいぞ)
→名乗った名前(お母さん)と手の色(オオカミの手)という属性を使って正当性を確認
子ヤギ :お母さんの手はそんな色じゃない。おまえはお母さんじゃない!
→認証失敗③
■認証(成功の例)
オオカミ:(手に白い粉を塗って)お母さんだよ。扉を開けておくれ。
→識別情報「お母さん」を与えている
子ヤギ :(ああお母さんか)
→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
子ヤギ :(本当にお母さんかな?声はお母さんの声に似ているな。扉から見える手もお母さんの手に似ているな)
→名乗った名前(お母さん)と手の色(白く塗ったオオカミの手)という属性を使って正当性を確認
子ヤギ :(確かにお母さんだ)
→認証成功④
■認可
子ヤギ :(お母さんは家族だから扉を開けても良いな)お帰りなさい。(扉を開ける)
→認可⑤
整理すると、
①で対象が与えた情報を元に子ヤギは対象を識別します。
ここで最初から「田中です」と言っても「誰やねん」という話になり子ヤギからは識別されませんので次のフェーズ(認証)へは物事は進みません。
次に②で子ヤギは対象が与えた情報(声)を元に本当に対象があらかじめ与えた識別情報と合致しているかどうかの正当性の検証を行います。
ここでは「声」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
同様に③では、「声」に加えて対象が与えた情報(手の色)を元に正当性の検証を行います。
ここでも「手の色」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
ちなみに何故チョークを食べると声が優しくなるのかは不明です。。
続いて、④では対象が与えた「声」と「手の色」の両方が子ヤギの知っている「お母さん」のものと同じであることから子ヤギは対象の正当性を認めます。つまりやっと認証成功です。
いわゆる2要素認証ですね。
最後に、対象が正当に「お母さん」であることが確認されたので、「お母さん」の持つ属性(家族)を見てあらかじめ定義された行為(家に入ること)を許可します。
これが新聞屋だったら例え正当性が確認できても家に入れる、ということはしなかったでしょう。(つまり家族ではないので家に入ることは許可されない)
ちょっと回りくどかったと思いますが、上記が識別、認証、認可の定義です。
さて、やっとIdMの話です。
IdM(狭義のIdM=provisioning/synchronizationを中心としたもの)の役割は、
・管理対象レポジトリのエントリの追加/削除
・管理対象エントリ属性の変更
であると言うことができます。
ここにワークフローやセルフサービスが入ってきたとしてもそれはあくまでプロビジョニングの条件設定や属性変更の一手段にすぎません。
上記の童話に当てはめてみると、
・管理対象レポジトリ → 子ヤギの脳
・エントリ → 知識(お母さんは知っている。田中さんは知らない)
・管理対象エントリ属性 → お母さんの声は優しい。お母さんの手は白い。お母さんは家族だ。
となります。(なんかグロいですね・・・)
IdMは子ヤギが識別したり認証したり認可をしたりするために必要な情報の提供をしているだけで、実際に識別や認証や認可をしているのは子ヤギそのものなんです。
ですから、IdMシステムの定義をする際は、対象システムがどんな情報をベースに識別し認証し認可するのか、という情報の洗い出しを厳密に行うことが非常に大切です。
この例をベースに考えると、子ヤギ(システム)は、
・名前(お母さん)を識別機能に使う
・声と手の色を認証機能に使う
・続柄(家族)を認可機能に使う
という洗い出しをあらかじめしておいて、IdMシステムに対しては
・名前
・声
・手の色
・続柄
という4つの属性を子ヤギの脳(対象レポジトリ)の中で正しい状態に保つ、ということが求められる機能だ、という定義を行います。
実際は認証連携やシングルサインオンなど、他のシステムが認めたオブジェクトに対して認可を行ったりすることもあり機能の分割がややこしいのですが、よ~く考えると上記の機能分解ができるはずなので、じっくり考えてIdMで管理が必要な属性と同期先となるレポジトリの定義を整理して行きましょう。
さて、この手のシステムをやっているとお客様を含めついつい混同されがちなのが、識別と認証と認可というキーワードだと思います。そのような混同があるのでIdMツールを入れればシングルサインオンまで含め全部何とかなる、といった勘違いが起きるのだと思います。
そこで、今回は識別、認証、認可といったキーワードの定義とIdMはそれらのキーワードに対して何をしてくれるものなのか?について整理をしてみようと思います。
まずはそれぞれの言葉の定義を見てみましょう。
識別:物事の相違を見分けること
認証:何らかの知識を元に対象の正当性を確認すること
認可:認めて許すこと
たとえば、グリム童話の「7匹の子ヤギ」に当てはめてみましょう。(コンセプトはサルでもわかるIdMの役割!です)
■識別
オオカミ:お母さんだよ。扉を開けておくれ。
→識別情報「お母さん」を与えている
子ヤギ :(ああお母さんか)
→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別①
■認証(失敗の例Ⅰ)
子ヤギ :(本当にお母さんかな?声がおかしいぞ)
→名乗った名前(お母さん)と声(オオカミの声)という属性を使って正当性を確認
子ヤギ :お母さんはそんな声じゃない。おまえはお母さんじゃない!
→認証失敗②
■認証(失敗の例Ⅱ)
オオカミ:(チョークを食べて声を変えて再び)お母さんだよ。扉を開けておくれ。
→識別情報「お母さん」を与えている
子ヤギ :(ああお母さんか)
→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
→ここまでは先ほどと同じ
子ヤギ :(本当にお母さんかな?声はお母さんの声に似ているな。ん?扉から見える手が黒いぞ。おかしいぞ)
→名乗った名前(お母さん)と手の色(オオカミの手)という属性を使って正当性を確認
子ヤギ :お母さんの手はそんな色じゃない。おまえはお母さんじゃない!
→認証失敗③
■認証(成功の例)
オオカミ:(手に白い粉を塗って)お母さんだよ。扉を開けておくれ。
→識別情報「お母さん」を与えている
子ヤギ :(ああお母さんか)
→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
子ヤギ :(本当にお母さんかな?声はお母さんの声に似ているな。扉から見える手もお母さんの手に似ているな)
→名乗った名前(お母さん)と手の色(白く塗ったオオカミの手)という属性を使って正当性を確認
子ヤギ :(確かにお母さんだ)
→認証成功④
■認可
子ヤギ :(お母さんは家族だから扉を開けても良いな)お帰りなさい。(扉を開ける)
→認可⑤
整理すると、
①で対象が与えた情報を元に子ヤギは対象を識別します。
ここで最初から「田中です」と言っても「誰やねん」という話になり子ヤギからは識別されませんので次のフェーズ(認証)へは物事は進みません。
次に②で子ヤギは対象が与えた情報(声)を元に本当に対象があらかじめ与えた識別情報と合致しているかどうかの正当性の検証を行います。
ここでは「声」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
同様に③では、「声」に加えて対象が与えた情報(手の色)を元に正当性の検証を行います。
ここでも「手の色」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
ちなみに何故チョークを食べると声が優しくなるのかは不明です。。
続いて、④では対象が与えた「声」と「手の色」の両方が子ヤギの知っている「お母さん」のものと同じであることから子ヤギは対象の正当性を認めます。つまりやっと認証成功です。
いわゆる2要素認証ですね。
最後に、対象が正当に「お母さん」であることが確認されたので、「お母さん」の持つ属性(家族)を見てあらかじめ定義された行為(家に入ること)を許可します。
これが新聞屋だったら例え正当性が確認できても家に入れる、ということはしなかったでしょう。(つまり家族ではないので家に入ることは許可されない)
ちょっと回りくどかったと思いますが、上記が識別、認証、認可の定義です。
さて、やっとIdMの話です。
IdM(狭義のIdM=provisioning/synchronizationを中心としたもの)の役割は、
・管理対象レポジトリのエントリの追加/削除
・管理対象エントリ属性の変更
であると言うことができます。
ここにワークフローやセルフサービスが入ってきたとしてもそれはあくまでプロビジョニングの条件設定や属性変更の一手段にすぎません。
上記の童話に当てはめてみると、
・管理対象レポジトリ → 子ヤギの脳
・エントリ → 知識(お母さんは知っている。田中さんは知らない)
・管理対象エントリ属性 → お母さんの声は優しい。お母さんの手は白い。お母さんは家族だ。
となります。(なんかグロいですね・・・)
IdMは子ヤギが識別したり認証したり認可をしたりするために必要な情報の提供をしているだけで、実際に識別や認証や認可をしているのは子ヤギそのものなんです。
ですから、IdMシステムの定義をする際は、対象システムがどんな情報をベースに識別し認証し認可するのか、という情報の洗い出しを厳密に行うことが非常に大切です。
この例をベースに考えると、子ヤギ(システム)は、
・名前(お母さん)を識別機能に使う
・声と手の色を認証機能に使う
・続柄(家族)を認可機能に使う
という洗い出しをあらかじめしておいて、IdMシステムに対しては
・名前
・声
・手の色
・続柄
という4つの属性を子ヤギの脳(対象レポジトリ)の中で正しい状態に保つ、ということが求められる機能だ、という定義を行います。
実際は認証連携やシングルサインオンなど、他のシステムが認めたオブジェクトに対して認可を行ったりすることもあり機能の分割がややこしいのですが、よ~く考えると上記の機能分解ができるはずなので、じっくり考えてIdMで管理が必要な属性と同期先となるレポジトリの定義を整理して行きましょう。
2009年1月20日火曜日
ILM"2"の悩みどころ?(MPR、OSR)
先日の土曜日のTech Fieldersセミナーは土曜日にも関わらず結構な動員だったみたいですね。(私は別件があり、顔を出したら既にセッションはすべて終了、懇親会真っ最中でした。ビールを飲みに行ったようなものです(*´Д`)
ということで私は内容を一切聞いていないので聴講された方がどのような理解をされたのかわかりませんが、個人的に初めてILM"2"に触られる方(特にMIIS/ILM2007経験者)が最も理解しにくい概念がMPR(Management Policy Rules)とOSR(Outbound Synchronization Rules)だと思います。
MIISやILM2007のように単純にMetaVerseにあるエントリをConnector Space上にプロビジョニングコードでストレートに吐き出してあげれば、後はExportすれば実際の同期対象システムにIDができるという考え方は、とてもわかりやすいのですが実際のユーザ環境ではそのまま使うには機能が足りません。(入力データの取り込みについてはとりあえず何でも取り込んでしまってもIdMの中の話なので、キー属性さえちゃんとしていればそれほど問題になりません)
ここで、同期対象のシステムへプロビジョニングを行う際に考えられる最低限の要件を考えてみると、
・誰(何)を
・どのような条件で
・どこに
・どのように
同期/プロビジョニングするのか?というのが最低限ルールとして定義されている必要があると言えると思います。
ILM"2"ではこの要件をある程度コーディングせずに実装するための仕組みとして、
・MPR(Management Policy Rules)
・SET
・WorkFlow
・OSR(Outbound Synchronization Rules)
という概念を実装してきました。
上記の、誰を、どのような条件で、どこに、どのようにという要件をこれらの概念に当てはめると、下の表と様になります。このセット自体のことをMPRと呼びます。
ILM"2"では、ILMSDB上のエントリに対してこのMPRを適用し、各オブジェクトに対して適用されるOSRが決定されます。(これが各オブジェクトのExpected Rules List(ERL)属性となります)
その後、ILMSDB MAのConnector Spaceへのimport/synchronizationを行うと属性に入っているERLを見て関連するOSRが実行され、実際のプロビジョニング/同期が実行されます。(ERLにはOSRオブジェクトへの参照が入ります)
最近の他社の製品には普通に実装されている機能なのですが、MIIS/ILM2007ユーザにはちょっとわかりにくいかと思うので、MIIS/ILM2007との機能対比を最後に書いておきます。
ちなみに、ILM"2"でもMAやMetaVerseのRules Extensionは従来通り利用可能なので、合わせて実装することも可能です。(切り分けが難しくなりそうなので、お勧めはしませんが)
ということで私は内容を一切聞いていないので聴講された方がどのような理解をされたのかわかりませんが、個人的に初めてILM"2"に触られる方(特にMIIS/ILM2007経験者)が最も理解しにくい概念がMPR(Management Policy Rules)とOSR(Outbound Synchronization Rules)だと思います。
MIISやILM2007のように単純にMetaVerseにあるエントリをConnector Space上にプロビジョニングコードでストレートに吐き出してあげれば、後はExportすれば実際の同期対象システムにIDができるという考え方は、とてもわかりやすいのですが実際のユーザ環境ではそのまま使うには機能が足りません。(入力データの取り込みについてはとりあえず何でも取り込んでしまってもIdMの中の話なので、キー属性さえちゃんとしていればそれほど問題になりません)
ここで、同期対象のシステムへプロビジョニングを行う際に考えられる最低限の要件を考えてみると、
・誰(何)を
・どのような条件で
・どこに
・どのように
同期/プロビジョニングするのか?というのが最低限ルールとして定義されている必要があると言えると思います。
ILM"2"ではこの要件をある程度コーディングせずに実装するための仕組みとして、
・MPR(Management Policy Rules)
・SET
・WorkFlow
・OSR(Outbound Synchronization Rules)
という概念を実装してきました。
上記の、誰を、どのような条件で、どこに、どのようにという要件をこれらの概念に当てはめると、下の表と様になります。このセット自体のことをMPRと呼びます。
要件 | 関連する概念 | 解説 |
誰(何)を | SET | ILM"2"内で定義するオブジェクトのグループ(セット)。スタティックにメンバを決めることもできますし、オブジェクトの属性をベースに動的にメンバを決めることもできます。 例)EmployeeType属性がContractorのユーザオブジェクトのセット |
どのような条件で+どこに | WorkFlow | 承認が必要な場合などを含め条件をWorkFlowで定義します。 特にOSRと紐付をするタイプのWorkFlowをActionWorkFlow(AW)といいます。 承認後、結果によって振る舞いを変える場合はAuthorization WorkflowとActionWorkflowを組み合わせることにより実現します。 |
どのように | OSR | ISRと同様にAttributeFlowなどを設定し属性のマッピング等を行います。 |
ILM"2"では、ILMSDB上のエントリに対してこのMPRを適用し、各オブジェクトに対して適用されるOSRが決定されます。(これが各オブジェクトのExpected Rules List(ERL)属性となります)
その後、ILMSDB MAのConnector Spaceへのimport/synchronizationを行うと属性に入っているERLを見て関連するOSRが実行され、実際のプロビジョニング/同期が実行されます。(ERLにはOSRオブジェクトへの参照が入ります)
最近の他社の製品には普通に実装されている機能なのですが、MIIS/ILM2007ユーザにはちょっとわかりにくいかと思うので、MIIS/ILM2007との機能対比を最後に書いておきます。
要件 | MIIS/ILM2007 | ILM"2" |
だれを同期するか | MetaVerseのRules ExtensionのProvision関数内に条件分(IF、SWITCHなど)で実装 | SETを利用 |
同期条件は何か | WorkFlowを利用 | |
どこに同期するか | Action WorkflowにOSRを設定 | |
どのように同期するか | 同期対象MAの設定(Rules Extension含む) | OSRを利用 |
ちなみに、ILM"2"でもMAやMetaVerseのRules Extensionは従来通り利用可能なので、合わせて実装することも可能です。(切り分けが難しくなりそうなので、お勧めはしませんが)
2009年1月14日水曜日
ILM"2"組み込み関数一覧
コードレスプロビジョニングで使える関数の説明がまとめられているブログがあったので紹介します。
ILM Best Practives
http://www.ilmbestpractices.com/blog/2009/01/ilm-2-functions-explained.html
簡単に転記&和訳しておきます。
余談ですが、ブログ筆者の方(David Lundellさん。ILM MVP)はEnsynchというITコンサル屋さんに所属しています。
http://www.ensynch.com/pa_secure_ID_management.aspx
この会社、他にもBrad Turnerさん(http://www.identitychaos.com/)などILMのMVPの人が複数所属しているらしいです(どんな会社だ?)
Brad Turnerさんですがこの人はこの人で、「ILM_2_RC0_Workflow_Activity_Walkthrough」というILM"2"のカスタムワークフローの開発ガイドのようなドキュメントを書いていたりしますので、今後ILMにかかわる人は要チェックかと。
今週末、MSエバンジェリスト安納さんのセミナもありますし、やっと国内でもILMの立ち上げに本気になったんでしょうか?
http://blogs.technet.com/junichia/archive/2008/12/08/3164978.aspx
ILM Best Practives
http://www.ilmbestpractices.com/blog/2009/01/ilm-2-functions-explained.html
簡単に転記&和訳しておきます。
関数名 | 引数 | 解説 |
BitAnd | 1) マスク 型:Integer 2) フラグ 型:Integer | BitAndはマスクとフラグの論理積を行います。ActiveDirectoryのuserAccountControl属性あたりで活用できます。 |
BitOr | 1) マスク 型:Integer 2) フラグ 型:Integer | BitAndはマスクとフラグの論理和を行います。※現状(RC0時点)では動作しないようです。 |
CRLF | なし | 改行コード(CRLF)を返します。 |
DateTimeFormat | 1)dateTimeString 型:String 2)フォーマット 型::String | 引数で与えた日付・時間の文字列をフォーマットに合わせて成型した文字列を返します。 |
ConvertSidToString | 1) ObjectSID 型:Binary | Utils.ConvertSidToStringと同じ機能です。BYTE文字列形式のObjectSIDを文字列として出力します。 |
EscapeDNComponent | 1) dnStr 型:String | ConnectedMA.EscapeDNComponentと同じ機能です。DNとして許可されていない文字をエスケープします。 |
IIF | 1)式 型:Boolean 2)真の時の値 型:Object 3)偽の時の値 型:Object | 式の結果が真であれば、真の時の値が、偽であれば偽の時の値を返します。 |
Left | 1) 文字列 型:String 2) 文字数 型:Integer | 文字列の左から文字数分の文字列を切り出して、返します。 |
LowerCase | 1) 文字列 型:String | 入力文字列を小文字に変換します。 |
LeftPad | 1) 文字列 型:String 2) 文字列長 型:Integer 3)埋め文字 型:String | 結果文字列の長さが第2パラメータで渡した文字列長になるように入力文字列の左側に埋め文字を付加します。 |
Mid | 1)文字列 型:String 2)開始位置 型:String(Integerの間違い?) 3)文字列長 型:Integer | 入力文字列を開始位置から文字列長分切り出した文字列へ整形します。 |
LTrim | 1) 文字列 型:String | 入力文字列の左側のスペースを除去します。 |
ProperCase | 1) 文字列 型:String | 各単語の最初の文字を大文字に、それ以外を小文字に変換します。 |
RandomNum | 1)下限数 型:Integer 2)上限数 型::Integer | 下限数から上限数の間で乱数を返します。 |
Right | 1) 文字列 型:String 2) 文字数 型:Integer | 文字列の右から文字数分の文字列を切り出して、返します。 |
Trim | 1) 文字列 型:String | 入力文字列の左右のスペースを除去します。 |
RTrim | 1) 文字列 型:String | 入力文字列の右側のスペースを除去します。 |
RightPad | 1) 文字列 型:String 2) 文字列長 型:Integer 3)埋め文字 型:String | 結果文字列の長さが第2パラメータで渡した文字列長になるように入力文字列の右側に埋め文字を付加します。 |
UpperCase | 1) 文字列 型:String | 入力文字列を大文字に変換します。 |
Word | 1) 文字列 型::String 2)インデックス 型::Integer 3)区切り文字 型:String | 入力文字列を区切り文字で区切った結果の配列のインデックス個目の文字列を返します。 |
余談ですが、ブログ筆者の方(David Lundellさん。ILM MVP)はEnsynchというITコンサル屋さんに所属しています。
http://www.ensynch.com/pa_secure_ID_management.aspx
この会社、他にもBrad Turnerさん(http://www.identitychaos.com/)などILMのMVPの人が複数所属しているらしいです(どんな会社だ?)
Brad Turnerさんですがこの人はこの人で、「ILM_2_RC0_Workflow_Activity_Walkthrough」というILM"2"のカスタムワークフローの開発ガイドのようなドキュメントを書いていたりしますので、今後ILMにかかわる人は要チェックかと。
今週末、MSエバンジェリスト安納さんのセミナもありますし、やっと国内でもILMの立ち上げに本気になったんでしょうか?
http://blogs.technet.com/junichia/archive/2008/12/08/3164978.aspx
2009年1月6日火曜日
SAP NetWeaver Identity Management事始め(アーキテクチャ整理)
仕事で触ることになりそうなので、SAPに買収された後のバージョンに初めて触れてみます。
最新バージョンは7.1なのですが、現状一般にリリースされた状態ではないのでとりあえず入手可能なバージョンということで7.0sp2をベースに考えてみます。
※7.1からフロントエンドがこれまでIIS+PHPで動いていたのが、NetWeaver AS上で動作する様になり、見た目もより”SAP”になったそうなので、7.1が入手できればそちらでも検証が必要になりそうです。
さて、現行の7.0というバージョンに関しては旧MaXware Identity Center(MIC)と殆ど変わらない、と考えておいて問題ないと思います。
まず、基本アーキテクチャですが、Identity Centerは以下のコンポーネントで構成されます。
・Identity Center database
この製品の特徴が中央に統合されたアイデンティティストアを持つことです。このあたりがSunのVirutal Identityとは異なる点です。(IDストアを持つべきか、持たざるべきかについては色々と議論を呼ぶところかと思いますが、私個人としてはデータの加工の容易さなどの点でIDストアを持った方が楽だと思っています。実装屋の意見ですね・・・)
話がそれましたが、SAP IdMではこのデータベースにプロビジョニングやワークフローのタスクやジョブそのもの、スケジュール情報、タスクの状態や差分情報、監査ログなども格納されます。
ちなみにdatabaseエンジンとしてはSQL ServerもしくはOralceが使用されます。
・Runtime components
メインはdispatcherとevent agentです。
・runtime engine
実際の同期やプロビジョニングを行う単位をSAP IdMではジョブと呼びますが、このジョブを実行するのがruntime engineです。旧MaXware時代はこのruntime engine部分が別製品のData Synchronization Engine(通称DSE)として販売されており、単純な同期・プロビジョニングの要件だけならこちらで十分対応できました。
・dispatcher
様々なイベントに応じて適切なジョブをruntime engineで実行するのがdispatcherです。
・event agent
上記のdispatcherは基本的にバッチの仕組みなので、リアルタイム性に欠けます。そこで登場するのがこのevent agentです。
データベーストリガーやLDAPのchange logを使って変更を検知し、ある程度リアルタイムに属性同期やプロビジョニングを行います。
また、ジョブ実行のスケジューリングも行います。
・Workflow UI
利用者向けのWebインターフェイスです。
ユーザ登録、セルフサービス、パスワードリセット、承認タスクなどが実施できます。
・Monitoring UI
管理者向けのWebインターフェイスです。
システム状態のモニタリングや監査ログの取得などが実施できます。
・Management console
Identity Centerの構成を行うためのMMCインターフェイスです。
この画面で同期やプロビジョニング、ワークフローなどのタスクやジョブを構成します。
ちなみに最後のManagement Console以外はUNIXプラットフォーム上でも動作します。(Java版)
最新バージョンは7.1なのですが、現状一般にリリースされた状態ではないのでとりあえず入手可能なバージョンということで7.0sp2をベースに考えてみます。
※7.1からフロントエンドがこれまでIIS+PHPで動いていたのが、NetWeaver AS上で動作する様になり、見た目もより”SAP”になったそうなので、7.1が入手できればそちらでも検証が必要になりそうです。
さて、現行の7.0というバージョンに関しては旧MaXware Identity Center(MIC)と殆ど変わらない、と考えておいて問題ないと思います。
まず、基本アーキテクチャですが、Identity Centerは以下のコンポーネントで構成されます。
・Identity Center database
この製品の特徴が中央に統合されたアイデンティティストアを持つことです。このあたりがSunのVirutal Identityとは異なる点です。(IDストアを持つべきか、持たざるべきかについては色々と議論を呼ぶところかと思いますが、私個人としてはデータの加工の容易さなどの点でIDストアを持った方が楽だと思っています。実装屋の意見ですね・・・)
話がそれましたが、SAP IdMではこのデータベースにプロビジョニングやワークフローのタスクやジョブそのもの、スケジュール情報、タスクの状態や差分情報、監査ログなども格納されます。
ちなみにdatabaseエンジンとしてはSQL ServerもしくはOralceが使用されます。
・Runtime components
メインはdispatcherとevent agentです。
・runtime engine
実際の同期やプロビジョニングを行う単位をSAP IdMではジョブと呼びますが、このジョブを実行するのがruntime engineです。旧MaXware時代はこのruntime engine部分が別製品のData Synchronization Engine(通称DSE)として販売されており、単純な同期・プロビジョニングの要件だけならこちらで十分対応できました。
・dispatcher
様々なイベントに応じて適切なジョブをruntime engineで実行するのがdispatcherです。
・event agent
上記のdispatcherは基本的にバッチの仕組みなので、リアルタイム性に欠けます。そこで登場するのがこのevent agentです。
データベーストリガーやLDAPのchange logを使って変更を検知し、ある程度リアルタイムに属性同期やプロビジョニングを行います。
また、ジョブ実行のスケジューリングも行います。
・Workflow UI
利用者向けのWebインターフェイスです。
ユーザ登録、セルフサービス、パスワードリセット、承認タスクなどが実施できます。
・Monitoring UI
管理者向けのWebインターフェイスです。
システム状態のモニタリングや監査ログの取得などが実施できます。
・Management console
Identity Centerの構成を行うためのMMCインターフェイスです。
この画面で同期やプロビジョニング、ワークフローなどのタスクやジョブを構成します。
ちなみに最後のManagement Console以外はUNIXプラットフォーム上でも動作します。(Java版)