hdknr’s posterous

 
Filed under

openid

 

GMO-PGがOpenID決済サービスを開発、年内に提供開始予定 -INTERNET Watch

 現在GMO-PGでは、ECサイト構築オープンソース「EC-CUBE」でのOpenID決済サービス連携実証を進めている。具体的には、属性情報交換の拡張仕様「OpenID AX」を実装。年内にはAXのセキュリティ面をより強化した拡張仕様への対応も視野に入れているという。さらに、クレジットカード決済以外のさまざまな決済手段への拡張を視野に入れ、システム面、法制度面などでも関係機関と連携しながら評価・検証を行っていく考え。

Filed under  //   OpenID  

Comments [0]

Example usage of AX in PHP OpenID - Stack Overflow

Ran into the same issue. Some digging in AX.php got me a working start. Haven't looked for any bugs, nor tested beyond basic, nor tested with anyone other than Google. This is not pretty: needs error handling, etc. But this should get you started. Will post an update if I have something robust...

First to throw ...

//      oid_request.php

// Just tested this with/for Google, needs trying with others ...
$oid_identifier
= 'https://www.google.com/accounts/o8/id';

// Includes required files
require_once
"Auth/OpenID/Consumer.php";
require_once
"Auth/OpenID/FileStore.php";
require_once
"Auth/OpenID/AX.php";

// Starts session (needed for YADIS)
session_start
();

// Create file storage area for OpenID data
$store
= new Auth_OpenID_FileStore('./oid_store');

// Create OpenID consumer
$consumer
= new Auth_OpenID_Consumer($store);

// Create an authentication request to the OpenID provider
$auth
= $consumer->begin($oid_identifier);

