Add an Application Using Trusted Headers

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

You can use trusted headers to protect access to older applications that were developed internally.

Before you begin 

  • You must be a Super Admin for the Cloud Administration Console to perform this task.
  • At least one identity router must be connected to the Cloud Authentication Service.
  • At least one identity source for the Cloud Authentication Service must be connected to the identity router.
  • Consult with a knowledgeable person at your site, such as an application web developer or support person, to learn what header information the application expects to receive. The application web server must be configured to check for headers and to prevent users from accessing the server without authenticating through RSA SecurID Access.
  • If you are using a custom image for the application portal icon, you need an image file in JPG or PNG format, and no larger than 50 KB. The recommended size is 75x75 pixels.
This configuration affects the entire deployment. All identity routers share these settings.

Procedure 

  1. In the Cloud Administration Console, click Applications > Application Catalog.
    The Application Catalog appears.
  2. Click Create From Template.
  3. Next to Trusted Headers, 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 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.

    4. Click Next Step.
  5. On the Proxy Settings page, specify a proxy web server. This proxy is the identity router. In most cases, you only need one proxied hostname for the identity router. You need multiple proxied hostnames only if the application communicates with other services. Click ADD and provide the following information.
                                   
    Field Setting
    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.

    Proxy Hostname The hostname of the proxy web server, without the internet protocol, ending with your company domain name. Use a valid alias from the Domain Name System (DNS) database that points to the identity router hostname. This alias must be unique for each application.
    Examples:
    • www-appname-com.sso.example.com
    • resources-appname-com.sso.example.com
    Real Hostname The true hostname where the application is located, without the internet protocol.
    Examples:
    • www.appname.com
    • resources.appname.com
    Port The proxy port number. 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.

  6. Provide the DNS administrator with a list of canonical name (CNAME) records. These records must be added to the DNS database before this application can use trusted headers. Each CNAME record points to the address (A) record for the hostname of the application portal. To generate this list, click Show CNAME Summary, and select one:
    • Click Hostname to show the hostname to which the CNAME record points.
    • Click BIND to show the Berkeley Internet Name Domain (BIND) format.

    Copy the CNAME list and provide it to the DNS administrator.

  7. In the Custom Headers section, select the information to pass in headers to the application.
                            
    Option Pass to Application
    Pass Attributes User attribute values from the identity source
    Pass Headers User session information
    Verify Certificates If Secure Sockets Layer (SSL) through port 443 (SSL/443) is enabled, the identity router validates the application SSL certificates.
  8. Define the custom headers.
                               
    Field Option Description
    Source Select the source where the HTTP header originates.
    • Attribute sends a user attribute from the identity source. Commonly used for trusted headers.
    • Constant sends a static string, for example, the name of the application. Rarely used for trusted headers.
    Property (available if Source is Attribute) Select the user attribute property to send.
    Name Specify the name that the application expects to receive. Consult with application developers to determine this name.
    Value (available if Source is Constant) Specify the constant value. Rarely used for trusted headers.
  9. (Optional) RSA SecurID Access provides the capability to define Apache HTTP Server rewrite rules when you click Advanced.

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

  10. Click Next Step
  11. 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.
  12. Click Next Step.
  13. 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 RSA SecurID Access Application Portal. Use the default icon or click Change Icon to upload a different image.
    3. In the Application Tooltip field, specify tooltip text to display when the user passes the cursor over the application icon.
    4. In the Portal URL field, enter the URL where the user will be directed after clicking an 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.

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

 

 

Previous Topic:Trusted Headers
You are here
Table of Contents > Web Applications > Add an Application Using Trusted Headers

Attachments

    Outcomes