[OPENAM-12627] initiating TransactionConditionAdvice with a wrong credential resulting in a non-error response Created: 16/Mar/18 Updated: 17/Dec/20 Resolved: 04/Mar/19
|Fix Version/s:||6.5.1, 6.0.1, 5.5.2, 7.0.0|
|Reporter:||Sam Phua||Assignee:||Sachiko Wallace|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
This test case reuse the setup script provided in the 5.5.1 TOI but minus the push authentication part. It only uses DataStore in this case.
|Attachments:||How-To-Use-Scripts.pdf run-setup.sh setup-openam.sh setup-openam65.sh|
|Sprint:||AM Sustaining Sprint 57, AM Sustaining Sprint 58, AM Sustaining Sprint 59, AM Sustaining Sprint 60|
|Support Ticket IDs:|
|Needs QA verification:||
|Are the reproduction steps defined?:||
Yes and I used the same an in the description
User should receive error response when authentication has failed during TransactionConditionAdvice auth to avoid confusion
At this point, user will receive HTTP response code 200 with a clean response message not hinting anything about authentication failure :
Policy evaluation will return empty result with this transaction UUID when policy evaluation was continued after step up auth has failed, but it is confusing for the user why policy evaluation is not successful.
*NOTE:* This test case uses "DataStore" as auth module to simplify the scenario, but that shouldn't stop this bug from being evaluated as push auth will have the same issue described above.
|Comment by Ken Stubbings [ 16/Mar/18 ]|
In case this got missed yesterday:
Peter Major [9:49 AM]
|Comment by Andy Hall [ 16/Mar/18 ]|
Transactional Authorization was designed for Push Authz use-case.
|Comment by Simon Moffatt [ 18/Oct/18 ]|
Re-opening. The issue seems more likely related to how AM is handling failed authentication when a valid iPlanetDirectoryPro token is being presented during a call to ../json/authenticate endpoint via the transaction advice payload.
Tested transactional authorization on 6.5 and 6.0 with a non-push related chain and tree which work fine with both agents and REST client.
This Jira is specifically around how to handle a failing authentication response. Currently a success is being returned.
Note the transactionId in the CTS is NOT being updated and subsequent calls to the policy evaluation endpoint to check if the transaction has been completed still fail. This is good and as designed.
Likely work performed to close https://bugster.forgerock.org/jira/browse/OPENAM-9516 has resulted in this.
|Comment by Simon Moffatt [ 22/Oct/18 ]|
Bug Triage: as the secondary request to the policy eval endpoint would always fail, irregardless of the perceived success of the transaction advice request, the advice is to always make that secondary request.
|Comment by Simon Moffatt [ 20/Nov/18 ]|
Added back to triage for review based on update
|Comment by Ľubomír Mlích [ 29/Mar/19 ]|
to server configuration I can see 401 instead of token id in step 3 of push authentication in setup-openam65.sh in ForgeRock Access Management 6.5.1-RC2 Build 6e42f86d08 (2019-March-20 19:43)