Add an Application Using HTTP Federation Proxy

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 Applications and is available for single sign-on (SSO) after the next publish operation.

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. Choose where to enable your application for single sign-on (SSO). You can enable the application on My Page or identity router based portal. This option is available only if identity router based portal is enabled for you.
   2. In the Name field, enter a name for the application.
   3. (Optional) In the Description field, enter a description for the application.
   4. (Optional) To make the application unavailable to users, select the Disabled check box. When disabled, the application appears in 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.

   5. 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 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 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 Cloud Access Service Certificates. 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 or HTTPS. Note:  If the application uses both HTTP and HTTPS protocols, repeat Step 8 to configure a separate web server entry for each internet protocol.
      Port Number	The port number the web server uses for communication. The default HTTP port is 80, and the default HTTPS port is 443.
      Rewrite Rules (Advanced)	(Optional) Click to define Apache HTTP Server rewrite rules. Note:   Do not configure rewrite rules unless instructed to do so by SecurID 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.
      Name	Enter 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 RSATechnical 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 a Policy – Select an 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. No Access Allowed is available only if the identity router based portal is enabled.

      Note:  If you are currently using a 1.0 policy, you need to migrate to a 2.0 policy before modifying the application configuration. The 2.0 policies provide the capability to configure both Primary and Step-up Authentication options within the same access policy.

   2. Select the Allow user to request access to this application checkbox to enable users to request access to the application through My Page > Applications > App Catalog tab.

      Note:  When Allow user to request access to this application checkbox is selected, an App Catalog group is automatically created. The group name matches the application name. Additionally, users who are not eligible for this application policy can view the application in the App Catalog tab.

   3. 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. SecurID 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. On the Fulfillment page, select whether users will access the application with or without an approval workflow, and define the application configuration type. (For more information on the Fulfillment feature, see Lifecycle Management (Fulfillment Setting) in the Cloud Administration Console).

    Note:   The Fulfillment service to provision user access requests for applications or services is disabled by default.

12. Enable the Fulfillment setting to select the Approver Type and set the proper configuration type for the HTTP Federation Proxy application.

    1. Select one of the following Approver Types:

       • None: This option grants application access directly to users.

       • Manager: This option requires the assigned manager, retrieved from the Identity Source, to accept the request via My Page > Action Items to grant access to HTTP Federation Proxy for users.

       • Application Owner: This option requires the assigned application owner, retrieved from the Basic Information, to accept the request via My Page > Action Items to grant access to HTTP Federation Proxy for users.

       • Manager & Application Owner: This option requires both the assigned manager and application owner to accept the request via My Page > Action Items before granting access to HTTP Federation Proxy for users.

    2. (Optional) Select the Send Email to Requesters and Approvers checkbox to notify approvers and requesters by email once a request is submitted. This will allow approvers to view and either approve or decline the request and notify requesters of the current status.

    3. Select the appropriate configuration type from the Fulfillment Configuration Type drop-down list:

       Note:  Administrators need to ensure that all necessary configuration information is readily available before proceeding.

       Option	Description
       LDAP	Identity Source: Select one of the previously configured identity sources from the list. Fulfillment Group Name: Enter a name for the selected identity source. For example, to reference a group named "Developers" in the IT organizational unit within the domain company.org, use the following format:   cn=Developers,ou=IT,dc=company.org Note:  You can select the same identity source and assign a different fulfillment group name each time.
       SCIM Endpoint	Base URI: Enter Base URI obtained from the service provider. API Key: Enter API key obtained from the service provider. Group Object ID (Optional): Enter Group Object ID obtained from the service provider. Note:  If you cannot reach SCIM Endpoint application, ensure contacting RSA support to approve the application.

     

13. (Optional) Enable OAuth 2.0 if you are using OAuth 2.0 for the SCIM Endpoint.

    1. In the OAuth 2.0 URL field, enter the OAuth 2.0 URL obtained from the service provider.

    2. In the Client ID field, enter the Client ID obtained from the service provider.

    3. In the Client Secret field, enter the Client Secret configurations obtained from the service provider.

       Option	Description
       Entra ID	Client ID: Enter the Client ID obtained from the service provider. Client Secret: Enter the Client Secret obtained from the service provider. Tenant ID: Enter the Tenant ID obtained from the service provider. Group Object ID: Enter the Group Object ID obtained from the service provider.

14. Select Enable Delete Actions to allow managers and application owners to manage account deletion actions in My Page. You can choose from the following options:

    Note:  When you select LDAP as the configuration type, Remove from group is the only action available for account removal.

    • Delete account:Deletes the user account entirely from the SCIM or EntraID application.

    • Remove from group:Removes the user account from the fulfillment groups defined in the application’s fulfillment configuration.

    Note:  If the same group is used in the fulfillment configuration of multiple applications, removing a user from that group will also revoke their access to any other applications that share the group.

15. Select Allow enabling/disabling user account access to applications to allow managers and application owners enable or disable user accounts on the SCIM or Entra ID application.

    Note:  Disabling or enabling a user in the identity source affects access to all applications that use the same identity source.

16. (Optional) Enable Application Roles to define roles and set conditions, providing users with attribute-based access to the application.

    Note:  If a user does not match any of the configured roles, they can still request access to the application. In such cases, they will receive the default access level specified in the fulfillment configuration completed during the earlier steps.

17. (Optional) Select the Allow approvers to add users to roles or groups checkbox to enable approvers to assign/ unassign users to specific roles or groups via My Page.

18. In the Role Name field, enter the role name that appears on My Page for the approver to add users. You can either click the plus (+) icon to add additional roles, or click the minus (-) to remove roles.

    Managers and application owners can submit a Modify User Role request from My Page, and these changes follow the same approval workflow defined in the Fulfillment settings.

19. In the Additional Group field, enter the group name that appears on My Page for the approver to add users. You can either click the plus (+) icon to add additional groups , or click the minus (-) to remove additional groups.

20. The selected users must meet the criteria specified in the drop-down list. You can select one of the following options:

    • Any: This option grants access to users whose profile matches any of the set criteria.

    • All: This option grants access only to users whose profile matches all of the set criteria.

21. To set the User Attribute, click the Add button. In the User Selection dialog box, do the following:

    1. Select the User Attribute from the drop-down list.

    2. Select the Operation from the drop-down list.

    3. Enter the Value based on your operation selection.

    4. Click Save.

    Note:  If this role assigns users based on identity source attributes, ensure that the identity source is properly configured to select those attributes and synchronize them with the Cloud Access Service.

22. Click Save and Finish.

23. (Optional) To publish this configuration and immediately activate it, click Publish Changes.