Add an Application Using Trusted Headers
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 Cloud Access Service (CAS).
- At least one identity source for CAS 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 CAS.
- 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.
Procedure
- In the
Cloud Administration Console, click
Applications > Application Catalog.
The Application Catalog appears.
- Click Create From Template.
- Next to
Trusted Headers, click
Select.
The Add Connection wizard appears.
- On the Basic Information page, complete these fields.
- 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.
- In the Name field, enter a name for the application.
- (Optional) In the Description field, enter a description for the application.
- (Optional) To hide the application in the application portal, clear the
Display in Portal check box. 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.
- Click Next Step.
- 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 or HTTPS.
Note: If the application uses both HTTP and HTTPS protocols, repeat Step 5 to configure a separate web server entry for each internet protocol.
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. Real Hostname The true hostname where the application is located, without the internet protocol. Examples:Port The proxy port number. 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 RSA Customer Support.
- 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.
- 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. - 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. - (Optional)
CAS 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.
- Click Next Step.
- 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.
- 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 2.0 Policy - Select a 2.0 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.
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.
- Click Next Step.
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.
- On the Portal Display page, configure how the application will appear in the application portal.
- (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.
- Select the Application Icon to represent the application in the RSA Application Portal. Use the default icon or click Change Icon to upload a different image.
- In the Application Tooltip field, specify tooltip text to display when the user passes the cursor over the application icon.
- 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.
- (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.
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.
Enable the Fulfillment setting to select the Approver Type and set the proper configuration type for the Trusted Headers application.
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 Trusted Headers 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 Trusted Headers 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 Trusted Headers for users.
(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.
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.
(Optional) Enable OAuth 2.0 if you are using OAuth 2.0 for the SCIM Endpoint.
In the OAuth 2.0 URL field, enter the OAuth 2.0 URL obtained from the service provider
In the Client ID field, enter the Client ID obtained from the service provider.
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.
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.
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.
(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.
(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.
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.
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.
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.
To set the User Attribute, click the Add button. In the User Selection dialog box, do the following:
Select the User Attribute from the drop-down list.
Select the Operation from the drop-down list.
Enter the Value based on your operation selection.
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 CAS.
Click Save and Finish.
(Optional) To publish this configuration and immediately activate it, click Publish Changes.
Moving Applications from Identity Router Based Portal to My Page
If you are currently using IDR-based portal, you can move the applications from the current portal to My Page.
Before you begin
You must have upgraded to the version that supports My Page.
Procedure
1. In the Cloud Administration Console, click Applications > Applications.
2. Click Edit corresponding to the application that you want to migrate to My Page.
3. In the Basic Information section, click the Cloud option.
4. Click Next Step and make changes in the other tabs, if any.
5. Click Save and Finish.
Related Articles
View an Application Trust Certificate 9Number of Views Edit an Application Trust Certificate 8Number of Views Add an Application to My Page 37Number of Views Choosing a Connection Method to Add an SSO Agent Application 34Number of Views Add an Application Using HTTP Federation Proxy 64Number of Views
Trending Articles
RSA MFA Agent 2.3.6 for Microsoft Windows Installation and Administration Guide RSA Authentication Manager 8.9 Release Notes (January 2026) How to install the jTDS JDBC driver on WildFly for use with Data Collections in RSA Identity Governance & Lifecycle RSA Authentication Manager 8.8 Setup and Configuration Guide Artifacts to gather in RSA Identity Governance & Lifecycle