search

wwtaourl / openid4java

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

OpenID over SSL fails #113

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I have two unit tests using an embedded Jetty to test an OpenID
authentication. The first one is non-SSL, the second one is SSL. I cannot
seem to get the SSL right. I always receive the following error:
INFO  [YadisResolver] Yadis discovered 2 endpoints from:
https://localhost:53455/identity/idp/123456789
DEBUG [UrlIdentifier] Normalized: https://localhost/identity/idp/123456789
to: https://localhost/identity/idp/123456789
INFO  [Discovery] Discovered 2 OpenID endpoints.
DEBUG [ConsumerManager] Looking for a service element to match the
ClaimedID and OP endpoint in the assertion...
ERROR [ConsumerManager] No service element found to match the ClaimedID /
OP-endpoint in the assertion.
ERROR [ConsumerManager] Discovered information verification failed.

Seems like the normalization loses the port number when using SSL.

In attachment you'll find the two unit tests.

Original issue reported on code.google.com by frank.co...@gmail.com on 23 Mar 2010 at 3:42

Attachments:

GoogleCodeExporter commented 8 years ago 
The specification clearly states:
http://openid.net/specs/openid-authentication-2_0.html#verify_disco

If an assertion has either value for "openid.op_endpoint", then that field 
matches
this <xrd:Service>  element.

Which is indeed the case of my unit test.

Original comment by frank.co...@gmail.com on 23 Mar 2010 at 5:22

GoogleCodeExporter commented 8 years ago 
Normalization looks ok, the library is requested to normalize https://localhost/
identity/idp/123456789.

DEBUG [UrlIdentifier] Normalized: https://localhost/identity/idp/123456789
to: https://localhost/identity/idp/123456789

What is the result of discovery on 
https://localhost:53455/identity/idp/123456789 ?

Original comment by Johnny.B...@gmail.com on 24 Mar 2010 at 1:09

GoogleCodeExporter commented 8 years ago 
Thanks for handling my reported issue.

The (second/verification) discovery happens as expected. First the HTML is 
downloaded
(identity is provided via the embedded OpenIDIdentityServlet) containing:
<meta http-equiv="X-XRDS-Location" 
content="https://localhost:53455/identity/xrds"/>

Next the YADIS document is downloaded containing:
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service>
<Type>http://specs.openid.net/auth/2.0/server</Type>
<URI>https://localhost:53455/producer</URI>
</Service>
<Service>
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<URI>https://localhost:53455/producer</URI>
</Service>
</XRD>
</xrds:XRDS>

Which works just fine for the non-SSL unit test (second Service entry matches 
and
makes the RP to trust the OP), but when converting the entire thing over to SSL 
(see
the second unit test) I get the following error message:
INFO  [YadisResolver] Yadis discovered 2 endpoints from:
https://localhost:53455/identity/idp/123456789
DEBUG [UrlIdentifier] Normalized: https://localhost/identity/idp/123456789 to:
https://localhost/identity/idp/123456789
INFO  [Discovery] Discovered 2 OpenID endpoints.
DEBUG [ConsumerManager] Looking for a service element to match the ClaimedID 
and OP
endpoint in the assertion...
ERROR [ConsumerManager] No service element found to match the ClaimedID / 
OP-endpoint
in the assertion.
ERROR [ConsumerManager] Discovered information verification failed.

Why does the port number disappears when normalizing?

Original comment by frank.co...@gmail.com on 24 Mar 2010 at 6:48

