1

現在、OpenID (C# および DotNetOpenAuth 経由) を使用して、アプリ A (「彼らのアプリ」) とアプリ B (「私のアプリ」) の間のシングル サインオン機能を作成しています。

属性交換を利用して、アプリが提供するデータを取得したいと考えています。彼らの API は、AX リクエストがどのように見えるべきかを文書化しています。

openid.ns.ax              = http://openid.net/srv/ax/1.0
openid.ax.type.studentids = http://theirapp.com/path/student-ids

.ax 名前空間に注意してください。これは、OpenID の AX 仕様と一致しているようです。

これは、私が DotNetOpenAuth を使用して属性を要求および取得する方法です。これは、SOおよび無数の他のソースによって示唆されています。

FetchRequest ax = new FetchRequest();
ax.Attributes.AddRequired("http://theirapp.com/path/student-ids");
request.AddExtension(ax);

と

string sIDs = String.Empty;
if (fetch != null)
    sIDs = fetch.GetAttributeValue("http://theirapp.com/path/student-ids");

応答が AX 要求を完全に無視して戻ってきたとき、私は困惑しました。送信したクエリ文字列パラメーターを観察した後、実際には彼らのせいではないと思います。

openid.ns:http://specs.openid.net/auth/2.0
openid.ns.alias3:http://openid.net/srv/ax/1.0
openid.alias3.required:alias1
openid.alias3.mode:fetch_request
openid.alias3.type.alias1:http://theirapp.com/path/student-ids
openid.alias3.count.alias1:1

どうした、DotNetOpenAuth？「alias3」はどこから来たのですか? それは「斧」のはずです。私が使用しているアプリが AX 名前空間について過度に肛門的であるかどうか、または DotNetOpenAuth が必須の OpenID プロトコルに注意を払っていないかどうかはわかりません。

それで、このすべての構築の後、私の質問：

  1. AX リクエストは、openid.alias3 ではなく、名前空間 openid.ax にある必要があります。DotNetOpenAuth にそれを強制するにはどうすればよいですか?
  2. API では、要求されたプロパティに名前を付ける必要があります。この場合は、'student-ids' です。上記では、「alias1」などのデフォルト名を取得しています。カスタム名でプロパティにラベルを付けるように DotNetOpenAuth を強制するにはどうすればよいですか?
  3. ここで正しいのは誰ですか: openid.ax または DotNetOpenAuth を要求しないための API ですか?
4

2 に答える 2

2

質問1：

AX リクエストは、openid.alias3 ではなく、名前空間 openid.ax にある必要があります。DotNetOpenAuth にそれを強制するにはどうすればよいですか?

DotNetOpenAuth では、特定の拡張機能のエイリアスを強制できません。特定のものを要求することは、OpenID 2.0 仕様に反します。AX 拡張機能自体でさえ、セクション 1.1 でこれを述べています。

openid.ns.<extension_alias>=http://openid.net/srv/ax/1.0

実際の拡張名前空間エイリアスは、複数の拡張間の競合を回避するような方法で、メッセージを構成する当事者によってメッセージごとに決定される必要があります。このドキュメントでは、属性交換サービスの拡張名前空間エイリアスは「ax」になります。

質問2：

API では、要求されたプロパティに名前を付ける必要があります。この場合は、'student-ids' です。上記では、「alias1」などのデフォルト名を取得しています。カスタム名でプロパティにラベルを付けるように DotNetOpenAuth を強制するにはどうすればよいですか?

最初の質問と同様に、DotNetOpenAuth は個々の属性のエイリアスを強制する方法を提供しません。これは、AX 拡張機能がこれらのタイプの要件を許可していないためです。属性のタイプは URI で指定されます。その属性のエイリアスは依拠当事者によって定義可能であり、OpenID プロバイダーは属性のタイプ URI を調べて、依拠当事者から取得したエイリアスを受け入れることになっています。

質問 3:

ここで正しいのは誰ですか: openid.ax または DotNetOpenAuth を要求しないための API ですか?

DotNetOpenAuth は正しいです。実際に、この学生 ID 交換について参照しているドキュメントと DotNetOpenAuth の間のエイリアスの違いが、AX 属性が無視されているという問題の根本原因である場合、障害はサーバーで実行されている OpenID プロバイダー。OpenID プロバイダーの不十分な実装は非常に恐ろしいものです。相互運用性が低いだけでなく、仕様を適切に実装する際の注意が不足していることを考えると、多くのセキュリティ上の問題が発生する可能性があることを示唆しているからです。

Fiddler またはその他の HTTP スニファーを使用してアウトバウンド リクエストをインターセプトし、すべてのエイリアスを修正して、ドキュメントが推奨するものと一致するようにし、問題が修正されるかどうかを確認することをお勧めします。その場合は、OpenID プロバイダーを修正する必要があります。彼らに連絡して、使用しているライブラリの新しいバージョンにアップグレードするように依頼することができます (これだけで修正されることを願っています)。エイリアスを「修正」しても問題が解決しない場合は、相互運用エラーの他の考えられる理由の調査に進むことができます。

于 2012-10-25T06:03:13.290 に答える
1

ありがとうスパムガイ。この問題を回避するためのハックを見つけたので、PowerSchool の OpenID プロバイダーの制限で同じ問題に遭遇する可能性のある他の人のために、ここに投稿しています。

通常、DotNetOpenAuth を使用してリクエストを作成し、リクエストからリダイレクト レスポンスを抽出する必要があります。これを取得したら、Location ヘッダーをプルして、必要に応じて名前空間の値を上書きできます。

この例は、MVC アプリケーション用です。WebForms アプリでこれを行う必要がある場合は、メソッドからロジックを取得して、行return redirectResponse.AsActionResult();をに置き換えredirectResponse.Send()ます。ThreadAbortExceptions の通常の try...catch... でこれをラップする必要があります。

使用される名前空間:

using System;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Mvc;
using System.Web.Security;
using DotNetOpenAuth.Messaging;
using DotNetOpenAuth.OpenId;
using DotNetOpenAuth.OpenId.Extensions.AttributeExchange;
using DotNetOpenAuth.OpenId.RelyingParty;

ハック：

const string NS_DCID = "http://powerschool.com/entity/id";
const string NS_USERTYPE = "http://powerschool.com/entity/type";

static readonly OpenIdRelyingParty openid = new OpenIdRelyingParty();

private ActionResult SubmitOpenIdRequest(string openid_identifier)
{
    var request = openid.CreateRequest(openid_identifier);

    var ax = new FetchRequest();

    // any modification to the following attributes will require a corresponding change in the string replacement hack
    ax.Attributes.AddRequired(NS_DCID);
    ax.Attributes.AddRequired(NS_USERTYPE);

    request.AddExtension(ax);

    var redirectResponse = request.RedirectingResponse;

    // PowerSchool is violating the attribute exchange specification, requiring specific namespaces and elements to function
    // Need to overwrite the values generated by OpenID to patch PowerSchool's incorrect provider implementation
    redirectResponse.Headers["Location"] = redirectResponse.Headers["Location"]
        .Replace("openid.ns.alias3", "openid.ns.ax")
        .Replace("openid.alias3.required=dcid%2Calias2", "openid.ax.required=dcid%2Cusertype")
        .Replace("openid.alias3.mode", "openid.ax.mode")
        .Replace("openid.alias3.type.alias1", "openid.ax.type.dcid")
        .Replace("openid.alias3.count.alias1", "openid.ax.count.dcid")
        .Replace("openid.alias3.type.alias2", "openid.ax.type.usertype")
        .Replace("openid.alias3.count.alias2", "openid.ax.count.usertype");

    return redirectResponse.AsActionResult();
}

注意: これは壊れやすいハックです。DNOA の内部変更または FetchRequest への変更により、置換ロジックが壊れる可能性があります。

于 2013-02-08T18:02:28.623 に答える