Skip to Content

Securing Trusted authentication

 

As we know, Trusted authentication (TA) is used when we need to authenticate against any unsupported(by BOE) authentication systems. That is, with trusted authentication, we defer the responsibility from the central management server (CMS) to another system with which a trust would be established. Typically, TA is setup between CMS and the application webservers for applications like Launchpad, Central Management Console or OpenDocument. It can be setup for Restful APIs also. Trusted authentication APIs are also available in the BOE SDK, which means custom applications can also be written using this type of authentication.

However, it is important to take note of a few security concerns and accordingly setup the landscape when TA is enabled. While setting up the webserver for TA, there are certain configurations that we need to do in the web application. Particularly, the way to retrieve the user name – trusted.auth.user.retrieval . The allowed values are REMOTE_USER, HTTP_HEADER , COOKIE, QUERY_STRING ,WEB_SESSION, USER_PRINCIPAL. Now, the most commonly used are HTTP_HEADER and QUERYSTRING. What this means is, the application code (say,within Launchpad or CMC) will be reading the user name based on this setting. All the application will look for is just this username on the header or querystring, as would be cofigured. The application would have no means to know the veracity of the source of this request. I.E., in other words, there is a possibility of impersonation if TA is not setup correctly. TA is well used by many clients. So, thought it would be worthwhile to put together, even if its at a conceptual level, the best practices while using TA.

 

Consider the below scenario:

In a typical scenario where TA is required, there would be a portal application or a custom application to where the end user would first logon to. This application would then have links to BOE. SO, if the user now clicks on these links that take the user to BOE, BOE would need to authenticate the user (using TA).

If the user can go directly to the BOE servers, it could pose a possible vulnerability.

 

In the above, there is no way for the BOE webserver to know if what it gets on the queryString (or header) is a request from a legitimate user or not. This is an incorrect and potentially unsafe configuration of the landscape.

 

For a correct configuration, one of the ways is to not allow end users to directly access BOE webserver at all, especially for login – i.e., we should block the login URLs that come directly to BOE(at least).

 

 

 

Using the proxy configuration to block direct access:

A proxy has to be setup in such a way that direct requests to the BOE server is not entertained. Only those requests (for login) that come via the portal/custom application should be allowed to access BOE.

 

For the above, there will be configuration required in the proxy, which is typically a network/IT administrator work.

 

Using x509 certificates:

  1. Using end-user x509 certificates:

BOE web applications can be configured for x509 based Trusted authentication.

This is more secure as the source of the login request will now be carrying the x509 certificate and is therefore treated as legitimate. But, in many cases, not every end user would have a x509 (because this depends on the enterprise’s auth policies). Yet, this should be considered at least for access to CMC. Since CMC is an admin application, not many administrators or delegated administrators would be there. It may be possible that the enterprise can provide x509 certs to all BOE admins. This will make the TA setup secure to a large extent. And if we can rely on x509s, no proxy or any such configuration would be required.

 

  1. Using application/proxy x509 cert:

There is an additional setting that can used on BOE which can be another layer of security when using TA. If landscapes allow us to inject a x509 on the login requests, BOE can validate against this. I.E., either the custom/portal application or the proxy/gateway(in case of SAP landscape) can insert or inject a particular x509 which is also registered with BOE. BOE then will allow only those login requests to go through. This eliminates the need to every end user to have the x509.

How to configure:

  1. Create an X.509 certificate and save it at INSTALLDIR>\SAP BusinessObjects Enterprise XI 4.0\win64_x64.
  2. Go to <INSTALLDIR>\tomcat\webapps\BOE\WEB-INF\config\custom.
  3. Edit the global.properties file.
    1. Enable X.509 authentication by changing the property auth.user.enablex509 as true.
    2. You can add the certificate name by editing the property auth.user.enablex509.certname.
  4. You should then ensure that the custom/portal application OR the proxy/gateway that intercepts the request, adds the X.509 certificate on the request.

 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply