Trusted Headers

Trusted headers is a connection method that allows SecurID to protect applications that do not support SAML and do not contain the sign-in forms required to configure HTTP Federation. These are usually internally-developed applications that did not previously restrict access by requiring sign-in credentials.

The applications that use trusted headers determine user access by evaluating user identification data that they receive from the identity router. This data is provided in messages containing HTTP headers that the application trusts. Users can access these applications through links in an application portal.

Authentication Flow for Trusted Headers

When you use trusted headers, the identity router acts as a proxy server to protect applications from unauthorized access. The following steps describe the authentication flow for trusted header connections.
  1. The user signs in to the application portal directly or signs in using Integrated Windows Authentication (IWA).
  2. SecurID reads the access policies to determine which application(s) the user is allowed to access. The user can only see the permitted applications after signing on.
  3. The user clicks an application icon or link, that go to a proxy URL for the identity router.
  4. The identity router sends user identification data, in headers, to the application web server. This data may include user attributes, user session information, and certificates.
  5. The application web server returns a decision to the identity router indicating whether the user is allowed or denied access.
  6. If access is granted, the application opens in a new browser tab. If access is denied, the application displays an error page.

Note: If you configure SecurID to use SSL when connecting to a protected application using the trusted headers method, the web server hosting the application must have a valid SSL certificate signed by a certificate authority (CA) that the identity routers trust. For more information, see List of Trusted Certificate Authorities for HFED and Trusted Headers Applications.

When an Application Requires Multiple Proxy Web Servers

All communication to a web server that hosts an application that accepts trusted headers must be proxied to prevent unauthorized access. Therefore, if the application communicates with any external services in addition to the identity router, you must create proxied web servers for those connections.

For example, suppose you are configuring an expense reporting application to receive trusted headers from SecurID. If the application uses an analytics service to send or receive statistics, you must add a proxied hostname to the trusted headers configuration for the application to handle the analytics service connection.

Related Concepts

Choosing a Connection Method to Add an SSO Agent Application

Related Tasks

Add an Application Using Trusted Headers