[OPENAM-13991] 'issuer' value in .well-known/openid-configuration response is incorrect for a sub-realm Created: 16/Nov/18  Updated: 24/Aug/20  Resolved: 08/Jan/19

Status: Resolved
Project: OpenAM
Component/s: OpenID Connect
Affects Version/s:,,,, 6.5.0
Fix Version/s: 13.5.3, 14.1.2,,, 6.5.1, 6.0.1, 5.5.2, 7.0.0

Type: Bug Priority: Major
Reporter: Andy Itter Assignee: Lawrence Yarham
Resolution: Fixed Votes: 1
Labels: EDISON
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
caused OPENAM-16697 Case mismatch for realm (when using l... Resolved
is caused by OPENAM-12784 ProviderConfiguration is not spec com... Closed
Target Version/s:
Rank: 1|hzx5sf:
Sprint: AM Sustaining Sprint 58
Story Points: 3
Needs backport:
Support Ticket IDs:
QA Assignee: Ľubomír Mlích
Verified Version/s:
Needs QA verification:
Functional tests:
Are the reproduction steps defined?:
Yes and I used the same an in the description


Bug description

The 'issuer' value in the .well-known/openid-configuration output does not match the URL that requested it when a sub-realm is part of the request.

Note that this behaviour in onward is different to the initial 6.0 release and also different to earlier releases due to OPENAM-12784


How to reproduce the issue

1). Install AM and simply create a sub-realm, eg. named IDP and configure for OIDC using the wizard.

2). Request (specifying realm not using DNS alias) using the following format:


3). Inspect the results and note:



Expected behaviour (as seen in AM and earlier releases)


From the response:

Current behaviour


From the response:




Comment by Andrew Vinall [ 19/Nov/18 ]

Bug Triage: Andy Itter Would you be able to try using the Base URL Provider Service as a workaround?

Comment by Andy Itter [ 19/Nov/18 ]

Andrew Vinall I have done and that doesn't appear to work for this use case?

Comment by Ľubomír Mlích [ 10/Jan/19 ]

Verified by tests in

Comment by Ľubomír Mlích [ 18/Apr/19 ]

Verified by tests in

Generated at Sat Mar 06 01:24:38 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.