2013年2月28日木曜日

#idcon mini に参加してきた

Identity Conference Mini に参加しました。
　- http://atnd.org/events/36953


今日は、@hdknr さんによる OneID と Self-Issued OP の話と私が SCIM 関係の話をさせてもらいました。

@hdknr さんの OneID、Self Issued OP の話では、 OneID のサービスの話が聴けました。
ざっくりいうと、OP で認証するときに ID / Password の代わりに、スマートフォンを使って認証する、という仕組みのようです。
流れとしては、
１．ブラウザで RP へアクセス
２．OneID によりブラウザ上に QR コードが表示される
３．携帯電話で QR コードを読み、OP へ＝認証
４．ブラウザへトークンが渡され、RP へアクセス可能
というような感じでした。

PC と 携帯の間で KeyPair を共有しており、認証済みの携帯で QR コードを使って OneID へアクセスすることで認証とみなす、という形です。

メリットとしては
・パスワードがいらない
・OP へ渡る属性は暗号化されており、OP の運営者でも内容を参照できない
という2点がメインです。


次に、私が SCIM の話をしました。
若干無理やりではありますが、Windows Azure Active Directory がプロビジョニング API として Graph API を採用しているのは何故か？今後サービスプロバイダは SCIM を使うのが良いのか？Graph を使うのが良いのか？という話をしました。結果的に答えはないのですが、私の個人的な考えとしては、SCIM が目指したのはあくまでスキーマやプロトコルの標準化によるコスト削減や複雑性の低減で、Graph の目指すオブジェクト（ノード）とオブジェクト間の関係性（Edge）の表現とは別お世界であり、今後は現行の SCIM の様に同一レポジトリ内のオブジェクト間の関係（memberとmemberofなど）だけではなく、Federation などによる外部レポジトリ上のオブジェクトとの関係性についても表現することが大切になるのではないか？という話をさせていただきました。

以下が、資料です。
スライドにも書きましたが、答えがない世界なので色々と議論が継続的にできれば、と思います。

投稿者 時刻: 1:55 0 コメント
ラベル: , , , , , ,

2013年2月20日水曜日

[ADFS2.0] Rollup 3 がリリース


今月はシアトルに来ていたりするので、前後を含め色々と忙しくてこんなネタばっかりです。。

AD FS2.0 Rollup 3 がリリースされています。
　http://support.microsoft.com/kb/2790338

これまでの Rollup では機能拡張があったのですが、今回はバグフィックスのみです。
- Rollup 1 / Office365 対応の強化
　http://idmlab.eidentity.jp/2011/10/ad-fs20-rollup-1-office-365.html
- Rollup 2 / SAML 仕様対応の強化
　http://idmlab.eidentity.jp/2012/05/ad-fs20-rollup-2.html


  • Issue 1
    • AD FS 2.0 does not issue an ActAs token for a relying party who is using a Security Assertion Markup Language (SAML) 2.0 bootstrap token. When this issue occurs, the following error is generated:
    • System.IdentityModel.Tokens.SecurityTokenException: ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.
    • After you apply AD FS 2.0 update rollup 3, AD FS 2.0 successfully issues the token in this situation.
  • Issue 2
    • AD FS 2.0 acts as a federation provider and receives an invalid SAML 2.0 signed request (for example, the signature is not valid or the requestor is unknown). In this situation, AD FS 2.0 rejects the request only after it forwards the request to the downstream identity provider and receives a valid SAML response.
    • In order to make sure the validity of the requests that are sent to the downstream identity provider, the expected behavior is that AD FS 2.0 validates SAML requests and rejects any requests that have invalid signatures.
  • Issue 3
    • AD FS 2.0 update rollup 2 introduced strict Uniform Resource Identifier (URI) checking. When AD FS 2.0 acts as a federation provider and trusts an identity provider whose identifier is not an URI, the response that is returned from the identity provider is rejected by AD FS 2.0. The validation fails because AD FS 2.0 tries to validate the value of the identity provider’s identifier. This behavior breaks previously functioning AD FS 2.0 deployments in which identity providers use non-URI identifiers. AD FS 2.0 update rollup 3 removes this URI checking.
  • Issue 4
    • Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 is capable of allowing unique signature certificates to be applied to a relying party trust, but it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction and allows multiple relying parties to use the same signing certificate for SAML request.
  • Issue 5
    • Consider the following scenario:
    • You use a third-party hardware security module (HSM) to speed up the signing processes.
    • You use the third-party HSM and to generate and store the private keys.
    • The private keys are for AD FS 2.0 signing and for AD FS 2.0 encryption certificates.
    • In this situation, the performance of AD FS 2.0 is not as good as when you use Microsoft CSP. AD FS 2.0 update rollup 3 significantly improves the performance of AD FS 2.0 when HSM is used.
  • Issue 6
    • AD FS 2.0 update rollup 1 introduces the Congestion Avoidance Algorithm. If you accidentally disable the Congestion Avoidance Algorithm by changing the configuration, a handle leak occurs on an AD FS 2.0 federation server proxy every time that the federation server proxy processes a request. AD FS 2.0 update rollup 3 removes the setting that enables you to disable Congestion Avoidance Algorithm by changing the configuration. You can fine tune the Congestion Avoidance Algorithm by adjusting the latencyThresholdInMsec and minCongestionWindowSize settings.

