Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-6565

.well-known/openid-configuration is published with both DNS Realm alias AND realm in the path, resulting in failed authentication

    Details

    • 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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                phillcunnington Phill Cunnington
                Reporter:
                david.bate David Bate
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 15h Original Estimate - 15h
                  15h
                  Remaining:
                  Time Spent - 9h Remaining Estimate - 15h
                  15h
                  Logged:
                  Time Spent - 9h Remaining Estimate - 15h
                  9h