[OPENAM-5317] 1st. character from realm value is deleted from endpoint /json/authenticate?realm=myRealm" Created: 15/Dec/14  Updated: 25/May/18  Resolved: 11/Jun/15

Status: Resolved
Project: OpenAM
Component/s: rest
Affects Version/s: 12.0.0, 13.0.0
Fix Version/s: 12.0.1, 13.0.0

Type: Bug Priority: Major
Reporter: Richard Hruza Assignee: Quentin CASTEL [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: AME, release-notes, verified
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

OpenAM 12.0.0-RC5 Build 11888 (2014-December-13 12:44)

Issue Links:
is duplicated by OPENAM-8051 Error message when user attempts to a... Resolved
Sprint: Sprint 75 - Team Tesla, Sprint 76 - Team Tesla
Support Ticket IDs:
QA Assignee: Richard Hruza


1st. character from realm value is deleted from endpoint /openam/json/authenticate?realm=myRealm"

1.) Create a subrealm
2.) Try to authenticate via subrealm used REST

curl --request POST --header "X-OpenAM-Username: bjensen" --header "X-OpenAM-Password: secret12" --header "Content-Type: application/json" --data "{}" "http://perf-openam.internal.forgerock.com:8080/openam/json/authenticate?realm=subrealm"

Observed Result:

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

Expected Result:


I tried add 2x first latter and I got expected result.

Comment by Pavel Balcárek [ 15/Dec/14 ]

Also reproduced this issue on /json/authenticate endpoint using python requests. Not seen this in AM12-RC4, so it looks like regression.

Comment by Pavel Balcárek [ 15/Dec/14 ]

Not seeing this on oauth2/authorize endpoint (both subrealm & /subrealm works as realm parameter)

Comment by Sam Drew [ 15/Dec/14 ]

XUI makes use of this syntax for the authentication endpoint when redirecting from /UI/Login, however it appears to add %2F to the request in the case that it does not begin with a slash.

Comment by James Phillpotts [ 15/Dec/14 ]

Looks like RestletRealmRouter.java L100 (12.0.0 branch) is the culprit here:

realm += realm.endsWith("/") ? subrealm.substring(1) : subrealm;

This should check if the subrealm starts with a slash before doing substring(1).

Comment by Sebastien Bertholet [X] (Inactive) [ 19/Dec/14 ]

Not sure it is the same bug, but using any char instead of '=' is unexpectedly working, ex:

curl --request POST --header "X-OpenAM-Username: user.0" --header "X-OpenAM-Password: password" --header "Content-Type: application/json" --data "{}" "http://lab01-fr.internal.forgerock.com:8080/openam/json/authenticate?realm2subrealm"
Comment by Richard Hruza [ 09/Jan/15 ]

For the case in comment above I raised new bug OPENAM-5405

Comment by Richard Hruza [ 09/Jan/15 ]

Verified and Closed

Tested with OpenAM 13.0.0-SNAPSHOT Build 12035 (2015-January-07 02:38)

Comment by Richard Hruza [ 09/Jan/15 ]

reopened, need to add label verified

Comment by Sebastien Bertholet [X] (Inactive) [ 09/Jan/15 ]

Ok. Thanks for opening the bug Richard.

Comment by Andrew Dunn [X] (Inactive) [ 11/Jun/15 ]

It's requested this be backported for 12.x.x.

Comment by Quentin CASTEL [X] (Inactive) [ 11/Jun/15 ]

Solved in 12.0.1 thanks to OPENAM-5508, r13245

Comment by edwardb [ 07/Jan/16 ]

For Version 13.0.0 I have checked that attempting to log on to a non-existent realm results in the correct error message (as was the problem stated in OPENAM-8051). This is the expected behaviour.


curl --request POST --header "Content-Type: application/json" --header "X-OpenAM-Username: tester" --header "X-OpenAM-Password: password" 'http://openam.example.com:18081/openam/json/authenticate?realm=wrongRealm&authIndexType=service&authIndexValue=2FA'


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

I also set up a valid realm and tried an authentication request using the realm. The response we got was valid and expected.


curl --request POST --header "Content-Type: application/json" --header "X-OpenAM-Username: tester" --header "X-OpenAM-Password: password" 'http://openam.example.com:18081/openam/json/authenticate?realm=/TestRealm&authIndexType=service&authIndexValue=2FA'


{"authId":"eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAiYXV0aEluZGV4VmFsdWUiOiAiMkZBIiwgIm90ayI6ICJsc2ZudDkwdnUwYWJ1cDNlN3NpaWtzNDRpMSIsICJhdXRoSW5kZXhUeXBlIjogInNlcnZpY2UiLCAicmVhbG0iOiAibz10ZXN0cmVhbG0sb3U9c2VydmljZXMsZGM9b3BlbmFtIiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3hFaGJhYlozZk92cV9TWTAtWDlMQXRWX01lanJXZkZuTS4qQUFKVFNRQUNNREVBQWxOTEFCUXRORFV3TkRFME1qY3hORGcxTXpjNE56VXdOd0FDVXpFQUFBLi4qIiB9.Xif9CR2Blb7Rs8qZfQtIfGFHjvT3imaHW_AL77p51wk","template":"","stage":"HOTP2","header":"Please enter your One Time Password, or request a new one","callbacks":[{"type":"PasswordCallback","output":[{"name":"prompt","value":"Enter OTP"}],"input":[{"name":"IDToken1","value":""}]},{"type":"ConfirmationCallback","output":[{"name":"prompt","value":""},{"name":"messageType","value":0},{"name":"options","value":["Submit OTP","Request OTP"]},{"name":"optionType","value":-1},{"name":"defaultOption","value":0}],"input":[{"name":"IDToken2","value":0}]}]}
Generated at Sat Oct 24 00:11:38 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.