Thanks for letting us know the solution. I didn't realize that the "operation: verify" was required for custom infomap rules. I'll have to look into this further.
Jon.
Original Message:
Sent: Mon January 11, 2021 06:11 AM
From: Mukesh Bhati
Subject: ISAM - Getting null value in InfoMap
Hi Jon,
Thanks for your response.
What I observe after 2FA, we need to pass an extra attribute i.e "operation": "verify". then it works fine.
for Example:
{
"password":"Passw0rd",
"newPassword":"Passw0rd1",
"passwordConfirm":"Passw0rd1",
"operation":"verify"
}
------------------------------
Mukesh
Original Message:
Sent: Fri January 08, 2021 06:30 AM
From: Jon Harry
Subject: ISAM - Getting null value in InfoMap
Hi Mukesh,
OK, I see the flow more clearly now that I can see all the images. To be honest, I cannot explain why you are not able to read the parameters you are posting. Seems like it should work based on what I can see.
What happens if you include the password change parameters in the request you send to OTP endpoint? Like this:
{
"otp.user.otp": 123456,
...
"password":"xxxxx",
....
}
I'm not suggesting this is the answer but interested to see if it works as it might narrow down the issue?
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Tue December 22, 2020 06:27 AM
From: Mukesh Bhati
Subject: ISAM - Getting null value in InfoMap
Hi Jon,
I'm not sending password, newPassword and confirmPassword in the first request. sending after 2FA.
Even flow is that, suppose the user wants to change the transaction password. First, he/she has to authenticate with 2FA once the user is authenticated then we need to ask the user for passwords.
------------------------------
Mukesh
Original Message:
Sent: Tue December 22, 2020 04:17 AM
From: Jon Harry
Subject: ISAM - Getting null value in InfoMap
Hi Mukesh,
The request context only contains the context related to the most recently received HTTP request from the user. So, after the user POSTs response to 2FA method, the original request at the start of the flow is lost.
You'll need to add code in an early infomap (maybe the validate session one if that is JavaScript?) to read the values you need and store in the response context so that they can be read again later in the authentication policy flow.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Tue December 22, 2020 02:10 AM
From: Mukesh Bhati
Subject: ISAM - Getting null value in InfoMap
Hello Team,
I have written infoMap to change one of the user attributes let's say Transaction password(custom attribute).
and then created a policy and access it as API. It's working fine
code for reference.
//imported required packages
var username = context.get(Scope.SESSION, "urn:ibm:security:asf:response:token:attributes", "username");
var password = utf8decode(context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "password"));
var newPassword = utf8decode(context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "newPassword"));
var confimPassword = utf8decode(context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "confimPassword"));
// logic to update user attribute with scim API's.


but when I added branching with 1 branch for MAC OTP and other Branches with TOTP in Policy. it's working fine till the branching step once it moves to the change transaction password step. infoMap receives a null value for all the request attributes.
code for reference.
//imported required packages
var username = context.get(Scope.SESSION, "urn:ibm:security:asf:response:token:attributes", "username");
var password = utf8decode(context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "password"));
var newPassword = utf8decode(context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "newPassword"));
var confimPassword = utf8decode(context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "confimPassword"));
// getting all attribute from request as null
// logic to update user attribute with scim API's.


// dynamic_url is taken from the previous api call(action attribute).



Can anyone help with the same?
------------------------------
Mukesh
------------------------------