GoogleCodeExporter commented 8 years ago 
Comparing the non-SSL YADIS result with the SSL YADIS result yields a 
difference. For
non-SSL I get (of course the port number changes on each run of the unit test):
DEBUG [XrdsParserImpl] Found 2 services for the requested types.
DEBUG [XrdsParserImpl] Discovered endpoint: 
Service priority: 0
Type: [http://specs.openid.net/auth/2.0/server]
URI: http://127.0.0.1:33082/producer
URI Priority: -1
LocalID: null
DEBUG [XrdsParserImpl] Discovered endpoint: 
Service priority: 0
Type: [http://specs.openid.net/auth/2.0/signon]
URI: http://127.0.0.1:33082/producer
URI Priority: -1
LocalID: null

For SSL I get:
DEBUG [XrdsParserImpl] Found 2 services for the requested types.
DEBUG [XrdsParserImpl] Discovered endpoint: 
Service priority: 0
Type: [http://specs.openid.net/auth/2.0/server]
URI: https://localhost:58729/producer
URI Priority: -1
LocalID: null
DEBUG [XrdsParserImpl] Discovered endpoint: 
Service priority: 0
Type: [http://specs.openid.net/auth/2.0/signon]
URI: https://localhost:58729/producer
URI Priority: -1
LocalID: null

For non-SSL you see the resulting URIs using IP-number, for SSL it is using the
localhost host name. mmm... Maybe this makes sense in the context of SSL.

I think the ConsumerManager should accept the https://localhost:58729/producer 
as
matching with the OP endpoint from the authentication result:
openid.op_endpoint:https://localhost:58729/producer

since for the non-SSL the matching with:
op_endpoint:http://127.0.0.1:48745/producer

is successful.

Original comment by frank.co...@gmail.com on 24 Mar 2010 at 6:59

GoogleCodeExporter commented 8 years ago 
The port number seems to disappear *before* normalization. Does https://
localhost:53455/identity/idp/123456789 redirect to https://localhost/identity/
idp/123456789 by any chance?

If you run a unit test similar to the ones in YadisResolverTest, with just
   List result = _resolver.discover("https://localhost:53455/identity/idp/123456789")
what result do you get?

Original comment by Johnny.B...@gmail.com on 24 Mar 2010 at 8:55

GoogleCodeExporter commented 8 years ago 
The discovery clearly uses the explicit port URL.
INFO  [Discovery] Starting discovery on URL identifier:
https://localhost:57900/identity/idp/123456789
...
DEBUG [YadisResolver] Performing HTTP GET on:
https://localhost:57900/identity/idp/123456789 ...
...
DEBUG [YadisResolver] xrdsLocation: https://localhost:57900/identity/xrds
DEBUG [YadisResult] Setting X-XRDS-Location for yadis result:
https://localhost:57900/identity/xrds

But then all of the sudden the following pops up:
DEBUG [YadisResult] Setting X-XRDS-Location for yadis result:
https://localhost/identity/xrds

Original comment by frank.co...@gmail.com on 25 Mar 2010 at 1:15

GoogleCodeExporter commented 8 years ago 
I've tried the 0.9.6-SNAPSHOT version, and this one works as expected. So it 
seems
like there has been some bug fixed between 0.9.5 and 0.9.6-SNAPSHOT. When will 
0.9.6
be released?

Original comment by frank.co...@gmail.com on 25 Mar 2010 at 1:47

GoogleCodeExporter commented 8 years ago 
I've been digging some deeper into this issue. Seems like there is some missing 
normalization.

After authentication the following happens before the YADIS discovery continues:
DEBUG [Discovery] Creating URL identifier for: https://localhost:443/eid-
idp/endpoints/openid-identity?71715100070
DEBUG [UrlIdentifier] Normalized: 
https://localhost:443/eid-idp/endpoints/openid-
identity?71715100070 to: https://localhost/eid-idp/endpoints/openid-identity?
71715100070

Because of the following code in UrlIdentifier.normalize:
if (port == url.getDefaultPort())
    port = -1;

While in ConsumerManager.verifyDiscovered2 the assertId is not normalized 
before 
looking for a match. Thus I'm having the following data in ConsumerManager:
DEBUG [ConsumerManager] assert id: 
https://localhost:443/eid-idp/endpoints/openid-
identity?71715100070
DEBUG [ConsumerManager] resp endpoint: 
https://localhost:443/eid-idp/protocol/openid
DEBUG [ConsumerManager] OP specific: https://localhost/eid-idp/endpoints/openid-
identity?71715100070
DEBUG [ConsumerManager] OP endpoint: 
https://localhost:443/eid-idp/protocol/openid

So the OP specific has been normalized (because of the lookup) while the 
assertId has 
not.

Original comment by frank.co...@gmail.com on 6 Apr 2010 at 11:05

GoogleCodeExporter commented 8 years ago 
The OpenID 2.0 specification doesn't mention anything about normalization of 
the 
protocol port. See also: http://openid.net/specs/openid-authentication-
2_0.html#normalization

Original comment by frank.co...@gmail.com on 6 Apr 2010 at 11:26

GoogleCodeExporter commented 8 years ago 
In attachment a possible solution for this problem. I also normalize the 
asserted Id 
within ConsumerManager:verifyDiscovered2 before searching for a match.

Original comment by frank.co...@gmail.com on 6 Apr 2010 at 3:13

Attachments:

GoogleCodeExporter commented 8 years ago 
Per OpenID Authentication 2.0 Section 7.2 Normalization, paragraph 4:

"URL Identifiers MUST then be further normalized by both following redirects 
when 
retrieving their content and finally applying the rules in Section 6 of 
[RFC3986] to 
the final destination URL."

RFC3986 Section 6.2.3:

"    http://example.com
     http://example.com/
     http://example.com:/
     http://example.com:80/
[...] the second URI above is the normal form for the 'http' scheme."

Original comment by Johnny.B...@gmail.com on 6 Apr 2010 at 7:11

GoogleCodeExporter commented 8 years ago 
Normalization is a required step during discovery, and its result is the 
claimed 
identifier (which is always in the normal form).

The positive assertion from the OP must contain the claimed identifier (per 
section 
10.1 Positive Assertions), which must be already in the normal form (per 
section 2 
Terminology, Claimed Identifier). Per Section 11.2 Verifying Discovered 
Information, 
the claimed identifier obtained through discovery must match the 
openid.claimed_id 
value from the positive assertion, without any processing applied to the 
latter. (It 
is the OP's responsibility to send a valid, normalized, claimed_id.)

Original comment by Johnny.B...@gmail.com on 6 Apr 2010 at 7:19

GoogleCodeExporter commented 8 years ago 
Thanks for your answer! Because I use OP selected identifiers (which I 
apparently
forgot to normalize) maybe we could add a check for this as part of the
ConsumerManager to detect non-normalized OP selected identifiers? This check 
could
help others when trying to find out what is going wrong during the verification 
process.

Original comment by frank.co...@gmail.com on 7 Apr 2010 at 6:38

GoogleCodeExporter commented 8 years ago

Original comment by Johnny.B...@gmail.com on 31 Oct 2012 at 7:39