[OPENAM-6565] .well-known/openid-configuration is published with both DNS Realm alias AND realm in the path, resulting in failed authentication Created: 12/Aug/15  Updated: 27/Mar/18  Resolved: 17/Dec/15

Status: Resolved
Project: OpenAM
Component/s: oauth2, OpenID Connect
Affects Version/s: 12.0.1, 13.0.0
Fix Version/s: 13.0.0

Type: Bug Priority: Major
Reporter: David Bate Assignee: Phill Cunnington
Resolution: Fixed Votes: 0
Labels: 13.0.0-Must-Fix, AME, TESLA
Remaining Estimate: 15h
Time Spent: 9h
Original Estimate: 15h

Attachments: Text File well-known_openid-configuration.txt    
Issue Links:
Relates
relates to OPENAM-7035 OAuth2ProviderSettings are not update... Resolved
relates to OPENAM-7969 jwks_uri cannot be null Resolved
relates to OPENAM-8004 refresh_token load: bottleneck at Ope... Closed
Target Version/s:
Sprint: Sustaining Sprint 11, Sustaining Sprint 12, Sprint 98 - Team Tesla
Support Ticket IDs:

 Description   

jjWhen an OAuth2 Provider is configured on a realm with a DNS Realm alias configured, the .well-known/openid-configuration that is published for that realm when seen using said DNS for that realm, shows BOTH the realm dns and the realm in the path, which results in authentication failure.

I've attached the .well-known/openid-configuration that has both the DNS alias and realm path being used.

Steps to reproduce:

1)
Install 12.0.1.
I installed it as http://host1.example.com

2)
Create a Realm: /customers

3)
add customers.example.com to the Realm/s DNS Alias

4)
add customers.example.com to your /etc/hosts file to the same ip address as host1.example.com

5)
Use Common Tasks Wizard to create an Oauth2 Provider. Create it in the /customers realm

6)
In the /customers realm, create an OAuth2 Agent (Open AM --> Access Control --> Customers – >Agents --> OAuth2

7.
use myClientID for name
and
"password" for the password

8. Stop OpenAM then Start OpenAM. I don't know why this is needed but before the restart

9. Go to this URL:
http://customers.example.com:8383/openam/oauth2/.well-known/openid-configuration

see that ALL references use DNS name customers.example.com AND realm path: .../openam/oauth2/customers/...

9. Now issue this command that is using the publicized access_token:
"token_endpoint": "http://customers.example.com:8383/openam/oauth2/customers/access_token",

curl --user "myClientID:password" --data "grant_type=password&username=demo&password=changeit&scope=cn%20mail" --request POST http://customers.example.com:8383/openam/oauth2/customers/access_token

{"code":400,"reason":"Bad Request","message":"Invalid realm, customers/customers"}

tr808:~ db$

It gives us an invalid realm. and shows it trying to go to "customers/customers" rather just "customers" realm

Now either

a) use realm dns alias but with no realm in the path and it succeeds:

curl --user "myClientID:password" --data "grant_type=password&username=demo&password=changeit&scope=cn%20mail" --request POST http://customers.example.com:8383/openam/oauth2/access_token

{"scope":"mail cn","expires_in":5999,"token_type":"Bearer","access_token":"ff7af078-3159-4087-989c-bac1d55b2823"}

or

b)
use the top level dns and include the realm in the path and it succeeds as well:

curl --user "myClientID:password" --data "grant_type=password&username=demo&password=changeit&scope=cn%20mail" --request POST http://host1.example.com:8383/openam/oauth2/customers/access_token

{"scope":"mail cn","expires_in":6000,"token_type":"Bearer","access_token":"c3f94e14-2fa5-40bc-b4d5-464b1587be2a"}

WHY is the .well-known/openid-configuration that is being published WHEN using a DNS Alias for the realm, showing both the DNS alias for the realm AND the realm in the path.

-->

but before restarting, when going to the below URL:
http://customers.example.com:8383/openam/oauth2/.well-known/openid-configuration

it would reference host1.example.com rather then customers.example.com
for example: "token_endpoint": "http://host1.example.com:8383/openam/oauth2/customers/access_token",

after a restart of openam they now show customers.example.com, but they ALSO use the DNS realm and realm in the URL:

for example:
"authorization_endpoint": "http://customers.example.com:8383/openam/oauth2/customers/authorize"

}

has both http://customers.example.com... AN openam/oauth2/customers/...

This is an incorrect URL. The correct URL that DOES work:
"http://customers.example.com:8383/openam/oauth2/authorize"

So it is important to do step 8 in order to SEE the incorrect published URL's.



 Comments   
Comment by Peter Major [X] (Inactive) [ 14/Aug/15 ]

I'm not really sure what the preferred solution should be, during my investigations I could identify 2 main issue:

  • the OpenAMOAuth2ProviderSettingsFactory seems to cache the first OpenAMOAuth2ProviderSettings it generates based on the first incoming OAuth2 request. If you have more than one DNS alias configured for the realm, then the well-known endpoint will always use the first alias that you used first to access the well-known endpoint, which does not seem to be correct. (I'm not really sure though that it should be possible to access the same realm's well-known configuration endpoint with different URLs and potentially get back different URLs/issuer values...)
  • the way OpenAMOAuth2ProviderSettings constructs the OAuth2BaseURL appears to be wrong, it assumes that the host name always corresponds to the top level realm... Since the query parameter should always overrule the other realm identifiers in the incoming request, maybe we should just modify the code, so that all the endpoints AND the issuer has the realm value specified as query parameter.

Alternatives would involve to try to be smarter and check what is the realm alias and whether the hostname maps to it and construct the URLs that way, but that could be more complex when we start to think about sub-subrealms (subrealm has an alias, but the sub-subrealm doesn't)...

Comment by Phill Cunnington [ 17/Dec/15 ]

The OpenID configuration endpoint now takes into consideration where the realm is derived from, server name (DNS alias), URI realm sub path and query realm parameter.

Generated at Thu Dec 03 19:51:30 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.