Почти все проверяющие стороны OpenId отклоняют утверждения от моего провайдера, поддерживаемого dotNetOpenAuth - PullRequest
5 голосов
/ 20 апреля 2011

Создавая поставщика OpenId, я столкнулся с любопытной проблемой, что только сайты Stack Exchange примут его.

Обнаружение работает нормально, и, наблюдая за трафиком журнала, я посылаю (как мне кажется) верный ответ обратно.

Удивительно, что нет никаких тестов на соответствие *, чтобы сказать мне, что не так, и большинство сайтов, которые предлагают вход в систему через OpenId, не дают вам полезных сообщений об ошибках. Переполнение стека дает некоторые, но, похоже, это единственная доверяющая сторона, которая просто принимает мои утверждения, так что ... да.

Во всяком случае, если я попытаюсь войти (например) Typepad Я в конечном итоге перенаправить обратно на URL, как

https://www.typepad.com/secure/services/signin/openid?openid-check=1&archetype.quickreg=1&tos_locale=en_US&portal=typepad&oic.time=1303249620-9db5665031c9c6b36031&openid.claimed_id=https://example/user/8c481fb7-1b5c-4e50-86b5-xxxxxxxxx&openid.identity=https://example/user/8c481fb7-1b5c-4e50-86b5-xxxxxxxxx&openid.sig=hoaxQrsN4BBg6H8kp50NoQwpHmcO96BBe+jB3oOP2UA=&openid.signed=claimed_id,identity,assoc_handle,op_endpoint,return_to,response_nonce,ns.alias3,alias3.mode&openid.assoc_handle={634388464235195799}{oqMrOA==}{32}&openid.op_endpoint=https://example/openid/provider&openid.return_to=https://www.typepad.com/secure/services/signin/openid?openid-check=1&archetype.quickreg=1&tos_locale=en_US&portal=typepad&oic.time=1303249620-9db5665031c9c6b36031&openid.response_nonce=2011-04-19T21:47:03Z1aa4NZ48&openid.mode=id_res&openid.ns=http://specs.openid.net/auth/2.0&openid.ns.alias3=http://openid.net/srv/ax/1.0&openid.alias3.mode=fetch_response

Вычеркнуто для (немного) более легкого чтения:

openid-check=1
archetype.quickreg=1
tos_locale=en_US
portal=typepad
oic.time=1303249620-9db5665031c9c6b36031
openid.claimed_id=https://example/user/8c481fb7-1b5c-4e50-86b5-xxxxxxxxx
openid.identity=https://example/user/8c481fb7-1b5c-4e50-86b5-xxxxxxxxx
openid.sig=hoaxQrsN4BBg6H8kp50NoQwpHmcO96BBe+jB3oOP2UA=
openid.signed=claimed_id,identity,assoc_handle,op_endpoint,return_to,response_nonce,ns.alias3,alias3.mode
openid.assoc_handle={634388464235195799}{oqMrOA==}{32}
openid.op_endpoint=https://example/openid/provider
openid.return_to=https://www.typepad.com/secure/services/signin/openid?openid-check=1
archetype.quickreg=1
tos_locale=en_US
portal=typepad
oic.time=1303249620-9db5665031c9c6b36031
openid.response_nonce=2011-04-19T21:47:03Z1aa4NZ48
openid.mode=id_res
openid.ns=http://specs.openid.net/auth/2.0
openid.ns.alias3=http://openid.net/srv/ax/1.0
openid.alias3.mode=fetch_response

Вот XRDS для пользователя (поскольку обнаружение кажется нормальным).

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
    <XRD>
      <Service priority="10">
        <Type>http://specs.openid.net/auth/2.0/signon</Type>
        <LocalID>https://example/user/8c481fb7-1b5c-4e50-86b5-xxxxxxxxx</LocalID>
        <Type>http://openid.net/extensions/sreg/1.1</Type>
        <Type>http://axschema.org/contact/email</Type>
        <URI>https://example/openid/provider</URI>
      </Service>

      <Service priority="20">
        <Type>http://openid.net/signon/1.0</Type>
        <Type>http://openid.net/extensions/sreg/1.1</Type>
        <Type>http://axschema.org/contact/email</Type>
        <URI>https://example/openid/provider</URI>
     </Service>
   </XRD>
</xrds:XRDS>

Если вы покопаетесь в html TypePad, вы увидите следующее сообщение об ошибке

<!-- Error Code: unexpected_url_redirect -->

... вот почему я использую их в качестве примера. Вид бесполезный, но это что-то.

Этот код в значительной степени основан на примере проекта MVC, который поставляется с dotNetOpenAuth , реализация SendAssertion - это то, где я подозреваю вещи заболевают.

protected ActionResult SendAssertion(IAuthenticationRequest authReq)
{
    // Not shown: redirect to a prompt if needed

    if (authReq.IsDirectedIdentity)
    {
        authReq.LocalIdentifier = Current.LoggedInUser.GetClaimedIdentifier();
    }
    if (!authReq.IsDelegatedIdentifier)
    {
        authReq.ClaimedIdentifier = authReq.LocalIdentifier;
    }

    authReq.IsAuthenticated = this.UserControlsIdentifier(authReq);

    if (authReq.IsAuthenticated.Value)
    {
        // User can setup an alias, but we don't actually want relying parties to store that since it can change over time
        authReq.ClaimedIdentifier = Current.LoggedInUser.GetClaimedIdentifier();
        authReq.LocalIdentifier = Current.LoggedInUser.GetClaimedIdentifier();

        // Not shown: responding to AX and SREG requests
    }

    var req = OpenIdProvider.PrepareResponse(authReq);
    var ret = req.AsActionResult();

    return ret;
}

Извините, это такой огромный информационный дамп, но мне нечем заняться, и, соответственно, я не могу сузить его до чего-то простого.

Так что, я думаю, главный вопрос в том ... есть идеи, что я здесь не так делаю?

* ОК, есть сортировки . Но ничто не говорит "ах-ха, это сломано".

1 Ответ

1 голос
/ 27 апреля 2011

Здесь оказалась целая куча других ошибок, ни одна из которых на самом деле не относится к dotNetOpenAuth.

  1. Все это заставляет SSL и перенаправляет все HTTPвходящий трафик.
    • ... за исключением того, что перенаправление всего HTTP-трафика было на /, что нарушило обнаружение
  2. Обнаружение HTML было прервано.
    • , в то время как теоретически проверяющие стороны могут делать все обнаружение с использованием заголовков, на практике почти каждый в какой-то момент начинает анализировать HTML.и спецификации 2.0
      • это немного перекрывает # 2, но некоторые проверяющие стороны совершенно рады сделать обнаружение с заголовками (OpenId 2.0), но затем отправляются на поиски openid.server в возвращенном HTML.

dotNetOpenAuth как одна из (очевидно, немногих) библиотек OpenId, которая может выполнять весь танец OpenId над заголовками, работала просто отлично, по совпадению.

...