// Create attribute request object
// See http://code.google.com/apis/accounts/docs/OpenID.html#Parameters for parameters
// Usage: make($type_uri, $count=1, $required=false, $alias=null)
$attribute
[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/contact/email',2,1, 'email');
$attribute
[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/namePerson/first',1,1, 'firstname');
$attribute
[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/namePerson/last',1,1, 'lastname');

// Create AX fetch request
$ax
= new Auth_OpenID_AX_FetchRequest;

// Add attributes to AX fetch request
foreach($attribute as $attr){
        $ax
->add($attr);
}

// Add AX fetch request to authentication request
$auth
->addExtension($ax);

// Redirect to OpenID provider for authentication
$url
= $auth->redirectURL('http://localhost:4001', 'http://localhost:4001/oid_catch.php');
header
('Location: ' . $url);

... and then to catch

<?php

//      oid_catch.php

// Includes required files
require_once
"Auth/OpenID/Consumer.php";
require_once
"Auth/OpenID/FileStore.php";
require_once
"Auth/OpenID/AX.php";

// Starts session (needed for YADIS)
session_start
();

// Create file storage area for OpenID data
$store
= new Auth_OpenID_FileStore('./oid_store');

// Create OpenID consumer
$consumer
= new Auth_OpenID_Consumer($store);

// Create an authentication request to the OpenID provider
$auth
= $consumer->complete('http://localhost:4001/oid_catch.php);

if ($response->status == Auth_OpenID_SUCCESS) {
        // Get registration informations
        $ax = new Auth_OpenID_AX_FetchResponse();
        $obj = $ax->fromSuccessResponse($response);

        // Print me raw
        echo '<pre>';
        print_r($obj->data);
        echo '
</pre>';
        exit;


} else {
  // Failed
}

Those ought to be the basics...

Filed under  //   Janrain   OpenID   PHP   PHP-Openid  

Comments [0]

JanRain: OpenID CX : CX Association MySQL Store (Draft) - Windows Live

DROP TABLE IF EXISTS `s_openid_cxassociations`;
CREATE TABLE IF NOT EXISTS `s_openid_cxassociations` (
`artifact` varchar(255) NOT NULL, ---- add
`realm` varchar(255) NOT NULL, ---- add
`server_url` blob NOT NULL,
`handle` varchar(255) NOT NULL,
`secret` blob NOT NULL,
`issued` int(11) NOT NULL,
`lifetime` int(11) NOT NULL,
`assoc_type` varchar(64) NOT NULL,
`proposal` blob NOT NULL, ---- add
`contract` blog NULL, ---- add
-- PRIMARY KEY (`server_url`(255),`handle`)
PRIMARY KEY (`artifact`,`realm` ) ---- changed
) ENGIN
Check out this website I found at hdknr.spaces.live.com

この方式だと変更がおおきすぎるな。。。 Association ← Contract のERでContractを追加したほうがいいかも。

Filed under  //   CX   OpenID  

Comments [0]

Identity Metasystem Interoperability (Pairwise Pseudonym Identifier, Private Personal Identifier)

7.5.14 Private Personal Identifier

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

Type:  xs:base64binary

Definition:  A private personal identifier (PPID) that identifies the Subject to a Relying Party. The word “private” is used in the sense that the Subject identifier is specific to a given Relying Party and hence private to that Relying Party. A Subject’s PPID at one Relying Party cannot be correlated with the Subject’s PPID at another Relying Party. Typically, the PPID SHOULD be generated by an Identity Provider as a pair-wise pseudonym for a Subject for a given Relying Party. For a self-issued Information Card, the Self-issued Identity Provider in an Identity Selector system SHOULD generate a PPID for each Relying Party as a function of the card identifier and the Relying Party’s identity. The processing rules and encoding of the PPID claim value is specified in Section 7.6.

Compatibility Note:  Some existing Identity Selectors omit listing the PPID claim as an ic:SupportedClaimType from the ic:SupportedClaimTypeList when saving a self-issued Information Card in the Information Cards Transfer Format defined in Section 6.1, even though the PPID claim is supported by the card.  This behavior is deprecated, as all supported claims SHOULD be listed.  Nonetheless, Identity Selectors MAY choose to recognize this case and support the PPID claim for self-issued cards not explicitly listing this claim.

PPIDはRPに対するSubjectの識別子。「プライベート」はSubject識別子があるRPに専用のもので、つまりRPに対してプライベートということ。あるRPでのSubjectのPPIDは他のRPでのSubjectのPPIDと関連性を持ってはいけない。たいていはPPIDは与えられたRPに対するサブジェクトの”pair-wise pseumonym"としてのIdentity Providerによって生成されるべき。自己発行情報のCardではIdentity Selectorシステムの自己発行Identity ProviderがそれぞれのRPのPPIDをカード識別子とRPのアイデンティティの関数として生成すべき。PPIDのクレーム値の処理ルールとエンコーディングは7.6章。

(そのうち訳を見直すよ)

Filed under  //   identity   OpenID   PPID  

Comments [0]

Diffie-Hellman鍵交換とは - ZDNet Japan

Diffie-Hellman鍵交換方式を利用すれば、秘密鍵をやり取りする必要がないため、秘密鍵暗号方式と比べてネットワーク上の盗聴などに強いという特徴がある。
その反面、通信経路上で暗号を解読する「中間者攻撃」の手法には強くないとされる。
そのためDiffie-Hellman鍵交換は別の暗号化アルゴリズムと組み合わせて用いられることが多い。
Diffie-Hellman鍵交換を採用した代表的な公開鍵暗号としては、RSAやエルガマル法を挙げることができる。

Filed under  //   Diffie-Hellman   OpenID   Security  

Comments [0]

ディフィー・へルマン鍵共有 - Wikipedia

このプロトコルは、通信を行いたい2者が各々公開鍵と秘密鍵 (私有鍵ともいう) を用意し、公開鍵のみを公開する。そして、お互いに秘密の値から作成されるデータを相手に送信し、各自、自分の秘密鍵と受信したデータから共通鍵を作成できる方法である。第三者が送受信されるデータを盗聴しても鍵を生成することができない所に特徴がある。

Filed under  //   Diffie-Hellman   OpenID   Security  

Comments [0]

OpenID Authentication 2.0 - Final : 11.4. Verifying Signatures (俺訳)

http://openid.net/specs/openid-authentication-2_0.html#verifying_signatures

11.4.  Verifying Signatures

If the Relying Party has stored an association with the association handle specified in the assertion, it MUST check the signature on the assertion itself. If it does not have an association stored, it MUST request that the OP verify the signature via Direct Verification (Verifying Directly with the OpenID Provider).

RPがアサーションに関連付けられたアソシエーションハンドルのアソシエーションを保存していたなら、シグネチャーをそのアサーションのものかを確認する必要がある。
もしもアソシーションを持っていなかったら「直接検証」によりOPに署名検証させるようにリクエストする。

11.4.1.  Verifying with an Association

The Relying Party follows the same procedure that the OP followed in generating the signature (Generating Signatures), and then compares the signature in the response to the signature it generated. If the signatures do not match, the assertion is invalid.

If an authentication request included an association handle for an association between the OP and the Relying party, and the OP no longer wishes to use that handle (because it has expired or the secret has been compromised, for instance), the OP will send a response that must be verified directly with the OP, as specified in Section 11.4.2 (Verifying Directly with the OpenID Provider). In that instance, the OP will include the field "openid.invalidate_handle" set to the association handle that the Relying Party included with the original request.

RPは「署名生成」でOPが従ったと同じ手順に従い、生成した署名に対する応答の署名と比較する。署名が一致していなかったらアサーションは不正である。
認証リクエストがOPとROPを関連(アソシエーション)付けるアソシエーションハンドルを含んでいてOPがそのハンドルをもう使いたくなくなったら(時間切れとかシークレットが危殆かしたとか)、OPはOPに対して直接検証するような応答を返す。11.4.2に示す。その場合、OPは"openid.invalidate_handle"フィールドを入れてそれにRPのオリジナルのリクエストに含まれているアソシエーションハンドルをセットする。

11.4.2.  Verifying Directly with the OpenID Provider

To have the signature verification performed by the OP, the Relying Party sends a direct request (Direct Request) to the OP. To verify the signature, the OP uses a private association that was generated when it issued the positive assertion (Positive Assertions).

OPに署名計算をやってもらうにはRPはOPに直接リクエストを送る。署名を検証するためにOPはプライベートアソシエーションを使うが、それはOPがポジティブアサーションを返したときに生成しておいたものである。

11.4.2.1.  Request Parameters (署名直接検証リクエスト)

  • openid.mode

    Value: "check_authentication"

  • Exact copies of all fields from the authentication response, except for "openid.mode". (その他認証応答に入っていたフィールドをそのまますべてコピる。ただしopenid.modeを除く

For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys. If the verification request contains a handle for a shared association, it means the Relying Party no longer knows the shared secret, or an entity other than the RP (e.g. an attacker) has established this association with the OP.

To prevent replay attacks, the OP MUST NOT issue more than one verification response for each authentication response it had previously issued. An authentication response and its matching verification request may be identified by their "openid.response_nonce" values.

署名検証のためにOPはプライベートアソシエーションだけを使う。共有キーを含んだアソシエーションは使わない。検証要求に共有アソシエーションのハンドルが含まれていれば、RPはすでに共有シークレットを忘れていることを意味するか、あるいはRP以外の誰か(つまり攻撃者)がOPにアソシエーションを張っていることを意味する。

リプレイ攻撃を防ぐためには以前に発行した認証応答と同じ検証応答を返さない。認証応答と対応する検証応答は"openid.response_nonce"の値を見て判断できる。



11.4.2.2.  Response Parameters(署名直接検証応答)

  • ns

    As specified in Section 5.1.2 (Direct Response).

  • is_valid (検証結果)

    Value: "true" or "false"; asserts whether the signature of the verification request is valid. (Trueが正しい署名、Falseは不正署名)

  • invalidate_handle (不正ハンドル)

    Value: (optional) The "invalidate_handle" value sent in the verification request, if the OP confirms it is invalid. (OPが不正と判断したときに送る)

    Description: If present in a verification response with "is_valid" set to "true", the Relying Party SHOULD remove the corresponding association from its store and SHOULD NOT send further authentication requests with this handle. "is_valid"="true"の検証応答があれば、RPは対応するアソシエーションを削除して、今後このハンドルを送らないようにする)

  • Note: This two-step process for invalidating associations is necessary to prevent an attacker from invalidating an association at will by adding "invalidate_handle" parameters to an authentication response. (アソシエーション無効化のための2ステップの手順が攻撃者がアソシエーションを無効化するのを防ぐために必要である。)

Filed under  //   OpenID  

Comments [0]