Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Hihu
Product and Topic Expert
Product and Topic Expert
There are already several good articles and KBAs (1795949 - Trusted Authentication with SAML Single Sign-On BI 4.x, 2812877 - Simplified Configuration for BOE/BIPRWS as SAML Service Provider) about configuring SAP BusinessObjects BI Platform for SAML2 Single Sign On.
I will not repeat that step by step but rather share some insights which may streamline the process. If you never did this configuration please read at least the mentioned KBA.

Think about naming before creating files and requesting a certificate


To configure Tomcat for https you need a certificate which will probably created by an internal authority. You will create a keystore and a certificate signing request (CSR). Don’t use only the hostname, add some alternatives. Often it is useful to hide the real servername with a DNS alias. If the BI system is already a cluster of multiple Tomcats you need the load balancer name. Use the alternative name not only for creating the keystore but more important also for the CSR.

Example: Your server is server1.my.org, but it is an development system, so the SID is EBO and the DNS alias might be sap-bo-dev.my.org.

I prefer to use absolute paths, so if the system is installed on Linux in /usr/sap/EBO the commands are:

Create a separate directory:
mkdir /usr/sap/EBO/saml

Create the keystore:

/usr/sap/EBO/sap_bobj/enterprise_xi40/linux_x64/sapjvm/bin/keytool -v -genkeypair -keystore /usr/sap/EBO/saml/EBO.keystore -alias EBO -keyalg RSA -keysize 2048 -ext san=dns:server1.my.org,dns:server1,dns:sap-bo-dev.my.org,dns:sap-bo-dev -dname CN=sap-bo-dev.my.org

We include FQDN for the server and the DNS alias as well as short names. Also we use the -dname parameter to avoid answering the keytool questions ;o)

Create the certificate signing request (CSR):

/usr/sap/EBO/sap_bobj/enterprise_xi40/linux_x64/sapjvm/bin/keytool -v -certreq -keystore /usr/sap/EBO/saml/EBO.keystore -alias EBO -keyalg RSA -keysize 2048 -file /usr/sap/EBO/saml/EBO.csr -ext san=dns:server1.my.org,dns:server1,dns:sap-bo-dev.my.org,dns:sap-bo-dev

Now you have a keystore file for Tomcat configuration and a CSR which can be sent to your signing department. You’ll get back a real certificate (not self-signed) to be imported into the keystore.

Re-use the keystore


The Spring SAML configuration uses also a certificate in a keystore to sign and encrypt the communication with the SAML IdP. So why not using the already created keystore?
Just remember: If you change the “SAML” keystore you always have to create new metadata for your BO system and import it into the IdP. Plan carefully!

Suggestion:

Import the real certificate

Import also the IdP certificate. At least when connecting to ADFS I found it necessary.

Copy the keystore into ../BOE/WEB-INF. I’m not a fan of redundant information but this might prevent some headaches. If everything works with a copy you can try a symlink or an absolute path in ../BOE/WEB-INF/securityContext.xml.

Example snippet in server.xml

<Connector SSLEnabled="true" maxThreads="150" port="8443" protocol="HTTP/1.1"> <SSLHostConfig ciphers="HIGH:!aNULL:!RC4:!MD5:@STRENGTH" hostname="*.my.org" protocols="TLSv1.1,TLSv1.2" sslProtocol="TLS"> <Certificate certificateKeystoreFile="C:/Daten/tomcat_ssl/BENN34058863A.keystore" certificateKeystorePassword="changeit" type="RSA"/> </SSLHostConfig> </Connector>

Example snippet in securityContext.xml

<constructor-arg value="/WEB-INF/EBO.keystore"/> <constructor-arg type="java.lang.String" value="changeit"/> <constructor-arg> <map> <entry key="EBO" value="changeit"/> </map> </constructor-arg> <constructor-arg type="java.lang.String" value="EBO"/>

Check if JVM supports unlimited key length


Please refer to KBA 1240081 - Java Cryptography Extension (JCE) Jurisdiction Policy Files

Search for
#crypto.policy=unlimited

in /usr/sap/EBO/sap_bobj/enterprise_xi40/linux_x64/sapjvm/jre/lib/security/java.security

If unsure check
/usr/sap/EBO/sap_bobj/tomcat/bin/bobjenv.sh

to find out which JVM is used.

Control shared secret location


I prefer to not copy something into BI binary directories. Therefore I put the downloaded TrustedPrincipals.conf into my created directory /usr/sap/EBO/saml and let Tomcat know about by adding
-Dbobj.trustedauth.home=/usr/sap/EBO/saml

to JAVA_OPTS in /usr/sap/EBO/sap_bobj/tomcat/bin/bobjenv.sh

E.g.
# set the JAVA_OPTS for tomcat
JAVA_OPTS="-d64 -Dbobj.enterprise.home=${BOBJEDIR}enterprise_xi40 -Djava.awt.headless=true -Djava.net.preferIPv4Stack=false -Xmx2048m -XX:MaxMetaspaceSize=384m -Dbobj.trustedauth.home=/usr/sap/EBO/saml "

BI on Linux


KBA 2812877 - Simplified Configuration for BOE/BIPRWS as SAML Service Provider contains a strange note about changing file separators in securityContext.xml:
change <value type="java.io.File">/WEB-INF/idp-meta-downloaded.xml</value> to <value type="java.io.File">\WEB-INF\idp-meta-downloaded.xml</value>
So it suggest changing the Linux native slash to the Windows nativ backslash. Looks weird and scary to me but saved my day some time ago.