投稿者 時刻: 8:33 0 コメント
ラベル: , , , , ,

[FIM2010] R2 SP1 リリース後、初の HotFix


早くも HotFix(4.1.3419.0)が出てます。
　http://support.microsoft.com/?id=2814853

基本的にバグフィックスのみですね。

FIM Synchronization service
  • Issue 1
    • In some cases, the Exchange configuration options on the Active Directory Management Agent do not appear. These options will now always be visible even if Exchange is not detected in the source directory.
  • Issue 2
    • When Exchange post-processing PowerShell cmdlets are run during export on the Active Directory Management Agent, the host process can stop for many reasons. In this case, the Active Directory Management Agent continues the export but does not try to run the Exchange cmdlets. With the changed behavior in this fix, the export run is now stopped so that the process can be restarted from where it ended.
  • Issue 3
    • The Synchronization service crashes in certain scenarios when references to newly created objects are exported into ECMA2 Connector (also known as "reference retry").
  • Issue 4
    • An ECMA1/XMA with call-based export crashes the Synchronization service. This problem occurs in some scenarios in which the following conditions are true:
    • Reference attributes are constantly rejected by the target directory.
    • The Synchronization service is trying to determine which value is causing the problem. It does this by trying to export a multivalued reference attribute as several individual changes (known as "fourth pass reference retry").
  • Issue 5
    • A full import might be stuck at the "Completing-Obsoletions" stage if the obsoletion of an object cascades into the obsoletion of related objects.


FIM service and portal

  • Issue 1
    • If a user who has access to advanced pages for a group (typically, an administrator) made a change to the object in this view, the group would contain invalid members. If the user was trying to delete the group, the system would be in a state in which no additional requests could be processed.


尚、HotFix を適用した後、Syncronization Service で拡張エージェント（ECMA1/ECMA2）を使っている場合に「stopped-extension-dll-load」エラーが出る場合があるので、その場合はちゃんと MIISServer.exe.config ファイルの dependentAssembly セクションを編集して正しいアセンブリのバージョンを参照するように設定してあげる必要があります。

しかし、機械翻訳の「Forefront ユーザー マネージャー 2010 R2」ってやめてほしいですねｌ。

投稿者 時刻: 8:17 1 コメント
ラベル: , , , , ,

2013年1月31日木曜日

ILM ブログ凍結・・・


一つの時代が終わったというか、、、Active Directory を含む Microsoft の ID 管理に少しでもかかわった人なら一度は見たことがあるはずの ADSI / IdM サポートチームの blog が凍結されました。

