ClaimedIdentifier Problem with myOpenID: http or https?

views:

answers:

ClaimedIdentifier Problem with myOpenID: http or https?

When the user clicks the OpenIdButton to log on to myOpenID, they navigate to the myOpenID sign in page and are prompted for a Username and password.

The returned ClaimedIdentifier starts with https (note the 's')

When the user enters their username in the OpenIdLogin control the returned ClaimedIdentifier starts with http (no 's').

Why is this happening? More importantly, how can I rely on a consistent username in my database if the return value can change depending on the login technique?

Is this a bug or am I doing something wrong?

Ken

+1 A:

One (although not recommended) method would be to strip protocol path of the URL.

Also, it's not a bug in the library, it's just the same provider returning different identifiers for different authentication methods -- Google does it too (accounts vs profiles).

When user inputs 'x.myopenid.com', it's translated (according to the spec) to 'http://x.myopenid.com', so the server returns identity with http://.

If the user would input https://x.myopenid.com, the server would return identity with https://.

Another thing is that MyOpenID should redirect from http to https, but doesn't do so.

Mewp 2010-06-18 20:43:01

myOpenID doesn't redirect from http to https because there was a time when many RPs couldn't deal with https, so logging in with an http identifier had to be an option.Stripping the protocol off the claimed identifier isn't recommended, as you said, but one option would be to examine the user input, and if 1) there is no protocol and 2) there's an https entry in your existing account database for that identifier, then add https. Technically still a spec violation, but pretty safe.

keturn 2010-06-19 16:07:30

Stripping the scheme (protocol) from the claimed identifier isn't actually safe. It completely neutralizes the security provided by HTTPS. If any of your users use HTTPS to protect their identifier from DNS poisoning, stripping off the scheme eliminates that protection.

Andrew Arnott 2010-06-20 02:43:22

Another way to solve this is to set RequireSsl=true, so that "https:" is the default prepended scheme when the user types in name.myopenid.com instead of "http:". But it will also break everyone just using "http:". All RPs struggle with this. One thing you can do for myopenid.com in particular is automatically upgrade all http://myopenid.com accounts to https://myopeind.com, and then when users type in their id, check the IAuthenticationRequest.ProviderEndpoint for myopenid and if found, reset the auth request to use HTTPS instead. This unifies user identities -- safely.

Andrew Arnott 2010-06-20 02:46:12

Of course, the simplest method would be to just add an exception for myopenid.com. If you want to use SREG/AX with it, you have to do it anyway (because myopenid has broken support for both).

Mewp 2010-06-20 13:33:48

I don't think you have to make an exception for myopenid for sreg/ax. If you use the AXFetchAsSregTransform, DotNetOpenAuth takes care of it for you I believe.

Andrew Arnott 2010-06-27 14:32:28

@Andrew Arnott: As far as I know and have tested, MyOpenID does not properly support AX (as it requires a different namespace), neither does it support SREG in OpenID 2.0, contray to what it advertises (at least, I couldn't get it to work). Because of that, I have to have use OpenID 1.1 where newer version is avaiable, and therefore I need an exception. And yes, I transform AX parameters to SREG ones.

Mewp 2010-06-27 21:21:20

By the way, dotNetOpenAuth seems to have a mechanism for such exceptions, as seen here: http://github.com/AArnott/dotnetopenid/blob/master/src/DotNetOpenAuth/OpenId/Extensions/AttributeExchange/AXAttributeFormats.cs . If such exceptions were unnecessary, then I guess that class wouldn't exist.

Mewp 2010-06-27 21:35:43

The "exceptions" source file you link to isn't a per-OP exceptions list. It highlights the fact that AX has no official standard for type URIs (although some sets are more popular than others). But you still don't have to encode the exceptions in your own code. If you activate the AXFetchAsSregTransform behavior, DotNetOpenAuth automatically figures out what OPs need (myopenid.com included, although not hard-coded) and sends it to them and translates the result back so the RP doesn't have to do this.

Andrew Arnott 2010-06-29 21:32:17

That said, I wish myopenid.com would adopt the namespaces that most other OPs are using.

Andrew Arnott 2010-06-29 21:32:54

I thought that axschema.org was the official one, but after cheking it, it turns out that you're right, there's no official one. Anyway, could you tell me (or provide a hint, or filename in source of DotNetOpenAuth) how to determine the namespace automatically? (while not sending every possible namespace at once)

Mewp 2010-06-30 15:10:19

By the way, "use SREG" is not an valid answer, so AXFetchAsSreg(as far as I understand how it works) is not a solution.

Mewp 2010-06-30 15:45:21

ansaurus

tags:

views:

answers:

ClaimedIdentifier Problem with myOpenID: http or https?

related questions