Add an Application Using HTTP Federation Proxy

Document created by RSA Information Design and Development on Jul 14, 2016Last modified by RSA Information Design and Development on Oct 20, 2017
Version 20Show Document
  • View in full screen mode
 

The HTTP Federation (HFED) Proxy method enables you to configure a connection to a web application that does not support Security Assertion Markup Language (SAML) and that uses a sign-in form to authenticate users. After you complete this procedure, the application is added to My Applications and is available for single sign-on (SSO) after the next publish operation.

Before you begin 

  • Collect all of the information that you need for the HFED-configured connection. You must complete all of the required fields before saving the configuration settings. If necessary, you can modify the settings later. For a list of required information, as well as information about decisions you can make ahead of time, see HTTP Federation Proxy Planning Worksheet.
  • Confirm that the identity router is configured and is connected to at least one identity source.

Procedure 

  1. In the Cloud Administration Console, click Applications > Application Catalog.
    The Application Catalog appears.
  2. Click Create From Template.
  3. Next to HTTP Federation Proxy, click Select.
    The Add Connection wizard appears.
  4. On the Basic Information page, complete these fields.
    1. In the Name field, enter a name for the application.
    2. (Optional) In the Description field, enter a description for the application.
    3. (Optional) To make the application unavailable to users, select the Disabled checkbox. When disabled, the application appears in My Applications, but does not appear in the application portal.

      For information about how this setting interacts with the Display in Portal setting on the Portal Display page of the wizard, see Application Availability and Visibility.

    4. Click Next Step.
  5. On the Connection Method page, select a method to use when configuring the application sign-in page. Do one of the following:
    • Click Discover to configure the sign-in page through the automatic discovery process. Proceed to step 6.
    • Click Use Recording to configure the sign-in page through playback of a pre-recorded configuration session.
    • Click Manual to configure the sign-in page manually. Skip to step 7.
  6. If you selected Discover, perform the following steps:
    1. In the Application Logon URL field, enter the URL for the web page that contains the application sign-in form, for example: https://www.appname.com/login.aspx.
    2. Click Next Step.

      RSA SecurID Access scans the application's sign-in page for the fields used to enter sign-in credentials (typically a username and password). The information is retrieved from the page and used to configure fields for the sign-in page so that users can sign into the application by entering the expected credentials.

      When discovery succeeds, the Connection Profile page of the wizard appears, with a confirmation message. If you need to modify sign-in page settings, perform step 7. Otherwise, click Next Step to proceed to the Proxy Settings page described in step 8.

      Note:   If a discovery error occurs, first check if the Application Logon URL is correct. If the URL is correct, check for SSL errors from the application web server by either searching the identity router logs, or by accessing the application web server using a browser. If there are SSL errors, ensure that the web server's SSL certificate is valid and has been signed by a certificate authority (CA) that the identity routers trust. For more information on trusted CAs,see Trusted Certificate Authorities for HFED or Trusted Headers Applications. If there are no SSL errors, it is possible that the website is not discoverable. In that case, select Manual, click Next Step, and perform step 7.

  7. If you selected Manual, perform the following steps:
    1. In the Logon Form URL field, enter the URL for the web page that contains the application sign-in form. For example: https://www.appname.com/login.aspx.
    2. In the Logon Form Action field, enter the action the sign-in page takes when a user submits credentials. For example: https://www.appname.com/Auth.
    3. In the Logon Form Identifier field, enter the HTML name of the sign-in form, for example, auth.
    4. From the HTTP Request Type drop-down list, select POST or GET to specify the HTML request that the sign-in form uses to send account credentials to the application. Most HFED applications use POST.

      Note:  If the discovery returns a GET, the Application Logon URL might be incorrect, or the application might not support POST (rare in modern web applications). If necessary, consult with a web application developer to determine which method the application requires.

    5. Define Logon Form Fields and Input Value Types for the sign-in form.

      For each form field, specify settings for the following components.

                               
      Component Description
      Identifier HTML name of the sign-in form, for example, auth.
      Name HTML name attribute for the field. Not visible to users, but in the source code provides a user-friendly description of the field for developers. The Identifier and Name fields are often the same.
      Purpose Function for which the field is intended. Select one:
      • Username
      • Password
      • Credential – Additional sign-in credential, such as birth date, account number, or employee ID.
      • Constant Value – Predefined value that does not change (rarely used).
      • Submit Button – Submit button for sign-in credentials.
      • Use Form Value – Set the value of this field as it was discovered in the form.
      • None – Nonfunctioning field that the application ignores. For example, if the discovery process returns a "password" field and a "reset password" button, you might set Purpose to None for the "reset password" button.

      Note:  Username, Password, and (optional) Credential inputs are stored in the user-specific keychains.

      Value User-visible name of the field. Label is only available for Username, Password, Credential, and Constant Value.

      To define additional form fields, click ADD.

    6. Configure Failure Detection settings to enable the identity router to detect when an attempt to sign into an application has failed.

      Describe the failure condition using the following parameters.

                             
      Field Options
      Indicator Select the type of indicator the application returns when sign-in fails.
      • VISIBLE_TEXT
      • URL
      • HTTP_STATUS
      Criteria Select the operation for determining the failure.
      • Starts with
      • Ends with
      • Contains
      • Does not contain
      • Is empty
      • Is not empty
      • Matches
      • Does not match
      Value Enter the specific error condition, enclosed in square brackets. Insert the pipe symbol (vertical line) within the brackets as needed to define multiple error conditions. For example: [value1|value2]

      The following table provides examples of Failure Detection settings.

                                  
      Indicator Criteria Value
      VISIBLE_TEXT Starts with [Invalid credentials]
      URL Contains [Failed]
      HTTP_STATUS Matches [401 Unauthorized]

      When the identity router detects a sign-in failure based on these settings, a unsuccessful sign-in dialog box appears. In this case, and if users can set their own credentials for the application, the user can enter credentials in the fields presented, and then click Save. If users cannot set their own credentials, an error message appears.

    7. Click Next Step.
  8. Specify web server proxy settings for each application server hostname.
    1. For each web server, click ADD, and in the Web Server dialog box, provide the following information.
                                  
      Field Setting
      Proxy Hostname The hostname of the proxy web server, without the internet protocol, and ending with your company domain name. The proxy hostname must be a valid alias in the Domain Name System (DNS) database that points to the hostname of the application portal in the identity router, and it must be unique across all applications.
      Examples:
      • www-appname-com.sso.example.com
      • resources-appname-com.sso.example.com
      Real Hostname The true hostname of the application, without the internet protocol.
      Examples:
      • www.appname.com
      • resources.appname.com
      Protocol The internet protocol for the web server: HTTP, HTTPS, or Both (HTTP/HTTPS)

      If you add a web server that requires HTTP, select Enable HTTPS communication between user and identity router to improve security. This functionality is also known as SSL Termination. With this option selected, all HTTP traffic for this web server is redirected to HTTPS on the identity router. The identity router still uses HTTP to communicate with the web server.

      Port Number The port number the web server uses for communication. The default HTTP port is 80, and the default HTTPS port is 443.

      The port number is required for either HTTP or HTTPS, but is not required for Both (HTTP/HTTPS).

      Rewrite Rules (Advanced)

      (Optional) Click to define Apache HTTP Server rewrite rules.

      Note:   Do not configure rewrite rules unless instructed to do so by RSA Customer Support.

    2. Click Save.
    3. Click Show CNAME Summary to display the canonical name (CNAME) records (or alias records) that must be in the DNS database. Each CNAME record must point to the address (A) record for the hostname of the application portal in the identity router. Click one of the following:
      • Hostname – Shows the hostname to which the CNAME record points.
      • BIND – Shows the Berkeley Internet Name Domain (BIND) format.

      Provide the CNAME list to the DNS administrator.

    4. (Optional) Define Custom Headers to pass customized information in headers to the application. Consult with an application web developer or application support to learn what headers the application expects. Select the appropriate options:
      • Pass Attributes – Passes attribute values from an identity source as a header to the application.
      • Pass Headers – Passes user session information as a header to the application.
      • Verify Certificates – Identity router validates the SSL certificates on the application if Secure Sockets Layer (SSL) is enabled through an SSL/HTTPS port.
      Define custom headers using the following fields.
      Field Setting
      Source Select the source where the HTTP header originates.
      • Attribute sends a user attribute from an identity source as a custom HTTP header.
      • Constant sends custom HTTP header that is static.
      Property (available if Source is Attribute) Select the user attribute property to send.
      NameEnter the name for the custom HTTP header.
      Value Enter the value of the property or constant for the custom HTTP header.
      To add a new custom header, click ADD.
    5. (Optional) Click Rewrite Rules (Advanced) to define Apache HTTP Server rewrite rules.

      Note:   Do not configure rewrite rules unless instructed to do so by RSA Customer Support.

    6. Click Next Step.
  9. On the User Access page, select an access policy that determines which users can access the application in the application portal, and whether those users must perform step-up authentication in order to use the application.
    1. Select one of the following:
      • Allow All Authenticated Users – Allow all users signed into the application portal to access the application with no step-up authentication required. This is a built-in access policy that you cannot modify.
      • Select Custom Policy – Select a custom access policy from the drop-down list. The default is No Access Allowed, which denies access to all users. No Access Allowed is a built-in access policy that you cannot modify.
    2. Click Next Step.
  10. On the Portal Display page, configure how the application will appear in the application portal.
    1. (Optional) To hide the application in the application portal, clear the Display in Portal checkbox. When unselected, the application is not visible in the application portal, but users can still access the application by going directly to the protected URL.

      For information about how this setting interacts with the Disabled setting on the Basic Information page of the wizard, see Application Availability and Visibility.

    2. Select the Application Icon to represent the application in the application portal. Use the default icon or click Change Icon to upload a different image.

      The image file must be in JPG or PNG format, and no larger than 50 KB. The recommended size is 75x75 pixels.

    3. In the Application Tooltip field, enter text that appears briefly when the cursor pauses over the application icon in the application portal.
    4. In the Portal URL field, enter the URL where the user will be directed after clicking the application icon. Replace the real name of the application with the proxied hostname, and specify the application page that you want users to reach.

      For example, suppose the home page URL for the application is https://www.appname.com/welcome. Replace the real hostname (www.appname.com) with the proxied (protected) hostname (www-appname-com.sso.example.com). Add the welcome page. Now the full URL of the application portal is https://www-appname-com.sso.example.com/welcome.

      You can use this setting to forward users to any resource on the application after they are authenticated, for example, a reports page: www-appname-com.sso.example.com/reports.

    5. (Optional) Select Allow Users to Change Credentials to specify that users must provide their sign-in credentials for the application.

      If you do not select Allow Users to Change Credentials, the identity router uses stored user credentials to sign into the application on behalf of users. RSA provides an API/CLI for populating user keychains.

      Note:   To test the application after it is configured, select this option so you can enter valid sign-in credentials when you access the application through the application portal.

  11. Click Save and Finish.
  12. (Optional) To publish this configuration and immediately activate it on the identity router, click Publish Changes.

After you finish 

After you publish to the identity router, test the connection on the identity router by signing into the application through the application portal.

 

 

Next Topic:Trusted Headers
You are here
Table of Contents > Web Applications > Add an Application Using HTTP Federation Proxy

Attachments

    Outcomes