Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

This article describes how to use a single sign-on script in Smart ID Digital Access component. As web sites grow more and more resistant to automation, you might need to use a script, to make single sign-on (SSO) function as intended.

This implementation is not able to pick up and act on invalid SSO data. This means that if the password for a user in the target system has been changed, it will not be learned automatically by Digital Access, as with other SSO types, for example, Formbased and Adaptive.

The method works by intercepting the request from the login form submit and replacing dummy values with real SSO data, when the Access Point passes the request on to the internal resource. In order to make this work, a Java script is inserted in the web page using the WASCR technique.

 Prerequisites

-

Step-by-step instruction

 Log in to Digital Access Admin
  1. Log in to Digital Access Admin with an administrator account.
 Upload script files

  1. In Digital Access Admin, click Browse.
  2. Upload the provided files (without changing the file names) to access-point/custom-files/scripts.

 Add filters
  1. In Digital Access Admin, go to Manage Resource Access.
  2. Click Global Resource Settings.
  3. Go to the Filters tab and click Add Filter...
  4. Add these three filters and configure them as follows:
    • sso_set_username

      Configure sso_set_username

      Display Name: sso_set_username
      Script name: sso_set_username
      Type of Filter: Request
      Resource host: Difficult SSO Resource
      Path: login_form.aspx
      Apply Filter To: Content
      Content Type: *

    • sso_set_password

      Configure sso_set_password

      Display Name: sso_set_password
      Script name: sso_set_password
      Type of Filter: Request
      Resource host: Difficult SSO Resource
      Path: login_form.aspx
      Apply Filter To: Content
      Content Type: *

    • Inject_script

      Configure inject_script

      Display Name: inject_script
      Script name: inject_script
      Type of Filter: Response
      Resource host: Difficult SSO Resource
      Path: login_form.aspx
      Apply Filter To: Content
      Content Type: *

      Script variable: setTimeout(function() {document.getElementById("Password").value="secret_password";
      document.getElementById("Username").value = "secret_username";document.getElementById("LoginButton").click();}, 100);

      For help, click the ?-sign.

Information about the filters

This table gives information about the filters:

sso_set_usernameThis filter picks up a dummy-string, in this case: secret_username, and replaces it with the correct sso username in the request from the user to the internal server. This is a server side operation only so the username will never reach the end user or traverse to the client.
sso_set_passwordThis filter picks up a dummy-string, in this case: secret_password, and replaces it with the correct sso password in the request from the user to the internal server. This is a server side operation only so the password will never reach the end user or traverse to the client.
Inject_scriptThis filter injects a script in the login form web page that will prefill the values of the login form controls with the dummy strings secret_username and secret_password and auto-submit the form.
 Information when configuring the filters

Regarding the path

The path should be the target of the post, that is, what the form is configured to post its reply to. No web service is equal to another and sometimes this might not be a possible approach. The web page may post back to itself for example. So if a path can not be used, for whatever reason, use a * as path. This means that all requests will be inspected. In that case it is better to replace the dummy strings with something that will not under any circumstances be posted, to make sure not to replace other values. It could, for example, be that the web service actually has a reference to the string secret_username and in that case secret_username should be replaced with something random. For example, replace secret_username with hag_secret_username_lesuhfow8h2. The scripts must be edited accordingly. In the case of problems or questions contact Nexus Technical Support.

Regarding the script variable in Inject_script

The getElementById function calls are searching for the form fields Password, Username and LoginButton in the HTML of the login form. These are most likely named differently in other systems and must be updated accordingly by inspecting the HTML of the login form of the system that should be provided with SSO. These are typically the input fields where the user gives his/her credentials.

 Update Inject_script

Update the inject form script to introduce the script configured above (in the inject_script filter) in the correct position in the HTML.

  1. In Digital Access Admin, click Browse.
  2. Navigate to access-point/custom-files/scripts.
  3. Edit inject_script.wascr.

    [root]
    STRING="</body>";def
    ACTION=del("7"),ins("<script>"),ins(script), ins("</script></body>");0
    TRANS=root;root
  4. Find a place in the HTML to inject the script with correct syntax and without modifying functionality. This might not be trivial and sometimes changes to existing scripts may be needed. The above approach should however work in most conditions (find the end body tag and insert it just before the end).

The language above is called wascr and is somewhat complex. Basically the above script will do the following:

  • Search for the string </body> in the html file.
  • Delete 7 characters.
  • Insert "<script>"
  • Insert what is contained in the script variable (configured in the filter screen above)
  • Insert "</script>"
  • Insert "</body>"
 Enable script SSO
  1. In Digital Access Admin, go to Manage Resource Access.
  2. Click Web Resources.
  3. Mark the web resource and click Edit Resource Host...
  4. Check Enable Single Sign-On.
  5. Select Script as Single Sign-On Type.
  6. Select SSO Domain.
  7. Click Save and then Publish.
  • No labels