[OPENAM-5534] OAuth2/OIDC SSL connection is based on incoming request not on the site configuration Created: 11/Feb/15  Updated: 20/Nov/16  Resolved: 03/Mar/15

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

Type: Bug Priority: Major
Reporter: Phill Cunnington Assignee: James Phillpotts
Resolution: Fixed Votes: 0
Labels: AME, TESLA
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is required by OPENAM-5438 JWT claim iss is incorrect Resolved
Duplicate
is duplicated by OPENAM-3908 .well-known/openid-configuration shou... Resolved
Relates
is related to OPENAM-6219 Documentation of Base URL Provider Se... Resolved
Target Version/s:
Rank: 1|hzlruf:
Sprint: Sprint 79 - Team Tesla, Sprint 80 - Team Tesla
Support Ticket IDs:

 Description   

When the OAuth2/OIDC code determines whether to use a SSL connection or not is based on the http scheme of the incoming request. The problem with this is that the AM instance could be a part of a site where the external connection to the site is done over SSL but the request to the AM instance is over plain HTTP.

The site configuration should be taken into consideration when determining whether to use SSL or not.



 Comments   
Comment by Peter Major [X] (Inactive) [ 11/Feb/15 ]

Site configuration cannot correctly determine the actual URL to be used for OIDC: there is fqdnMap, DNS aliases and secondary site URLs that are all URLs allowed to be used to access OpenAM (fqdnMap and DNS alias doesn't contain the protocol scheme, only the primary and secondary site URL does).
I would suggest two solutions:

As a workaround:
Tomcat users can use proxyName, proxyPort, scheme, secure Connector settings:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

Comment by James Phillpotts [ 16/Feb/15 ]

Discussed this with Bernhard Thalmayr and decided on the following. A new provider service is created that allows the realm to have a configured option for how to obtain the base URL (including protocol) for places that need to return a URL to the client. The provider will have:

  • A radio button option for selecting URL source from:
    • Configured value
    • RFC7239 Forwarded header
    • X-Forwarded-Host + X-Forwarded-Proto headers
    • Host and protocol from the incoming AM request
    • An extension point that returns a base URL from a given HttpServletRequest.
  • A tick box to include/exclude the container's context path
  • A text field for specifying the configured fixed value (if required).
  • A text field for specifying the extension class (if required).

This service will initially just be used to fix the well-known endpoints (OIDC and UMA), but will be reusable from other places that also need to return URLs, such as SAML, CREST, etc. Separate bugs should be raised for those places.

Comment by James Phillpotts [ 03/Mar/15 ]

Now committed to trunk at r12807.

Comment by Peter Major [X] (Inactive) [ 20/May/15 ]

Backported to 12.0.1 with R13895 and to 12.0.2 with R13898

Generated at Mon Mar 01 22:20:02 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.