After we discussed the various Single Sign-on options that you can use for secure Integration of Business Objects with your Landscape in our previous blog, we dwell deep into each one of those options.
Security Assertion Markup Language which is abbreviated as SAML is an open standard XML based Single Sign-on (SSO) protocol and has become the de-facto industry standard for Single Sign-on requirements. SAML is a web browser based SSO protocol that is not dependent on any Operating system (or) device types. It is a trust-based protocol and can 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.
SAML was predominantly created to allow for system trust establishment across the landscape with the expectation that it would be generic enough for most systems to understand. Today, SAML is seen as the best option for connecting your current on-premise landscape.
SAML setup in Business Objects is an extension of the “Trusted” authentication plugin which is part of the “Enterprise” authentication plugin. SAML setup does not depend on the source where the user account is imported from. Even though user accounts are imported from multiple sources like Windows AD, LDAP, SAP and created locally with Enterprise plugin, SAML SSO will still work without an issue.
As the name implies, this authentication is purely based on trust. “Enterprise” authentication plugin available within Business Objects allows the generation of secret keys. This secret key will be shared with the trusted third party application (or) web application server. Authentication of the user will be delegated to the third party application and once authenticated, it will pass the user information to Business Objects along with the shared secret. Business Objects will then provide a session for the specific user. Refer to this blog for more on Trusted Authentication.
SAML Setup – Requirements
SAML Setup in Business Objects is supported out of the box in the latest releases. A typical SAML setup needs a Service Provider (SP) and an Identity Provider (IdP). In this case, Tomcat web application server will act as the Service provider and IdP can be any system available in the Landscape.
System specific requirements:
- Business Objects 4.2 SP05 and above
- Trusted authentication should be enabled in Business Objects.
- Tomcat configured as a Service Provider (with SAML libraries provided by SAP)
- An Identity Provider (IdP)
In a SAML enabled system, authentication workflow functions in the same order as mentioned below:
- The user launches the Business Objects URL and request reaches tomcat server
- Tomcat, which acts as the Service Provider, redirects the request to Identity Provider
- Identity Provider will authenticate the user and will verify the credentials with the connected directory server
- Once the user is authenticated, IdP will return a SAML session
- The User name will be obtained from the session and will be sent to Business Objects along with the shared secret
- Business Objects system will then provide a session for the user
- Existing SAML setup can be re-used
- SAML SSO can authenticate users imported from all sources
- Inter-operability with available portals and Single Sign-on systems is easier
- Cross-domain single Sign-on is possible and makes SSO setup with servers on hosted environments easier
In the next blog of this series, we explore options to setup SAML for Business Objects systems that do not support SAML out of the box.