How To: Speed Up Logons to Webservice Realms

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: All

     

    Overview

    This article explains how to speed up logons to a Webservice realm that uses multiple data stores, by letting users log on against a specific lookup realm directly using their down-level (DOMAIN\Username) logon name.

    When a Webservice realm is configured with multiple data stores, each logon attempt searches the realms one after another, which adds a delay. The more realms in use, the more pronounced this delay becomes. Webservice logons can be shortcut so they search the relevant realm directly, instead of searching every realm in sequence.

     

    Configure Down-Level Logons

    1. On the Data tab of the Webservice realm, in the Multi-Datastore Membership Configuration section, click Add Realm from Another Server.
    2. Enter the realm name or URL, followed by a pipe character (|) and a realm identifier of your choice. For simplicity, this identifier can be the Active Directory (AD) domain name. For example, for a local realm: SecureAuth1|DOMAIN. For a remote realm: https://idp.domain.com/secureauth1|DOMAIN, as shown below.

    Multi-Datastore Membership Configuration section showing a realm added with a pipe-separated domain identifier.

    1. Users can now specify the realm or domain the Webservice should use by typing the realm identifier, followed by a backslash, then their username — for example, DOMAIN\username, as shown below.

    Logon screen showing a user entering their down-level DOMAIN\\username logon name.


     

    Special Considerations

    This configures the Webservice to search the correct realm directly, but only asserts the plain logon name.


     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.