Tuesday Mar 25, 2008

Who Killed Meta-Directory?

メタディレクトリはもう死んでるのかどうかをめぐって, Dave Kearns 氏Kim Cameron 氏が妙にアツい論争をくりひろげてる.

斜め読みしただけなのでもしかしたら外してるかもしれないけど, どうも両者ともちょっとズレてるようにみえる. まず Dave の 「バーチャル・ディレクトリがあればメタディレクトリなんて要らないんじゃね?」 という主張にムリがある. Application developers like to use databases and tables だし, いくら社員情報の最新版が人事システムに入ってるからといって, バーチャル・ディレクトリ経由で毎回毎回問い合わせたりはしない (ふつうは offload information from the HR system to other systems する).

かといって Kim の言う通り, メタディレクトリがいまでも必要とされているのかというと, それも違う. たしかに昔は 「システム間でのアイデンティティ情報の変換・同期 (= メタディレクトリ)」 だけで良かったけど, 最近は同期そのものよりも, その処理を 「どのような立場の誰がどのように承認するか」 とか 「いつ実行するか」 とかいった, いわゆるワークフロー的な機能が重要になってきてて, だからこそ Sun Java System Identity Manager のようなアイデンティティ・プロビジョニング製品の市場が盛り上がってきてるわけで. まあ Microsoft はちゃんとしたアイデンティティ・プロビジョニング製品を持ってないので, 中の人である Kim はメタディレクトリを推さざるを得ないのかもしれないけど.

結局のところ, 両者の話がこじれてるのは, 「メタディレクトリは死んだ」 の主犯に 「バーチャル・ディレクトリ」 を挙げてしまったせいだと思う. 最初に 「アイデンティティ・プロビジョニングがメタディレクトリに引導を渡した」 と書いてれば良かったのに...

Tuesday Nov 06, 2007

Sun Tech Days 2007 in Tokyo

Sun Tech Days 2007 in Tokyo

岩片さんのエントリを読んで, すっかり告知し忘れてたことに気づいたんだけど (なんか最近 blogs.sun.com/swjp とごっちゃになってる), 明日からオープンする Sun Tech Days 2007 in Tokyo の展示コーナーにて 「Sun アイデンティティ管理ソリューション」 のブースを担当する予定. セッションの合間や, あるいは明日 19:15 からのレセプションで一杯ひっかけつつ, お立ち寄りいただければ幸いです.

Friday Mar 02, 2007

Java Enterprise System 5.0 / Directory Server Enterprise Edition 6.0 / Access Manager 7.1

Sun Java Enterprise System (Java ES) の最新バージョンである 5.0 が, 米国で正式にアナウンスされた. ダウンロードは Get the Product Now ボタンをクリック.

Sun Microsystems, Inc. (NASDAQ: SUNW) today announced the immediate availability of the latest version of the Sun Java Enterprise System (Java ES).
Sun Microsystems Upgrades Java Enterprise System -- Over 1.3 Million Subscribers Strong

アイデンティティ管理関連では Sun Java System Directory Server Enterprise Edition (DSEE) が 5.2 から 6.0 へひさびさのメジャー・アップグレード. また, Sun Java System Access Manager (AM) も 7.0 から 7.1 に更新されている. それぞれの新機能一覧は docs.sun.com にある製品文書をどうぞ. とくに DSEE には 「あー, あとこういうのができればいいんだけどなー」 的な機能が, 大小問わずたくさん盛り込まれている.

以下, blogs.sun.com から関連エントリをピックアップ.

Thursday Dec 21, 2006

SDC の IdM 連載 (2): ディレクトリ・システム

先月から SDC で始めた アイデンティティ管理の月いち連載, 第二回目はディレクトリ・システム.

それにしても, Ludo が紹介してる Sun Java System Directory Server の事例 @ sina.com はすごいなー. それまで Linux を動かしてた 30 台の Dell 製 Xeon サーバを 12 台の Solaris 10 on Sun Fire T1000 でリプレースして, その上で 1 億 2,000 万エントリの入った LDAP サービスを運用してるらしい. しかも, 将来的には 6 億エントリに拡張することを計画してるそうだ.

Thursday Oct 19, 2006

記憶力自慢の組織向けのパスワード管理ポリシー

地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版) という文書の 「3.5.4 ID及びパスワード等の管理」 に書かれている遵守事項の例文が, なかなかすごいことになっている:

