(Translate to English)
Tuesday Apr 01, 2008
I have very little knowledge on both
Shibboleth
specification and implementation however, It seems easy to
integrate
Sun Java System Access Manager /
OpenSSO
with it to
centralize user authentication into single access management
infrastructure and provide some other strong authentication methods such as client certificate,
finger vein etc.
The integration
point is REMOTE_USER variable between the Shibboleth IdP and
Application Server with Policy Agent, just like what
Paul did for
Sun Secure Global Desktop / Access Manager integration.
Sets the principal name in the IdP to REMOTE_USER as
determined by the web server or container's authentication,
similar to Shibboleth 1.3.
IdPUserAuthn - Shibboleth 2 Documentation - Internet2 Wiki
The user ID value is used by the agent to set the value of the
REMOTE_USER server variable.
Setting the REMOTE_USER Server Variable (Sun Java System Access Manager Policy Agent 2.2 Guide for Apache HTTP Server 2.2)
The key step here (doco)
in order to get it working is to modify the Tomcat server.xml
to look like the following, this ensures that Apache forwards
the value of REMOTE_USER to the Tomcat engine: [...]
Sun Grenoble Engineering Identity/Desktop Event : I'll Get My Coat
Here's a simple diagram. Let me know if I missed something.
(Translate to English)
Tuesday Nov 06, 2007
岩片さんのエントリを読んで,
すっかり告知し忘れてたことに気づいたんだけど
(なんか最近
blogs.sun.com/swjp
とごっちゃになってる),
明日からオープンする
Sun Tech Days 2007 in Tokyo の展示コーナーにて
「Sun アイデンティティ管理ソリューション」 のブースを担当する予定.
セッションの合間や, あるいは明日 19:15 からのレセプションで一杯ひっかけつつ,
お立ち寄りいただければ幸いです.
(Translate to English)
Wednesday Oct 10, 2007
二日目の火曜日は,
午前が全体セッションと
UltraSPARC T2 サーバのローンチ (CEC の会場 + 聴衆をそのまま使って生 Webcast した).
午後がブレイクアウト x 5 コマ, 休憩はさんで 6 時間.
全体セッションに登場した一人目は
Dave Douglas.
このひとのプレゼンテーションを観たのははじめてだったけど,
定量的なデータとか, ダイアログ (会話) とかのスライドへの取り入れかたがいろいろ参考になる.
内容自体もなかなか面白かったんだけど
(とくに
「発電所からきた電力がデータセンター内のサーバに届くまでにどれくらいのロスが発生しているか」
の具体的な数値),
公開してもいいのかどうかちょっとあやしいのでここでは割愛.
そして二人目は
Jonathan Schwartz.
いつも通りスマート.
そういえば,
BusinessWeek の Jonathan に関する記事
(via
shingoy のブックマーク)
はオススメ.
本日参加したブレイクアウトは以下の通り:
- Sun Software Infrastructure Platform
- Project Kevlar ネタ.
- Web 2.0, the Nitty-Gritty (はじめの 15 分だけ)
- Tim Bray のセッション.
序盤を聴く限り,
こないだ用賀でやったやつと同じような内容っぽかったので,
途中で退室.
- Enterprise Level Role Based Access Control: The Coming Perfect Storm
(開始後 20 分から聴講)
- ...というのも,
同じ時間にもうひとつおもしろそうなセッションがあったから.
それがこの, RBAC の話 by
Identity Crisis
の人.
Constrained RBAC とか, Symmetrical RBAC とか.
- A biometric authentication integrated with JES in a systemic security
architecture
- Axsionics
のデモ.
ちょっと内職しながら聴講してたので (すみません...
でも某記事広告レビューの締切が今日だったので...)
はじめはよくわからなかったんだけど,
一緒に出てた岩片さんからあとで話をきいたところでは,
これはかなりおもしろいデバイスだった.
イメージとしては,
トークン・カードの PIN のかわりに指紋が使えるような感じ.
そしてデバイスには光学インターフェースが内蔵されていて,
ディスプレイに表示される点滅コード (flickering code)
を読み取ることができる (つまり, ディスプレイ経由でデバイスにデータを転送できる)
ようになっている.
- Identity Manager Security Considerations
- Sun Java System Identity Manager
システムを導入するにあたっての,
そのシステムの周辺を含めたセキュリティを,
BSI
の階層モデルにしたがって考察.
- Using Sun's Velocity Identity Deployment Tool (VIDT) to Achieve Quality Implementations of Sun Java Identity Manager
- VIDT
ネタ.
おまけ: 本日の, そのほかの写真を何枚か.
まず, ローンチ後に
T5120
を激写する岡崎さん.
Project Blackbox
の輸送車.
さすがにこれは日本にもってこれないよなー.
日本から持参した
Sun Ray 2N
をホテル内の WiFi につないで,
会社に VPN 接続し,
その上で東京の環境で動いている Solaris のデスクトップを手元にとばしてきて,
Thunderbird
でメールをチェックする大串さん.
今晩のパーティで,
あまりおいしいものが食べられず不満気味の (そんなことない!?),
山口さんと岡崎さん.
(Translate to English)
Wednesday Sep 19, 2007
SDC 連載
「アイデンティティ管理の基礎と応用」
の第 9 回は,
前回インストール・設定した
OpenID Extension for OpenSSO
の動作確認.
今回は、 OpenID Extension for OpenSSO (以下 OpenID Extension) の動作を確認していきます。
アイデンティティ管理の基礎と応用(９):OpenID Extension for OpenSSO: OpenSSO の能力を活かした OpenID プロバイダの構築 (2/2)
本連載では
OpenID Extension の動作に最低限必要な設定の紹介にとどまっているけど,
これを実際の運用にあたってどのように構成していくかは,
Hubert
が
OpenID.sun.com
システムに関してまとめた以下のエントリが参考になると思う.
- OpenID @ Work - Architecture
- OpenID.sun.com の提供するサービスの構成.
ぼくの書いた記事の中ではユーザの登録を OpenSSO 管理者 (amadmin) が手動で行なったり,
OpenID Identifier でポイントされる HTML を静的に置いたりしたところを,
一方の OpenID.sun.com ではユーザ登録を OpenSSO の機能を使ってセルフサービス化し,
また HTML を動的に生成しているところがポイント.
- OpenID @ Work - Infrastructure Description
- OpenID.sun.com の機器構成.
ぼくの書いた記事の中では全部をひとつの GlassFish インスタンスで実行してるところを,
OpenID.sun.com ではユーザ情報をちゃんと Directory Server に格納し,
かつ OpenSSO も含めて冗長化.
さらに前段にファイアウォール / ロード・バランサを配置して,
負荷分散と SSL の終端処理も行なっている.
なお前回と今回の記事をご覧いただくとわかるように,
OpenID Extension は OpenSSO とは独立して動作する
Web アプリケーションとして実装されている
(OpenSSO からみると, OpenID Extension は Policy Agent
インスタンスのひとつとして認識される).
つまり OpenSSO 側には単に OpenID Extension
からの通信を受けつけるための接続情報だけ登録すればよくて,
OpenSSO システムになにか特別なモジュールを組み込む必要はない.
そしてぼく自身はまだ確認できていないんだけど (すみません),
この OpenID Extension は
Sun Java System Access Manager
システムと組み合わせても動作するはず.
もしすでに Sun Java System Access Manager を導入・運用されているサイトで,
さらに OpenID プロバイダの実現可能性を探りたいという野望 (?) をお持ちのかたは,
既存の環境にほとんど影響を与えずに導入することのできる OpenID Extension
for OpenSSO を, ぜひおためしください!
(Translate to English)
Wednesday Jul 25, 2007
昨年末に
2007 年はどうなるか. まず, IdM とは 「パッケージをいれればオッケー」 ではなく 「継続的なイニシアチブ」 であることに多くの人が気づく. あと, 「職務分掌徹底のためのアクセス権限管理の大変さ」 がようやく実感されるようになる. 最後に, SAML 2.0 が ASP / アウトソーシング方面で地味に広がる.
IdM ゆく年くる年 - tkudo's weblog about identity management
と予測したけど,
とりあえず三番目のやつは的中ってことでいいですかね.
(要求仕様のひとつに 「アカウント情報を学内各種情報システムと連携」 という利便性を実現する必要があったが) SAML ベースの Single Sign-On （SSO） API の利用によって実現への確証を得た。(中略) SSO を用いればキャンパス内の全ての IT サービスへの展開をも可能とする。
Google Apps Education Edition の導入事例: 日本大学
Gmailならサーバからサポートまで無料で利用できる上、ライブドアとのID連携機能も容易に構築可能だ。「公開仕様のSAML（Security Assertion Markup Language）に対応しているから、ID連携も当社が開発でき、相手先が作業し終わるのを待つ必要もない」
livedoorメールにGmail採用 「黒字化へ最後の一押し」 - ITmedia News
このまま
- Google Apps / Gmail を利用したい企業が増える
- 利用する上で, さらに SSO したい企業 (アウトソーサー) は,
自社のアクセス管理 / SSO システムに SAML2 IdP 機能を付加することになる
- 結果的に SAML2 IdP 機能を持った企業が増える
- それらの企業が, Google Apps / Gmail 以外のサービス・プロバイダ (アウトソーシー) にも
「御社も SAML2 SP 対応してよ (そうすれば自社の SAML2 IdP がさらに活用できるから)」
とリクエストする
- それを承けてサービス・プロバイダも自社のサービスに SAML2 SP 機能を付加することになる
- 結果的に SAML2 SP 機能を持ったサービス・プロバイダが増える
- それらのサービス・プロバイダのサービスを利用したい企業が増える
- 2. にもどる
となって, さらに 2. と 3. のあいだに
- 企業が
Sun Java System Access Manager
を導入して自社のアクセス管理 / SSO システムを SAML2 IdP 対応にする
加えて 5. と 6. のあいだに
- サービス・プロバイダが
Sun Java System Federation Manager
を導入して自社のサービスを SAML2 SP 対応にする
が入るといいなー.
(Translate to English)
Thursday Jun 21, 2007
今月の SDC 連載
「アイデンティティ管理の基礎と応用」
は
アイデンティティ Web サービス.
IdM の基本的なところは,
これでひととおりおさえた, かな...
相互に連携する Web サービスを、
最終的にサービスを受ける 「利用者」 を中心に置いて実行させるには、
すべての Web サービスが 「そのサービスをリクエストしている大元は誰か」
を認識することが必要です。
そのためには、
Web サービス間で 「ユーザのアイデンティティ」
を相互に流通させることが必要です。
これを実現するためのアーキテクチャが、
「アイデンティティ Web サービス」 です。
アイデンティティ管理の基礎と応用(６):アイデンティティ Web サービス:エンド・ツー・エンドのアイデンティティ連携
(Translate to English)
Friday May 18, 2007
SDC 連載
「アイデンティティ管理の基礎と応用」,
第 5 回の今月はアイデンティティ・フェデレーション.
アイデンティティの文脈での 「フェデレーション」 の定義についてはいろいろあると思うけど,
ここでは以下のようにしてみた.
インテグレーション (統合) やシンクロナイゼーション (同期) ではなくフェデレーション (連携) という言葉を用いていることからもわかるように、 アイデンティティ・フェデレーションとは、 個々のアクセス管理 / SSO システムに存在するアイデンティティ情報を、 ユーザを軸として互いにひもづけることです。
アイデンティティ管理の基礎と応用(5): アイデンティティ・フェデレーション: 別々に管理されたアイデンティティ情報の連携
あくまでもひもづけの対象は 「アイデンティティ情報」 であって,
「認証の状態」 を結びつけているんじゃないんだよー, 「にんしょーれんけー」 じゃないんだよー,
ということを表現したつもりなんだけど, どんなもんだろうか.
あと Sun と Hewitt (人事アウトソーシング・サービス) との間で
Sun Java System Access Manager と
Sun Java System Federation Manager
を使ったフェデレーションが実際に運用されている事例 (もしかしたら世界初公表なのかも) は,
Sun IT の担当アーキテクトの
Yvonne Wilson
に確認したところ, 現時点では
「アーキテクチャ図とかはまだ描かないで」 とのことだった.
ということで残念ながら今回はここまでの内容にとどめざるをえなかったんだけど,
そのうちちゃんとした事例紹介として公開されるみたいなので, 乞うご期待あれ.
(Translate to English)
Thursday Apr 12, 2007
今月の SDC 連載
「アイデンティティ管理の基礎と応用」
は
アクセス管理 / SSO システムについて.
不十分なアクセス制御は利便性とセキュリティの両方を低下させてしまいます。 そこで、 各システムごとに行なっていたアクセス制御を集中的に運用・管理するための基盤が、 今回ご紹介するアクセス管理 / SSO (シングル・サインオン) システムです。
アイデンティティ管理の基礎と応用(4): アクセス管理 / SSO (シングル・サインオン) システム: ユーザの利便性とセキュリティの両立
そういや, 渋谷に
sso
という居酒屋があるらしい.
これは IdM 関係者としては行かざるをえないな...
(Translate to English)
Friday Mar 02, 2007
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 から関連エントリをピックアップ.
- Directory Server Enterprise Edition 6.0 is downloadable!!
- 花木さんのエントリ.
今回は、これまでの 5.x 版からのメジャーアップデートということで、
いろいろと新機能が取りそろえられておりますが、
詳しくは上記マニュアルをご覧いただくとして、
見た目の大きな変化としては、従来の管理コンソールが廃止され、
Web-based application 型の Directory Service Control Center(DSCC)
が新しい管理コンソールとなっております。
- Directory Server Enterprise Edition 6.0 is NOW available
- DSEE 6.0 の新機能一覧と,
ダウンロードするなら ZIP 版がオススメ, という話.
You can download DSEE 6 by
going here,
but you do need a Sun Download Center account. (中略)
You can scroll down and select the DSEE 6 zip
download, which I recommend.
- Data Distribution in DSEE 6
- DSEE 6.0 に含まれる Directory Proxy Server 6.0 の,
データ分散機能の紹介
I want to shift the focus of this entry to Directory
Proxy Server. (中略) it also two major new categories of
features: virtual directory operations and data
distribution. In this post, I want to focus on data
distribution.
- It's time to upgrade your Directory Service...
- ポインタいろいろ.
The DSEE 6.0 Evaluation Guide
(one of the new guide out of the
complete documentation set)
contains a quick
overview of the new features,
help on how to
get started
and much more. You may
also want to
check Mark, Jonathan, Neil's blogs in the coming days
and weeks for more information about Directory Server
Enterprise Edition 6.0.
- What's new in Sun Java Directory Server 6.0
- Directory Server, Identity Synchronization for Windows,
Directory Proxy Server の新機能一覧.
-
Here are snippets of what's new in Directory Server Enterprise Edition 6.0.
- Short Introduction to Directory Server 6
- Directory Server 6.0 のアーキテクチャ概要.
-
Here is a look at a few different aspects of Directory
Server architecture. This section touches on the following
topics.
- Sun Java System Access Manager 7.1 is here!
- Access Manager 7.1 の新機能概要.
-
Although it's been widely previewed in beta in the Netbeans Enterprise Pack and Java EE SDK, it's still worth calling out the new features.
(Translate to English)
Tuesday Feb 20, 2007
昨年の 8 月,
11 月
に引き続き, またもや無料 IdM セミナーを来週の木曜 (3/1) に開催する.
セッションは今回も三本立てで, うちふたつを入れ替えた.
今回はじめてご参加される方だけではなく,
過去の同セミナーにご参加いただいた方にもお楽しみいただけるかと.
- アイデンティティ管理の基礎と応用 by 工藤
- 基本的には過去二回と同じ内容で,
認証基盤から内部統制, さらにはサービス連携, そして Sun の IdM ポートフォリオまで,
ざっくりとご紹介.
- ここまでできる! アイデンティティ管理による内部統制環境構築・評価・監査の効率化 by
佐藤さん
- Sun Java System Identity Manager を使ってアクセス権限管理をどう統制するか,
のお話.
- アクセス権限管理からはじめるシングル・サインオン (SSO) システムの構築
by 岩片さん
- 「SSO 入れるとアクセスが簡単になってセキュリティが下がる」
なんてことにならないためにはなにが必要か, の解説.
前回・前々回の集客状況から判断すると,
今回もすぐ定員に達してしまうのではないかと思う.
お申し込みはお早めに.
(Translate to English)
Tuesday Nov 28, 2006
jp.sun.com のホーム・ページにも掲示されている通り,
来週末 (12 月 8 日 金曜日), 用賀にて
Sun ソフトウェアてんこもりのイベントを開催する.
イベントの全体はきっと徹さんや大渕さんが紹介すると思うので,
ここではアイデンティティ管理関連のセッションをピックアップ:
ぼくは今回ビジネス・ガバナンス・プロジェクトの帽子をかぶって,
Sun の内部統制ソリューション全般をご紹介する予定.
ということで,
実はこの日はほかにもいろいろイベントが重なってたりしますが,
こちらにもぜひご来場いただければありがたいです...
(Translate to English)
Thursday Oct 19, 2006
地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版)
という文書の 「3.5.4 ＩＤ及びパスワード等の管理」 に書かれている遵守事項の例文が,
なかなかすごいことになっている:
(3) パスワードの取扱い
職員等は、自己の管理するパスワードに関し、次の事項を遵守しなければならない。
- パスワードを秘密にし、パスワードの照会等には一切応じてはならない。
- パスワードを記載したメモを作成してはならない。
- パスワードは十分な長さとし、文字列は想像しにくいものにしなければならない。
- パスワードが流出したおそれがある場合には、情報セキュリティ管理者に速やかに報告し、パスワードを速やかに変更しなければならない。
- パスワードは定期的に、又はアクセス回数に基づいて変更し、古いパスワードを再利用してはならない。
- 複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない。
- 仮のパスワードは、最初のログイン時点で変更しなければならない。
- パソコン等の端末のパスワードの記憶機能を利用してはならない。
- 職員等間でパスワードを共有してはならない。
地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版)
これらひとつひとつの項目はまっとうな内容に思えるけど
(6 を除く. 理由は後述),
すべてを同時に達成することって実際にできるんかな!?
とくに上で強調 (太字) した5 項目を遵守するのは相当難易度高いと思うなあ.
ヘタすれば, どれも守れなくて結局セキュリティは低下,
しかもユーザの利便性はどん底,
パスワード忘れの問い合わせへの対応は増える一方になるような気がする.
すこし前 ('02) の調査だけど,
IT システムを常用している一般的なユーザが管理しているパスワードの数は 21 個だという話がある.
また利用者がパスワードを完全にコントロールできる
(自分の覚えやすい文字列を使い, 自分が忘れる前に変更する)
ならまだしも, パスワード・ポリシー, たとえばよくあるところだと
- パスワードを変更するタイミング
- パスワードに使用することのできる文字種・長さ
- パスワード履歴に基づく使用禁止ポリシー
などは, そのパスワードを格納するシステムごとに異なっているはずだ.
そのような環境下でこんな運用↓をユーザに強制させることができるとすれば,
そこは相当記憶力がいい人の集まりに違いない.
- パスワードは十分な長さとし, 文字列は想像しにくいものにして下さい.
同一のパスワードをシステム間で用いてはならないことになっていますから,
システム毎に異なるパスワードを設定していただきます.
なおそのパスワードを記載したメモを作成してはならないですし,
またパソコン等の端末のパスワードの記憶機能を利用してはならないことは言うまでもありません.
最後に,
パスワードは定期的に, 又はアクセス回数に基づいて変更を強制されます. また古いパスワードを再利用してはならないように設定されています. ご注意下さい.
おそらく, この例文を作成した方は 「認証」 と 「認可」
をごっちゃにしていたのではないだろうか (ああ, またココにも
「認証基盤」 というダメ言葉の弊害が!).
その誤解を示しているのが, 項目 6 の
「複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない」
という文言.
たぶんパスワードがひとつ盗まれても他のシステムのパスワードは違うから,
被害は広がらないよーっていうことを意図してるんだろうけど,
本当に必要なのはそうではなくて,
システム / アプリケーションごとに適切な認証レベルを設定することのはずだ.
たとえばこんな感じ:
- 社員ポータルと Web
メールとインスタント・メッセージングは共通の認証レベルで十分であると定義し,
パスワードを一元化 (さらにはシングル・サインオン) する.
- 一方, 人事システムへのアクセスは人事担当者のみに制限する必要があるので認証レベルを上げ,
パスワードだけでなくディジタル証明書の提示も要求する.
- さらに, 経営情報管理システムはより高い認証レベルが必要であると定義し,
パスワードだけでなくディジタル証明書も必要,
特定の階 (ボード・ルームのあるフロア) の端末からしかアクセスを許可しない.
このへんの考え方は
「政府機関の情報セキュリティ対策のための統一基準」
を解説する
「政府機関統一基準の説明資料（2006年8月2日）」
の #81 - #95 になかなかよくまとめられている.
あとはもちろん,
弊社のアイデンティティ管理ソリューションもお忘れなく ;)
|
|
|
|
