IBM Verify

 View Only

  • 1.  Handling Authentication Policy Workflows - Verify Access

    Posted 26 days ago

    Hi all,

    I'm having some difficulty working with Authentication Policy workflows. I currently have two simple testing workflow steps configured in a policy, which are both InfoMap Authentication mechanisms. The first authentication mechanism kicks off as expected when I specify the policy URL in the browser (/mga/sps/authsvc/policy/test_policy).

    The InfoMap for this first authentication mechanism sets "success.setValue(false);" initially so that I can display a user input page which is specified in the InfoMap Authentication mechanism's form. Once the user specifies the correct input (with a simple static value check of an incoming parameter by the infomap), I want the policy to advance to the second auth mechanism in the workflow and do the same scenario and if the value check there is correct, complete the policy.

    However, I am having difficulty sending the user's input to the correct step in the workflow, so that the correct InfoMap auth mechanism executes in the flow. I have tried using the StateId query parameter and posting a header, a query parameter, a JSON body to it containing the user value, but Verify Access seems to ignore any and all values sent through as soon as I specify the StateId. If I remove the StateId when calling the policy again, all parameters can be sent through, whether in the header, body or a query parameter.

    My understanding is that the StateId sent back to the browser indicates the current step in the workflow, and that that could be used to return to that step and progress further through the workflow. I want to use /mga/sps/authsvc/policy/test_policy?StateId=xyz... to target the next step in the flow, and at the same time send parameters to that workflow step, but it doesn't seem to work.

    Do I have it all wrong or is there something small I'm missing?



    ------------------------------
    Martin van der Wel
    ------------------------------


  • 2.  RE: Handling Authentication Policy Workflows - Verify Access

    Posted 25 days ago

    A mechanism has to succeed in a policy for the next mechanism in that policy to be processed. Your policy should return success.setValue(true) when the username is validated. It's ok to return false on the first run through (when there has been no username supplied to the mechanism).

    If you are sharing data between the mechanisms in the policy, the best way is to set a server-side context variable. In the first mechanism, set it with something like:

    let username = "fred";
    context.set(Scope.SESSION, "urn:myns", ""myusername", username);


    In the second mechanism read it:

    let javaStringValue = context.get(Scope.SESSSION, "urn:myns", "myusername");

    Do note that the result of context.get is a Java String (not a Javascript String).



    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 3.  RE: Handling Authentication Policy Workflows - Verify Access

    Posted 25 days ago

    Hey Martin, 

    I might also encourage you to take a look at few examples:

    https://philipnye.com/2017/06/14/isam-infomap-any-alias-authentication/

    And the out of the box examples for User Self Care. 


    These all use a combination of infomaps and regular Mechanisms to pass context around. 
    Look for their corresponding Mapping Rules & template pages for more context. 

    The template page for Username and Password is also useful here to talk about. 

    C/authsvc/authenticator/password/login.html

    The ACTION Macro should contain the StateID already - so you don't need to manage it specifically. 


    <form method="POST" action="@ACTION@">
    <h2 class="sectionTitle">Login</h2>
    <input type="hidden" name="operation" value="verify">

    And another gotcha - is that the hidden Operation = Verify parameter is quite important when using alot of these mechanisms. 
    Many internal processes expect this to progress/validate the response. Generally speaking - ensure you add this in all POST submissions. 



    ------------------------------
    Philip Nye
    IBM
    Gold Coast
    ------------------------------

    Original Message