[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

Status: Resolved
Project: OpenAM
Component/s: None
Affects Version/s: 5.5.1
Fix Version/s: 6.5.1, 6.0.1, 5.5.2, 7.0.0

Type: Bug Priority: Major
Reporter: Sam Phua Assignee: Sachiko Wallace
Resolution: Fixed Votes: 0
Labels: EDISON
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

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: PDF File How-To-Use-Scripts.pdf     File run-setup.sh     File setup-openam.sh     File setup-openam65.sh    
Issue Links:
Relates
is related to OPENAM-14462 Document a new parameter that would r... Resolved
is related to OPENAM-12663 RFE for a non-push Authz use case usi... Open
Target Version/s:
Rank: 1|hzvkfj:
Sprint: AM Sustaining Sprint 57, AM Sustaining Sprint 58, AM Sustaining Sprint 59, AM Sustaining Sprint 60
Story Points: 5
Needs backport:
No
Support Ticket IDs:
Verified Version/s:
Needs QA verification:
Yes
Functional tests:
No
Are the reproduction steps defined?:
Yes and I used the same an in the description

 Description   

Bug description

User should receive error response when authentication has failed during TransactionConditionAdvice auth to avoid confusion

How to reproduce the issue

  1. setup an OpenAM 5.5.1
  2. login to admin console
  3. click [REALMS] -> [Top Level Realm] -> [Authentication] -> [Chains] -> [+ Add Chain]. Type in the following value and leave the rest as default :
        Name: pushService 
        Module: DataStore : REQUISITE
       
  4. click [REALMS] -> [Top Level Realm] -> [Authorization] -> [Policy Sets] -> "Default Policy Set" -> [+ Add a Policy]. Type in the following value:
        Id: PushServiceTransactionPolicy 
        Resource Types: URL
        Resources : http://example.com:80/*, http://agent.example.com:48080/*
        Actions: "POST": allow, "GET": allow
        Subjects: Authenticated Users
        Environment: Type=Transaction, Authentication Strategy=Authenticate to Chain, Strategy Specifier=pushService
       
  5. authenticate with amadmin & demo and get SSOToken
    curl --request POST --header "X-OpenAM-Username: <amadmin/demo>" --header "X-OpenAM-Password: <password>"  --header "Content-Type: application/json" --header "Accept-API-Version:protocol=1.0,resource=2.1" --data "{}"  "http://openam.example.com:18080/openam/json/realms/root/authenticate"
  6. request policy evaluation
    curl -X POST -k --header "iPlanetDirectoryPro: <amadmin token>" --header "Content-Type: application/json" --data '{"resources": ["http://example.com:80/index.html"], "application":"iPlanetAMWebAgentService", "subject": {"ssoToken": "<user token>"}} ' "http://openam.example.com:18080/openam/json/policies?_action=evaluate"
  7. previous step will return TransactionConditionAdvice with UUID as response. Use this UUID to request /authenticate endpoint with composite_advice auth module
    curl -X POST 'http://openam.example.com:18080/openam/json/authenticate?authIndexType=composite_advice&authIndexValue=%3CAdvices%3E%0A%3CAttributeValuePair%3E%0A%3CAttribute%20name%3D%22TransactionConditionAdvice%22%2F%3E%0A%3CValue%3E<transaction UUID>%3C%2FValue%3E%0A%3C%2FAttributeValuePair%3E%0A%3C%2FAdvices%3E' --header 'Content-Type: application/json' --header 'iPlanetDirectoryPro: <user token>' --data '{}'
        
  8. fill in the input values but provide wrong user password.
     curl -X POST 'http://openam.example.com:18080/openam/json/authenticate?authIndexType=composite_advice&authIndexValue=%3CAdvices%3E%0A%3CAttributeValuePair%3E%0A%3CAttribute%20name%3D%22TransactionConditionAdvice%22%2F%3E%0A%3CValue%3E<transaction UUID>%3C%2FValue%3E%0A%3C%2FAttributeValuePair%3E%0A%3C%2FAdvices%3E' --header 'Content-Type: application/json' --header 'iPlanetDirectoryPro: <user token>' --data '{"authId":"<authId>","template":"","stage":"Datastore1","header":"Sign in","callbacks":[{"type":"NameCallback","output":[{"name":"prompt","value":"User Name:"}],"input":[{"name":"IDToken1","value":"demo"}]},{"type":"PasswordCallback","output":[{"name":"prompt","value":"Password:"}],"input":[{"name":"IDToken2","value":"changeit123"}]}]}

At this point, user will receive HTTP response code 200 with a clean response message not hinting anything about authentication failure :

{
    "tokenId": "<old user token>",
    "successUrl": "http://example.com:80/index.html",
    "realm": "/"
}

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.

Expected behaviour
Failed authentication during composite_advice should provide a more meaningful message when the credential was wrong. 
Current behaviour
Authentication during composite_advice returns an identical message regardless of the correctness of the credential login. 

 



 Comments   
Comment by Ken Stubbings [ 16/Mar/18 ]

In case this got missed yesterday:

 

Peter Major [9:49 AM]
@sam.phua it was intentionally implemented like this. The main use-case for transactional authorization was to use the push authentication module. And when a user denies the request on their phone they will be just directed to the protected resource (where policy evaluation will fail)

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 ]

After adding

org.forgerock.openam.auth.transactionauth.returnErrorOnAuthFailure = true

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) 

Generated at Mon Mar 01 04:59:25 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.