What is the significance of the argument to WL.Client.createChallengeHandler?

564 Views Asked by At

I'm using Worklight 6.0 and Form based authentication.

I thought that the argument for WL.Client.createChallengeHandler() was the realm that the challenge handler would address, but testing seems to indicate that there is no way to create a realm specific challenge handler.

I have an adapter with 2 procedures. Each procedure has a separate security test. Each test corresponds to a different realm: r1 and r2.

In my app, I have 2 challenge handlers, one for r1, and one for r2. However, the challenge handler for r1 ends up handling the challenges for both adapter procedures. I find that I can use any string in WL.Client.createChallengeHandler() … non-existent realms, empty string, or even no argument, and it might change which of the 2 challenge handlers gets used, but whichever one gets used is used for all challenges.

What is the argument to WL.Client.createChallengeHandler() used for? Is there any way to tie a challenge handler to a realm?

1

There are 1 best solutions below

0
On BEST ANSWER

This argument has no meaning for most user authentication cases. Realm is detected not by its name but by a isCustomResponse() function inside of a challenge handler.

Basically WL auth framework knows how to handle two types of realms

  1. Internal WL security realms, e.g. noDeviceProvisioning, antiXSRF etc. They're coming from WL authentication framework and have predefined hardcoded realm names. In case of those realms the argument (realmName) is used internally by WL framework.

  2. All the rest, which includes custom user authentication realms, gateways, whatever you want. In this case developer cannot depend on a realmName since in some cases developer doesn't even have control over what the challenge will look like (e.g. auth gateways). Therefore you can supply any string as s realmName param (it will be ignored anyway) and use isCustomResponse() function to detect whether challenge belongs to a specific realm.

Good practice is to supply a proper realmName anyway to make your code future proof.