Using IIS Rewrite to auto-populate the Username Field in the Workforce platform

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Hybrid
  • Version Affected:  ALL

    Description:  

    Some SAML Service Providers make the user type their Username before it will redirect to the IdP and then the IdP makes the user type the Username again.

     

    Cause:  

    Service Providers may not use the keyword Username, so the IdP ignores the auto-filling of the Username on the login pages.

     

    Resolution:  

    1. Launch the IIS Manager on the IdP server

    2. Select the SecureAuth realm you want to add the rewrite rule to.

    3. In the right pane, and under IIS, double click on 'URL Rewrite'
    3. On the far right, click 'Add Rule(s)...'
    4. Click 'Blank rule' and then OK

    5. Give the rule a name.

     

    6. Match URL section should match as shown.

     

     

    7. In the Conditions section:

    a. Click 'Add...'

    b. 'Condition input:' set to {QUERY_STRING}

    c. Set 'Does Not Match the Pattern'

    d. Set 'Pattern:' to:
       (username=).*

    e. Add a second rule and set 'Matches the Pattern'

       (login_hint=)(\w*).*

     

    *** The username rule must be listed first in this rewrite rule.

    8. In the Action section:

    a. Set 'Action type:' to 'Redirect'

    b. Set 'Redirect URL:' to:

      {R:0}?{C:0}&username={C:2}

    c. Uncheck the 'Append query string'

    d. Set 'Redirect type:' to 'Temporary'

     

    Once completed, login to the Service Provider to see if the redirect and username populate properly. If the username is not in the URL sent to the IdP Server, this will not work. If the username is a different value than what was added, find said value and create another Condition to filter it and test again.

     

     

    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.