DeanHere / dotnetopenid

Automatically exported from code.google.com/p/dotnetopenid
0 stars 0 forks source link

identifier select and AuthenticationRequestMode.Immediate mode #116

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Is this issue relating to writing a Relying Party, a Provider, or both?

Relying Party

What steps will reproduce the problem?
(please include the actual Claimed Identifier or OpenID Url used to repro
the problem if possible)
1. Login with flickr.com (so, without username specified, let's do
autodiscovering) and AuthenticationRequestMode.Immediate mode.
2. You get AuthenticationStatus.SetupRequired response with
ClaimedIdentifier equals {http://specs.openid.net/auth/2.0/identifier_select}.
3. You do now AuthenticationRequestMode.Setup request with specified
ClaimedIdentifier (http://specs.openid.net/auth/2.0/identifier_select).

What is the expected output?
Sucessfully login with autodiscovered OpenID url. You can get it if login
from beginning with AuthenticationRequestMode.Setup mode and 'flickr.com'
claimed identifier.

What do you see instead?
I get "The remote name could not be resolved: 'specs.openid.net'" exception.

What version of the product are you using?  Official build?
Yep, official build DotNetOpenId 2.3.0

Can this problem be reproduced using the included samples?
Not sure, just use AuthenticationRequestMode.Immediate mode and flickr.com
as claimed identifier.

Please provide any additional information below.
According http://openid.net/specs/openid-authentication-2_0-12.html, par
7.3.1 claimed identifier
"http://specs.openid.net/auth/2.0/identifier_select" treated specially.

Original issue reported on code.google.com by derigel on 27 Jul 2008 at 9:31

GoogleCodeExporter commented 9 years ago
Thanks for reporting this, derigel.

As you point out, the "http://specs.openid.net/auth/2.0/identifier_select" is a
special string and isn't really a Claimed Identifier, and the library is 
designed to
hide this string from its users, so this is a bug.  

For now, you can workaround this by calling
IAuthenticationRequest.AddCallbackArguments and passing in the user-supplied
identifier so you can look it up when the Immediate mode authentication failure 
comes
back and use that when you try again using Setup mode.  

An interesting question to explore is what it should do instead.  "flickr.com" 
isn't
a Claimed Identifier either (it's an "OP Identifier"), so setting flickr.com 
into the
ClaimedIdentifier field doesn't make sense either.  We should probably set
ClaimedIdentifier to null.  But to make retrying with Setup easier, we could 
also add
an ProviderIdentifier property and set that in these cases.  That is 
'accurate', but
requires more web site code to handle since either ClaimedIdentifier or
ProviderIdentifier may have the value the caller wants to get at.  We could 
also add
a UserSuppliedIdentifier property that always works, but the danger in that is 
it
becomes easy for users to misunderstand how that property should be used and 
may use
it to store as the primary key in their users table instead of the 
ClaimedIdentifier,
which is a really bad thing for security.

This problem appears in v2.1 through v2.3.  Although if a breaking change is 
required
to fix it, we may only fix it in v2.3 or later versions.

I'll think more on this, and please, comments welcome.

Original comment by andrewar...@gmail.com on 27 Jul 2008 at 3:26

GoogleCodeExporter commented 9 years ago
Not to say we won't get to this, but setting priority to Low since this isn't an
implementation/interop defect and there is a workaround.

Original comment by andrewar...@gmail.com on 27 Jul 2008 at 3:27

GoogleCodeExporter commented 9 years ago
Thanks Andrew!
Workaround is fine.

Original comment by derigel on 27 Jul 2008 at 5:24

GoogleCodeExporter commented 9 years ago
I've added an ISetupRequiredAuthenticationResponse interface that
IAuthenticationResponse can be cast to when the result of an authentication 
attempt
is SetupRequired.  This new interface exposes a ClaimedOrProviderIdentifier 
member
that facilitates creating a new IAuthenticationRequest object so the 
authentication
can be retried using Setup mode.

It's in a private branch while the idea stabilizes.  

Original comment by andrewar...@gmail.com on 28 Jul 2008 at 2:46

GoogleCodeExporter commented 9 years ago
Fixed in 4c4d4673e6e499842bc8bdf429b2784d754d1925.

BREAKING CHANGE: RelyingParty.IAuthenticationResponse.ClaimedIdentifier returns 
null
instead of http://specs.openid.net/auth/2.0/identifier_select for failed 
directed
identity authentication scenarios.

Original comment by andrewar...@gmail.com on 9 Aug 2008 at 9:56

GoogleCodeExporter commented 9 years ago

Original comment by andrewar...@gmail.com on 19 Aug 2008 at 1:12