(3) パスワードの取扱い
職員等は、自己の管理するパスワードに関し、次の事項を遵守しなければならない。

  1. パスワードを秘密にし、パスワードの照会等には一切応じてはならない。
  2. パスワードを記載したメモを作成してはならない。
  3. パスワードは十分な長さとし、文字列は想像しにくいものにしなければならない。
  4. パスワードが流出したおそれがある場合には、情報セキュリティ管理者に速やかに報告し、パスワードを速やかに変更しなければならない。
  5. パスワードは定期的に、又はアクセス回数に基づいて変更し、古いパスワードを再利用してはならない。
  6. 複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない。
  7. 仮のパスワードは、最初のログイン時点で変更しなければならない。
  8. パソコン等の端末のパスワードの記憶機能を利用してはならない。
  9. 職員等間でパスワードを共有してはならない。

地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版)

これらひとつひとつの項目はまっとうな内容に思えるけど (6 を除く. 理由は後述), すべてを同時に達成することって実際にできるんかな!? とくに上で強調 (太字) した5 項目を遵守するのは相当難易度高いと思うなあ. ヘタすれば, どれも守れなくて結局セキュリティは低下, しかもユーザの利便性はどん底, パスワード忘れの問い合わせへの対応は増える一方になるような気がする.

すこし前 ('02) の調査だけど, IT システムを常用している一般的なユーザが管理しているパスワードの数は 21 個だという話がある. また利用者がパスワードを完全にコントロールできる (自分の覚えやすい文字列を使い, 自分が忘れる前に変更する) ならまだしも, パスワード・ポリシー, たとえばよくあるところだと

  • パスワードを変更するタイミング
  • パスワードに使用することのできる文字種・長さ
  • パスワード履歴に基づく使用禁止ポリシー

などは, そのパスワードを格納するシステムごとに異なっているはずだ. そのような環境下でこんな運用↓をユーザに強制させることができるとすれば, そこは相当記憶力がいい人の集まりに違いない.

  • パスワードは十分な長さとし, 文字列は想像しにくいものにして下さい. 同一のパスワードをシステム間で用いてはならないことになっていますから, システム毎に異なるパスワードを設定していただきます. なおそのパスワードを記載したメモを作成してはならないですし, またパソコン等の端末のパスワードの記憶機能を利用してはならないことは言うまでもありません. 最後に, パスワードは定期的に, 又はアクセス回数に基づいて変更を強制されます. また古いパスワードを再利用してはならないように設定されています. ご注意下さい.

おそらく, この例文を作成した方は 「認証」 と 「認可」 をごっちゃにしていたのではないだろうか (ああ, またココにも 「認証基盤」 というダメ言葉の弊害が!). その誤解を示しているのが, 項目 6 の 「複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない」 という文言. たぶんパスワードがひとつ盗まれても他のシステムのパスワードは違うから, 被害は広がらないよーっていうことを意図してるんだろうけど, 本当に必要なのはそうではなくて, システム / アプリケーションごとに適切な認証レベルを設定することのはずだ. たとえばこんな感じ:

  • 社員ポータルと Web メールとインスタント・メッセージングは共通の認証レベルで十分であると定義し, パスワードを一元化 (さらにはシングル・サインオン) する.
  • 一方, 人事システムへのアクセスは人事担当者のみに制限する必要があるので認証レベルを上げ, パスワードだけでなくディジタル証明書の提示も要求する.
  • さらに, 経営情報管理システムはより高い認証レベルが必要であると定義し, パスワードだけでなくディジタル証明書も必要, 特定の階 (ボード・ルームのあるフロア) の端末からしかアクセスを許可しない.

このへんの考え方は 「政府機関の情報セキュリティ対策のための統一基準」 を解説する 「政府機関統一基準の説明資料(2006年8月2日)」 の #81 - #95 になかなかよくまとめられている. あとはもちろん, 弊社のアイデンティティ管理ソリューションもお忘れなく ;)

Wednesday Oct 04, 2006

CEC 2006: ディレクトリ・サービス管理のデモ

ブレイクアウトの合間, 次のセッションへ向かう途中にふとデモ・コーナーを見てみると, そこにはハードウェアと並んで, 次期バージョンのディレクトリ・サーバにて提供予定の管理コンソールのデモがあった.

dscc

これまで Directory Server や Directory Proxy Server の管理ツールは専用のクライアント・アプリケーション (Sun Java System Console) だったけど, 次のバージョンからはこれらの管理が Web インタフェースからできるようになる. ディレクトリ・サーバのインスタンスの追加やレプリケーション設定, さらにディレクトリ・プロクシの負荷分散比率やフィルタリングの設定をみせてもらった感じでは, これまでより相当わかりやすくなってるようだ.

Wednesday Aug 02, 2006

OpenDS

OpenDS

いま cn=Directory Managerのエントリ読んで知ったんだけど, OpenDS プロジェクトが java.net にて先週から始まっている.

OpenDS は完全に Java で書かれたオープンソースのディレクトリ・サービスです. なぜ 「ディレクトリ・サービス」 という言葉を使うかというと, わたしたちは単なる 「LDAP アクセス可能なデータベース」 以上の機能をこの中に盛り込んでいくからです. (Sun の) 現行の Directory Server Enterprise Edition と同様の機能, すなわちディレクトリ・プロクシ (バーチャル・ディレクトリおよびデータ分散) や, Active Directory など他のソースとの同期, そしてさまざまなクライアント・ツールを包含する予定です.
Introducing the OpenDS Directory Service - cn=Directory Manager より引用

ためしにウィークリー・ビルドを動かしてみた. まずは OpenDS Downloads ページから 「Get the Latest Weekly Build」 をたどって, 現時点で唯一のプリビルト・バージョンである OpenDS 0.1 Build 001 をダウンロード.
Weekly Build

OpenDS-0.1-build001.zip を適当なところに展開. Unix / Windows はどちらでもよかったんだけど, 今回は Windows XP を使ってたので, とりあえず C:\\ に展開.

環境変数 JAVA_HOME を設定. 手元の環境では 1.5.0_07 が c:\\Program Files\\Java\\jdk1.5.0 に入ってたので, 以下の通り:

C:\\OpenDS-0.1>set JAVA_HOME=c:\\Program Files\\Java\\jdk1.5.0

OpenDS 0.1 Build 001 にはエントリのサンプルがついてないので, まずはなにかインポートしないといまいち遊べない. 今回は docs.sun.com にあった LDIF ファイルのサンプルを借用してみた. これを sample.ldif として C:\\ に配置し, bin\\import-ldif.bat を実行. バックエンドの名前はディフォルトで userRoot なので, それをオプション -n に指定.

C:\\OpenDS-0.1>bin\\import-ldif.bat -l \\sample.ldif -n userRoot
[02/8/2006:11:56:09 +0900] category=BACKEND severity=NOTICE id=8388697 msg="Import thread count = 8"
[02/8/2006:11:56:09 +0900] category=BACKEND severity=NOTICE id=8388698 msg="Buffer size per thread = 32,000,000"
[...]
[02/8/2006:11:56:12 +0900] category=BACKEND severity=NOTICE id=8388701 msg="Flushing data to disk."
[02/8/2006:11:56:12 +0900] category=BACKEND severity=NOTICE id=8388702 msg="Processed 8 entries, imported 8, skipped 0, and rejected 0 in 3 seconds (average rate 2.2/sec)."
[02/8/2006:11:56:12 +0900] category=BACKEND severity=NOTICE id=8388703 msg="Number of index values that exceeded the entry limit: 0"
C:\\OpenDS-0.1>

ここまでできたところで, いよいよ OpenDS を起動. 別のコンソールで, (JAVA_HOME を指定してから) start-ds.bat を実行.

C:\\OpenDS-0.1>bin\\start-ds.bat
[02/8/2006:11:56:28 +0900] category=CORE severity=NOTICE id=458886 msg="OpenDS Directory Server 0.1 starting up."
[02/8/2006:11:56:32 +0900] category=BACKEND severity=NOTICE id=8847402 msg="A database backend containing 8 entries has started."
[02/8/2006:11:56:33 +0900] category=CONFIG severity=SEVERE_WARNING id=3277325 msg="Access control has been disabled."
[02/8/2006:11:56:50 +0900] category=CORE severity=NOTICE id=458887 msg="The Directory Server has started successfully."
[02/8/2006:11:56:50 +0900] category=CORE severity=NOTICE id=458891 msg="The Directory Server has sent an alert notification generated by class org.opends.server.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, alert ID 458887):  The Directory Server has started successfully.."

本当に動いているのかどうか, ためしに同梱の ldapsearch コマンドで検索してみる. ディフォルトでは ポート 389, Base DN は dc=example,dc=com なので (ちなみに root ユーザの DN は cn=Directory Manager, パスワードは password), いわゆるユーザ一覧を検索するには以下のようにする.

C:\\OpenDS-0.1>bin\\ldapsearch.bat -b dc=example,dc=com objectclass=inetorgperson
dn: uid=abrown,ou=People,o=MyCorp,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
givenName: Aaron
userPassword: {SSHA}MbmYn39jI1S56RpyARHrdr5kCkY1iFkVe58LQQ==
cn: Aaron Brown
facsimiletelephonenumber: 666
sn: Brown
mail: abrown@mycorp.com
uid: abrown
[...]
C:\\OpenDS-0.1>

LDAP Browser / Editor でみるとこんなん:

...という具合に, 最前線の LDAP 職人たちが創るフリーのディレクトリ・サービス実装を, この機会にぜひ一度お試しあれ.

Monday Mar 27, 2006

圧倒的な Sun Java System Directory Server 技術情報 (その 2)

先日書いた, Neil の Sun Java System Directory Server ネタの超濃い blog に関するエントリの続き. 今回はとりあえず 2006 年 1 月末までの要約.

  • SSL over LDAP のアクセラレーション (高速化) ができない理由 (01/03/06)

    結論から言えば, SJS Directory Server をはじめとする LDAP サーバ・ソフトウェアの LDAP over SSL の処理性能を SSL アクセラレータで向上させることは基本的にできない. これは LDAP の使われ方 (HTTP と比べると接続が long-lived) によるもので, LDAP サーバの実装の優劣に関わる話ではない.

    高速化のためではなくセキュアな鍵ストレージとして SSL アクセラレータを使うというのであれば, それはそれで意味がある.

  • SLAMD はどうなった? (01/08/06)

    SLAMD の近況. 次期バージョン (CVS でチェックアウト + ビルドも可能) では以下の変更・拡張が入る予定:

    • 設定の保存先に LDAPv3 でなく Berkeley DB Java Edition を使う
    • SLAMD サーバとクライアントとの間のプロトコルを変更し拡張しやすくする
    • その他, 予想残り時間の出力, 改善したとみなす閾値の設定, MPStat や IOStat, NetStat などのリソース監視, HTTP クライアントの Cookie 管理の改良, 閲覧専用モードの追加など
  • Sun T2000 対 Dell 6850 再び (01/10/06)

    以前書いたベンチマークの追加試験結果. 格納するユーザ・エントリの数を変化させて, LDAP 認証性能を計測している.

  • RAID の重要性 (01/20/06)

    SJS Directory Server のディスク構成としては通常, RAID 1+0 (パフォーマンスと冗長性を重視) が適当. だけど RAID 5 (容量と冗長性を重視) のほうが向いていることもある. それは非常に大量のエントリを扱っている場合. 性能は落ちるけど, 何か障害が起こったとき長時間にわたるインポートをし直さなくてすむから.

  • あまり知られていない性能向上テクニックその 3: 参照整合性プラグイン (01/20/06)

    参照整合性プラグインに必要となる属性にはきちんとインデックスを設定すべし. さもないと削除 / 変更オペレーションのたびに長い時間待たされることになってしまう. また参照整合性の更新の遅延時間 (nsslapd-pluginarg0) も 0 以外の値, 1 ~ 10 (秒) にしたほうが良い. さらに参照整合性プラグインのログ・ファイル (nsslapd-pluginarg1) も, 適切な場所に設定すること.

  • Directory Server にコアをダンプさせる (01/23/06)

    タイトル通り, コアの吐かせ方のベスト・プラクティス. coreadm(1M) で適切に設定した後に kill -11 {PID}.

  • よく尋ねられる質問その 1: サイズの制限 (01/24/06)

    基本的に, なにか制限値が SJS Directory Server に埋め込まれていることはない. 初期値によって制限されることはあるけど, これらも変更可能.

    あとは ASN.1 エレメントの最大サイズ (32-bit signed integer, すなわち 2 GB マイナス 1 バイト) やエントリ ID (4,294,967,292 まで) があるけど, 実際の利用で問題になったと言う話はきいたことがない.

  • よく尋ねられる質問その 2: 非 SSL 接続を無効にする (01/26/06)

    これはいくつか方法がある. nsslapd-port を 0 にするのが一番てっとり早いけど, bak2db.pl などの管理スクリプトにちょっと改修を加えなくてはいけなくなる. おすすめは non-SSL のみループバックにすること. 具体的には nsslapd-listenhost を 127.0.0.1 とする.

  • よく尋ねられる質問その 3: ログ・ファイルのパーミッション (01/27/06)

    現行の SJS Directory Server 5.x は自身の出力するログ・ファイルの所有者を nsslapd-localuser の値に, パーミッションを 600 にセットする. これを 640 にしたいというリクエストが多くあって, その機能が次期バージョンの 6.0 に入る予定.

    5.x でのとりあえずの回避策としては cron で定期的にパーミッションを修正する方法がある. ただこれはシンプルだけど, あまり美しいとはいえない. Solaris なら以前書いたようにロールを使うとベター. usermod -K type=role dirsrv および usermod -R dirsrv {username} とかする.

  • よく尋ねられる質問その 4: 既定のアクセス制御 (01/27/06)

    既定のアクセス制御設定では cn=schema などへの anonymous アクセスを許可してるけど, これを無効化したいという話.

    技術的には ACI を ldap:///anyone から ldap:///all に変更するだけで認証済みユーザのみのアクセスに制限することができるけど, root DSE へのアクセス制御は変えないほうがいい. SJS Directory Server にどのようなケイパビリティがあるか, 未認証状態の LDAP クライアントからはわからなくなる. その結果たとえばどのような SASL メカニズムがサポートされているか, 外から判断できなくなってしまう.

    それと比較すると, cn=monitor にはアクセス制限をかけてもいいかもしれない. でも一般的にヘルス・チェックで使われることが多いから, いろいろ面倒くさいことになりそう.

    いずれの場合も, アクセスを制限をしたいのなら別の方法, たとえば IP アドレスで限定するとかのほうがおすすめ.

Wednesday Dec 21, 2005

圧倒的な Sun Java System Directory Server 技術情報

先日下道さんぼくや同僚を指して 「濃いエンジニア」 と書いていたけど, 実のところはまったくそんなことない. 「濃い」 というのは, たとえば先々週から blogs.sun.com にものすごい勢いでエントリを上げている Neil Wilson のような人に対して使うべき形容詞だ.

Hi. I'm Neil Wilson and I work with Sun's LDAP Directory Server. My primary responsibility is writing code, but I spend a lot of time doing performance analysis and benchmarking, and also working with customers to help them with deployment advice or performance issues or whatever problems they might have.
cn=Directory Manager: I've put it off long enough

社内の技術メールリストに数行 Sun Java System (SJS) Directory ServerSLAMD の質問を投稿するとすぐに Neil から数十行の詳細なフォローアップが返ってきたりして, 前からすごいなーと思っていたんだけど 彼の書いているエントリはまさしくそれと同じレベルの質・量だ. 社内外を問わず, SJS Directory Server にかかわっている人は全員必読だと思う.

現時点での彼のエントリをまとめてみた.

Thursday Sep 29, 2005

SLAMD Distributed Load Generation Engine

SLAMD
SLAMD は, ネットワーク・アプリケーションに対し分散負荷テストと性能測定 (いわゆるベンチマーク) を行なうための Java ベースのアプリケーション. もともとは Sun 社内利用オンリーのツールで, ちょうど一年くらい前, Sun Public License の下に公開された.

設定情報やテスト結果を格納するための LDAP サーバをインストールしなくてはならないのがちょっと敷居高めかもしれないけど, 一度準備してしまえばその後はけっこうお手軽にテストを設定・実行し, 結果を比較・解析できる.

実際の出力結果をいくつかご紹介. まずは HTTP 処理ベンチマークの例. 赤のグラフが平均トランザクション数 / 秒, 緑のグラフが一トランザクションあたりの平均処理時間.
HTTP_GetRate

Web サーバにたくさんの HTTP GET リクエストを与えたときの, サーバ全体の CPU 利用状況を計測した例. はじめはほとんど青 (idle) だけど, 徐々に緑 (sys) と赤 (usr) の割合が大きくなっていってる.
CPU_Utilization

同じく Web サーバにたくさんの HTTP GET リクエストを与えたときの, Web サーバ・プロセスのサイズを計測した例. プロセス内にキャッシュされるセッションや処理スレッド数が増えていくにつれて, そのサイズも大きくなっていってることがわかる.
Process_Size

もともと Sun Java System Directory Server やその関連ミドルウェアの開発に使われていたツールだから, あらかじめ用意されているジョブ・クラス (ベンチマーク定義) はそっち系が多め. しかしそれ以外にも HTTP GET 処理や SQL 処理のサンプルなどいろいろ同梱されているので (Defined Job Class 参照), フリーのベンチマーク・ツールをお探しの方はぜひ一度お試しあれ.

Friday Jul 01, 2005

Sun Identity Management Update - June 2005

SIMN header
Sun Identity Management Update の最新号が今週公開された. 以下, 内容をいくつか簡単にご紹介したい.


Sara Gates, Vice President of Identity Management: The Shape of Things to Come

Sara Gates による, アイデンティティ管理の過去 (Internet Age) と現在 (Extranet Age) のまとめ, そして将来 (Participation Age) の展望.

'01 くらいに登場した 「アイデンティティ管理」 は企業システムのアクセス権設定を自動化することによる効率向上と費用低減が目的だったが, 現在では社内ユーザだけではなく社外の取引先や顧客にまで管理対象を広げてきた. その中で, 企業秘密のような組織情報やクレジットカード番号のような個人情報をどうやって守るか, 情報の改ざん防止に関する法律・条例を遵守するにはどうすればよいか, が新たな課題となっている.

これらセキュリティとコンプライアンスに関わる課題を解決し, 「参加の時代」 を実現するために, 今後のアイデンティティ管理には次のような機能が求められる.

  • アイデンティティ連携: 組織の壁を越えたアイデンティティ情報の再利用 (面白い表現だ)
  • アイデンティティ・サービス: 散在するアイデンティティ情報の統合
  • アイデンティティ監査・セキュリティ: アイデンティティに関するすべての活動の集中監視

Webcast: Beyond Provisioning - Expert Perspectives on Identity Auditing and Compliance

Sun, Deloitte & Touche, Gartner による, アイデンティティ管理とコンプライアンスに関するウェブキャスト. PDF 形式のスライドがダウンロードできる.

Customer Success: The Henkel Group

グローバルな製造業 (従業員約 5 万名, 世界 125 ヶ国に展開) における導入事例. Sun Java System Identity Manager により, 厳密な認可とアクセス管理, SAP R/3, Lotus Notes, Microsoft Active Directory, Novell eDirectory の ID 統合, 既存ID管理システム (メインフレーム) のリプレースを実現した.

Sarbanes-Oxley Compliance Journal: How to Solve Your Biggest Compliance Problem in a Sustainable Way

Sara Gates が Sarbanes-Oxley Compliance Journal に寄稿した, アイデンティティ・ベースの監査についての記事.


そのほか Sun Java System Directory Server Enterprise Edition における Active Directory から Directory Server へのパスワード同期の技術 Q&A, アイデンティティ連携のホワイトペーパー, 今月行なわれる Burton Group Catalyst Conference でのおトク情報など, 経営層向けから技術寄りまでいろいろなネタが盛り込まれている. Sun のソリューションに限らずアイデンティティ管理に興味のあるかたはぜひどうぞ.

Wednesday Feb 02, 2005

Sun Java Identity Management Suite

Sun Java Identity Management Suite

今朝未明の Network Computing 05Q1 にて, Sun Java System Suites が正式発表された. Sun Java Identity Management Suite はそのスイート群のひとつ. 従業員一人あたり年額 $50 で, Sun のアイデンティティ管理製品が使い放題 (an infinite right-to-use). 日本での展開も近々明らかにできるはず.

Friday Oct 15, 2004

Red Hat to Acquire Netscape Enterprise Solutions

Sun Java System Directory Server (SJS DS) のアーキテクトである Ludovic が, Red Hat の Netscape サーバ製品買収についてコメントしてる. 曰く (かなり意訳):

... たしかに Red Hat は Netscape サーバ・ソフトウェアを手にいれたわけだけど, 以前のような顧客ベースや, 技術的 / マーケティング的な優位性, 市場での認知度はとうの昔に無くなってしまってる.
そもそも今日顧客が必要としているのは単なるディレクトリ・サーバなんかじゃなくて, 堅牢な 『アイデンティティ・データ・サービス』 (また新しい言葉だ!) なんだよね.
それこそがまさに SJS DS Enterprise Edition であり, LDAP プロクシ機能, Active Directory との同期機能, リソース・キットが詰め込まれてるんだ ...

で ``I'm curious to see (中略) how they are going to manage to open source some software that has non transferable patents'' と前置きした上で, 彼は最後にこう締めくくる:

And if they succeed to open source it, I'll be watching people's discussions about the code that I wrote more than 3 years ago!

自分の昔書いたコードについてあれこれ言われる (しかもたぶん大人の事情でコメントできない!?) のは, どんな気分なんかなー ;)

About

tkudo

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today