Transferring UserId from one module to other in an authentication chain

This topic has 7 replies, 2 voices, and was last updated 1 week ago by Jatinder Singh.

  • Author
    Posts
  • #28114
     Kabi Patt
    Participant

    Hello,
    Here is the definition of my Authentication Chain :-

    (1) LDAP Module (takes uid/pwd) marked as “requisite” .
    (2) Radius Module (takes uid/ Otp) marked as “required” .

    User enters the uid/pwd for the 1st module followed by uid/otp in second module for this authn-chain to be successful. I am using OOB login pages. How can I pre-populate the uid in 2nd module from the 1st module, so user does not have to re-enter it?

    Thanks,
    Kabi

    #28118
     Jatinder Singh
    Participant

    Hi Kabi, I would suggest to look into utilizing sharedState for this scenario. Shared state is AM’s way of sharing information between authentication modules/or nodes.

    #28128
     Kabi Patt
    Participant

    Thanks Jatinder,

    The shared state did not work. I set the followings :-
    (1) LDAP Module (takes uid/pwd) has option “iplanet-am-auth-store-shared-state-enabled=true” .
    (2) Radius Module (takes uid/ Otp) has option “iplanet-am-auth-shared-state-enabled=true” .

    I did not see the value of “username” transferred from 1st module to 2nd one. Note that only the “userName” is common between this two modules. User still required to enter the password and OTP in respective module. All I wanted is, the value of userName to appear on the UI of 2nd module for convenience.

    Kabi

    #28137
     Jatinder Singh
    Participant

    So, it doesn’t actually work that way. If it’s configured correctly, the RADIUS module will use information stored in shared state to perform authentication instead pre-populating and rendering the UI. Also, I would suggest to enable iplanet-am-auth-shared-state-behavior-pattern=useFirstPass on the RADIUS module. And enable Debug and share logs if still experiencing issues.

    #28142
     Kabi Patt
    Participant

    Jatinder,
    My use case is different. I simply wanted to pre-fill the userName in module 2 from module 1. User still require to fill the OTP in module2. Module1 collect user’s password that is validated against LDAP, while Module2 collect OTP validated against a Radius server.

    Using “UserFirstPass” will try to authenticate the user in Radius module (Module2) with the credential from module1 meant for LDAP. The authentication will fail.

    Thanks,
    Kabi

    #28159
     Kabi Patt
    Participant

    Will try out the authn state mentioned here. That may capture the userName from shared object.
    https://backstage.forgerock.com/docs/am/6.5/dev-guide/index.html#scripting-api-authn-state

    #28163
     Jatinder Singh
    Participant

    I suggest downloading the am-external source-code to see how these modules work. I have yet to work with the RADIUS module but from what it seems like you will have to modify the module to implement your requirements. The stock behaviour of the module is to either ask user for username/password if not present in shared state or use shared state data directly. It will not pre-populate those fields as you want.

    And I am not aware of your requirements but it seems like you want to collect username/password and OTP values at the same time. Shouldn’t you validate username/password first and then ask for OTP as a second-factor?

    #28165
     Jatinder Singh
    Participant

    And I just looked at the RADIUS module source-code again and if my understanding around your requirements is correct – this is how it should work if there’s an OTP challenge involved:

    P.S this is from the Auth Chain perspective.

    1. Username/Password information is passed via shared state to RAIDUS module;
    2. RADIUS module picks the username/password from shared state and authenticates user by invoking radiusConn.authenticate(username, tmpPasswd)
    3. RADIUS module successfully validates the username/password and returns a challenge response, and state of the module is set to LOGIN_CHALLENGE;
    4. User enters the OTP in the password input box and hits submit;
    5. RADIUS module intercepts the LOGIN_CHALLENGE reply from user and invokes radiusConn.replyChallenge method;
    6. For a happy case scenario, RADIUS module returns LOGIN_SUCCEED reply.

    Hope this clarifies any confusion!

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

©2020 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?