In today’s heterogeneous BI world, Single Sign-on (SSO) is something that has become the foremost need in everyone’s minds. This is primarily to ensure user-adoption and also, to reduce IT-related bottlenecks that come with users having to remember multiple passwords, managing security etc.
Earlier, Single Sign-On (SSO) was an afterthought mainly because the Business did not know the shelf life of a product in their enterprise. Now with products being tightly coupled to an ecosystem or platform, it is easier to bring a new tool in and harder to take it out.
Business Objects being a dominant and widely used analytics platform offers multiple Single Sign-on (SSO) options and in most cases, Single Sign-On (SSO) is default in Kerberos, which is what most people have implemented and it has a wide knowledge base, too. In this blog, we are going to look at how Kerberos is slowly becoming outdated and the other challenges that organizations face. We will also touch upon other security protocols that you can implement right now to ensure that your Business Objects stays current to the enterprise security needs.
Where does Kerberos come up Short?
Being a proven and stable technology for decades, Kerberos is falling short on many fronts in today’s world due to multiple reasons, like the following:
- Bring Your Own Devices (BYOD) – When users use their own devices, it is difficult for the domain controllers to send Kerberos tickets to the user systems. It needs additional software and complex configurations to securely send tickets to devices which are not part of the corporate domain.
- Diverse Operating Systems – With the increased adoption of different operating systems and devices, Kerberos ticket is not a viable option anymore as some of them do not support Kerberos out of the box.
- Browser Support – Kerberos is not supported in most of the browsers out of the box (of course, there are workarounds) and some browsers need configuration changes to work with Kerberos. Such changes make it difficult for a normal end user and also become an IT nightmare considering versions, compatibility, testing, and rollout, that have come to be expected of any Software.
- Complex Setup – Kerberos setup in Business Objects is a little complex as Business objects is a JAVA based application. More often, Kerberos setup runs into issues and needs a good amount of debugging effort.
With the advent of Identity providers and authentication management, there is a need for alternate Single Sign-on (SSO) options which are more flexible, supports diverse platforms, adheres to latest standards and offers a seamless experience for the users, such as:
Security Assertion Markup Language (SAML)
SAML is an open standard Single Sign-on protocol based on XML and has become the de-facto industry standard for Single Sign-on requirements. SAML is a web browser based SSO protocol and it is not dependent on Operating systems (or) device types. It is a trust-based protocol and can even be used to perform Single Sign-on with systems which are not part of the same domain. SAML setup in Business Objects is fairly simple and it is an option supported out of the box in latest releases (4.2 SP05 and above). Refer to this blog to read more on SAML.
X.509 is a standard defining the format of public key certificates and used in internet protocols. X.509 also offers an authentication mechanism where each user has his/her own X.509 cert signed by a certificate authority, which can be used to validate their identity. Business Objects supports X.509 Single Sign-on mechanism out of the box. However, to use this method, a proper certificate issuing, and revocation system is needed. Usually, this method is used in conjunction with a third-party reverse proxy or a web server. Refer to this blog to read more on X.509 Authentication.
This method is native to Business Objects and this is part of the “Enterprise” authentication plugin in Business Objects. As the name implies, trusted authentication is purely based on trust and it involves sharing of the confidential information with a third-party system (or) the web application server. SAML and X.509 Single Sign-on methods in Business Objects are an extension of the “Trusted” authentication and Trusted authentication can be extended to be used with various other methods. Refer to this blog to read about more on SAP Business Objects SSO – Trusted Authentication. It also provides the foundation for integration with custom Single Sign-on solutions, which are homegrown. However, this option should be used with extreme caution as improper design might expose the system and put it at risk.
All the above-mentioned alternate Single Sign-on methods have some advantages over the traditional option and as they are trust-based, and they can be used against user accounts that are imported from different sources. If a system has some users created locally (Enterprise users), some imported from Windows AD and some imported from SAP BW/ECC – SAML/X.509/. Trusted Single Sign-on will work for all users irrespective of their source. They can also be used in conjunction with other SSO types.
SAP has recognized that their analytics platform of choice has to stay relevant in today’s world where users have a choice and it is more of a question of making the platform work well in the enterprise rather than have a solution pushed down and the user taking it in the chin. The latter used to work earlier but then it has been found to be self-defeating and causes more harm than good by leading to Landscape Fragmentation and additional administration overheads.
In the next series of blogs, we will present more details on these Single Sign-on methods and discuss the architecture, implementation options and pros/cons of it.