　管理者は見た！ ～ AD と ILM 一家の秘密 ～
　http://blogs.technet.com/b/jpilmblg/




初めてのエントリが 2008 年 8 月 20 日と、この blog の開始直前（ちなみにこの blog は 2008 年 10 月開始）にオープンした blog ということで若干かぶり気味に、互いによりコアな？ネタを追い求めつつこれまでやってきたので非常に残念です。


ILM blog 第1回
　はじめまして。ADSI/ILM サポートチームです！
　http://blogs.technet.com/b/jpilmblg/archive/2008/08/20/adsi-ilm.aspx


　　※しっかりリンクを張っていただいておりました。


ちなみにこの blog の第1回
　早速始めてみます
　http://idmlab.eidentity.jp/2008/10/blog-post.html



何はともあれ、約4年半もの長い間お疲れ様でした！


投稿者 時刻: 0:06 0 コメント
ラベル: , , , , ,

2013年1月24日木曜日

時代は認証から認可へ？ - XACML3.0 が OASIS 標準として承認

なんだか色々なところで混同されたり誤用されている、「認証」と「認可」というキーワードですが、ちょっと整理をしておきましょう。

  • 認証（Authentication）
    • 要するに本人確認
    • @IT/セキュリティ用語辞典より
      • ネットワークやサーバへ接続する際に本人性をチェックし、正規の利用者であることを確認する方法。一般には利用者IDとパスワードの組み合わせにより本人を特定する。認証がなされると、本人が持つ権限でデータへのアクセスやアプリケーションの利用が可能となる。不正利用を防ぐため、パスワードの漏えいなどには十分な注意が必要である。
  • 認可（Authorization）
    • 認証済みのユーザに対してサービスやリソースへのアクセスを許可すること
    • @IT/セキュリティ用語辞典より
      • 認証（Authentication）によって確認された利用者を識別して、アクセス権限の制御を行い、利用者ごとに固有のサービスを提供すること。
      • 具体的には、利用可能なアプリケーションの制御、ファイルに対する“読み／書き／実行”の権限など、利用者の資格に応じて許可する。認可のための属性情報には、利用者ID／所属グループ／役職／部署／アクセス制御リスト（ACL）などがある。
      • 運用管理の面から、認可はACL（Access Control List）で与えることがセキュリティ上でも望ましく、SSO（Single Sign On）でもACLと組み合わせることが多い。

OAuth や 本日のタイトルにある XACML は「認可」のための仕組みです。
よく OAuth 認証なんていうキーワードを見かけますが、認可サーバへのアクセス時に通常実行される認証プロセスを都合よく使ってしまっているだけであり、OAuth の本質は scope に指定したリソースへのアクセスするためのアクセストークンを認可サーバから受け取って、そのトークンを元に保護されたリソースへアクセスをする、ということです。


脱線しましたが、XACML 3.0 が OASIS 標準として承認されました。
XACML とは何なのか？について、わかりやすく説明するほど詳しくはないので、少し古いですが以下の記事が参考になると思います。（現状他に日本語で解説されているサイトを見たことありません）

　@IT / PKIとPMIを融合させる次世代言語XACML

引用すると以下のように解説されています。
柔軟で拡張性のあるアクセス制御を実現するためのポリシー記述言語XACML（eXtensible Access Control Markup Language）について述べる。SAMLやXACMLはPKIと権限管理のインフラストラクチャであるPMI（Privilege Management Infrastructure）を融合させる次世代のフレームワークである。

で、XACML の歴史ですが、OASIS 標準の Web ページによると、
 - 2003年2月　：　1.0 承認
 - 2005年2月　：　2.0 承認
ということで、今回の 3.0 の承認までにかなり間が空いていたことがわかります。
※個人的にはまだ続いてたんだ、、、という感想だったり。。

いずれにしてもなかなか概念の理解および実装が難しい仕組みなのでなかなか浸透していないイメージがありますが、今回の新版の承認で少しは前進するのかも知れません。

スペックは下記 URL で公開されていますので、興味のある人は参照してみてください。
（まだ Candidate と記載されています）
　eXtensible Access Control Markup Language (XACML) Version 3.0


ちなみに、製品として実装されている例としては、Oracle Entitlements Server (OES) があります。

　製品ページ

ページ内には Sharepoint との連携に関するホワイトペーパーなんかも置いてあるので機会があれば実装してみたいなぁ、、と思ったりします。

　Securing Microsoft Office SharePoint Server (MOSS) with Oracle Entitlements Server 11gr2

投稿者 時刻: 0:45 0 コメント
ラベル: , , , , , , ,

2013年1月23日水曜日

OpenID Foundation の会員登録方法


そう言えば会員登録していなかったので、登録してみました。
※ちなみに OpenID Foundation Japan への登録ではなく、OpenID Foundation への登録方法です。OpenID Foundation Japan への登録はホームページから問い合わせてください。

個人会員だと $25/Year です。

個人会員だと、以下のような特典があります。

  • Vote on OpenID workgroups, specifications, and community board members of the OpenID Foundation
  • Use the OpenID Foundation Member logo and signature on your blog, email, website, apps
  • Show your support for OpenID as a community-driven, user-centric identity for the Internet
  • Way to leverage financial support for an important grassroots community
  • Become part of the momentum of OpenID adoption and visibility


まずは、登録 URL へアクセスします。
　登録 URL
　https://openid.net/foundation/members/registration


サイトが表示されたら、まず最初に好きな OpenID でサインインします。


私は Google OP を使いました。




次に、Membership Type を選択します。個人登録をする場合は Indivisual - $25 を選択して、[Next Step] をクリックします。


Contact Information として OpenID Provider から取得した情報が表示されるので、必要に応じて修正して [Next Step] をクリックします。


次は規約への同意です。規約を熟読して問題なければチェックボックスにチェックを入れて [Next Step] をクリックします。


次は会費の支払いです。私が登録したときは何か調子が悪かったのかなかなか支払いがうまくいきませんでした。
支払い方法はクレジットカードか PayPal から選択できますので、私は PayPal を選択しました。


登録内容の確認画面が表示されるので、進むと PayPal にリダイレクトされ、決済を行います。




うまくいけばメンバシップ登録が完了し、メンバシップページへアクセスできるようになります。


皆さんもアイデンティティ界を盛り上げるため、是非登録してみてください。


投稿者 時刻: 1:11 0 コメント
ラベル: , ,

RFC化された OAuth 2.0 の翻訳完了

※1/24 追記：6749 core に加えて 6750 bearer についても翻訳が完了してます。

以前 OpenID Foundation Japan のワーキンググループで draft 22 の翻訳をした OAuth 2.0 ですが、先日お伝えした通り無事 RFC 6749 / 6750 となりました。

と、言うことで同じく OpenID Foundation Japan のワーキンググループで RFC 版の翻訳を行いました。




以下のページで公開されています。
　OpenID Foundation Japan ホームページ
　http://openid-foundation-japan.github.com/


draft 22 のベースがあるとは言え、たった数人で始めてから2週間弱で公開できたのは、素晴らしい参加メンバのみなさんのおかげと言えると思います。是非活用していただければと思います。

翻訳メンバ：

  • Boku Kihara (Lepidum)
  • Kazuki Shimizu (Lepidum)
  • Masaru Kurahayashi (Yahoo! Japan)
  • Naohiro Fujie (Itochu Techno Solutions)
  • Noboru Kurumai (Fujitsu)
  • Nov Matake
  • Ryo Ito (mixi, Inc.)
  • Tatsuya Katsuhara (NRI)
  • Yusuke Kondo (Yahoo! Japan)


投稿者 時刻: 0:51 0 コメント
ラベル: , , ,
登録: 投稿 (Atom)