Trusted headers is a connection method that allows RSA SecurID Access 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
- The user signs in to the application portal directly or signs in using Integrated Windows Authentication (IWA).
- RSA SecurID Access 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.
- The user clicks an application icon or link, that go to a proxy URL for the identity router.
- 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.
- The application web server returns a decision to the identity router indicating whether the user is allowed or denied access.
- 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 RSA SecurID Access 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 RSA SecurID Access. 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.
We want your feedback! Tell us what you think of this page.