Apache + Shibboleth SSO with Tomcat for BI Platform using Trusted Authentication
This document describes the steps needed to integrate Shibboleth (a SAML2 federated authentication/identity provider) with BI Platform using Trusted Authentication to achieve SSO (within the web browser, does not tie into Active Directory).
This document assumes you have already:
- Installed BIP 4.1 (used SP2 P2) with Tomcat. We used Windows 2008 R2, but nothing here is very OS-specific.
- Installed Apache 2.4.12+ (must use VC10 version) with SSL as a reverse proxy for Tomcat using the AJP connector (see below)
- Apache HTTPS/443 connects to Tomcat AJP/8009 (see below)
- Apache HTTPS/4443 (or other port number) connects to Tomcat HTTP/8080 (see below)
- Installed/configured Shibboleth 2.5.3+ (see below)
- Configured Apache with Shibboleth to protect a static folder, such as /secure, that does not exist in the BIP install
- The Apache-Shibboleth securing process is working properly (without Tomcat)
- Your Enterprise user IDs match some attribute that will be returned from Shibboleth (uid, eppn, etc.), or you plan to rename your Enterprise users to match one of the Shibboleth attributes
- We only use Webi and Crystal, you may need to tweak your setup if you use other tools
Example Tomcat server.xml (relevant pieces only)
|
<Connector port=”8080″ protocol=”HTTP/1.1″ connectionTimeout=”20000″ redirectPort=”443″ compression=”off” URIEncoding=”UTF-8″ /> . . . <Connector port=”8009″ protocol=”org.apache.coyote.ajp.AjpNioProtocol” redirectPort=”443″ URIEncoding=”UTF-8″ enableLookups=”false” tomcatAuthentication=”false” address=”127.0.0.1″ scheme=”https” connectionTimeout=”20000″ maxThreads=”400″/> |
Example Shibboleth2.xml (relevant pieces only)
|
<ApplicationDefaults . . . REMOTE_USER=”uid” #### <– This is whatever attribute your IdP returns that will match your Enterprise accounts . . . > |
Example httpd.conf (relevant sections only)
|
. . . Listen 80 TimeOut 300 AcceptFilter http none AcceptFilter https none EnableSendfile off EnableMMAP off <VirtualHost _default_:80> RewriteEngine on ReWriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] </VirtualHost> ServerName yourserver.yourdomain.com UseCanonicalName On Include D:/opt/shibboleth-sp/etc/shibboleth/apache24.config ExtendedStatus On #====================Configure mod_deflate============== AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript text/json ##### Should be on one line with previous DeflateCompressionLevel 9 SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary |
Example ssl.conf (relevant sections only)
|
. . . Listen 443 <VirtualHost _default_:443> RewriteEngine on ProxyPass /Shibboleth.sso ! ProxyPassReverse /Shibboleth.sso ! ProxyPass / ajp://127.0.0.1:8009/ ProxyPassReverse / ajp://127.0.0.1:8009/ . . . <Location /BOE> AuthType shibboleth ShibRequestSetting requireSession 1 require shib-session </Location> <Location /shib> AuthType shibboleth ShibRequestSetting requireSession 1 require shib-session </Location> # The next 3 are required to use the Webi Java applet since it connects separately and Shibboleth gets confused <Location ~ “/BOE/portal/.*/AnalyticalReporting/webiApplet/.*”> Satisfy Any Allow from all AuthType None Require all granted </Location> <Location ~ “/BOE/portal/.*/rebean3ws/services/.*”> Satisfy Any Allow from all AuthType None Require all granted </Location> <Location ~ “/BOE/portal/.*/InfoViewAppActions/ajaxUre/.*”> Satisfy Any Allow from all AuthType None Require all granted </Location> </VirtualHost> Listen 4443 <VirtualHost _default_:4443> . . . ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ </VirtualHost> |
BIP Config
- For reference, see the BI Admin Doc, starting on page 229 about Trusted Authentication. The essential steps are below.
- Set the Authentication parameters similar to this, generate and download a new Shared Secret, then click Update
3. Put the shared secret file, TrustedPrincipal.conf on the WEB SERVER, in this directory
D:\BI4\SAP BusinessObjects Enterprise XI 4.0\win32_x86\
4. Followed the SAP doc 1593628 to test the SSO using QUERY_STRING
- Create file global.properties in D:\BI4\tomcat\webapps\BOE\WEB-INF\config\custom with the following contents
sso.enabled=true
trusted.auth.user.param=user
trusted.auth.user.retrieval=QUERY_STRING
b. Save, then restart Tomcat
c. Should be able to get into Launch Pad now using the URL (e.g.)
https://myserver.mydomain.com:4443/BOE/BI?user=myuser
d. This demonstrates all the Trusted Authentication pieces are working, without Shibboleth
5. To put it all together, update the global.properties file so it looks like this
sso.enabled=true
trusted.auth.user.retrieval=REMOTE_USER
- Save, then restart Tomcat
- Close and reopen your browser
- Go to the URL, https://myserver.mydomain.com/BOE/BI
- You should be prompted to log in via Shibboleth
6. If you’re having trouble, you can use a /shib directory (create under Tomcat\webapps\) to see the values being passed from Apache/Shibboleth using a JSP, e.g.
|
<%@ page import=”java.util.*” %> <html> <head> <title>Http Request Headers Example</title> </head> <body> <h2>HTTP Request Headers Received</h2> <table> <% Enumeration enumeration = request.getHeaderNames(); while (enumeration.hasMoreElements()) { String name = (String) enumeration.nextElement(); String value = request.getHeader(name); %> <tr><td><%= name %></td><td><%= value %></td></tr> <% } %> </table> <% out.print(“request.getRemoteUser: “+request.getRemoteUser()+”<br/>”); out.print(“request.getUserPrincipal.getName(): “+request.getUserPrincipal().getName()+”<br/>”); %> </body> </html> |
Login page setup
- We created a custom login page that presented links for both Shibboleth and Enterprise logins, under /auth, which then directs users to login via one of those methods
- Set up a redirect from /index.jsp (tomcat ROOT) to /auth/index.jsp, then present links to log on either via Shibboleth, or via Enterprise (port 4443)
- In \BI4\tomcat\webapps\BOE\WEB-INF\config\custom\BILaunchpad.properties, set url.exit to e.g.
https://yourserver.yourdomain.com/Shibboleth.sso/Logout?return=yourIDPlogoutURL
4. Stop/Restart Tomcat
5. Either way you log in, you will be redirected to the Shibboleth logout. This is done to handle weird address issues when logging in/out via different methods.
it would be helpful if document explained why is this being done and for what business purpose, what Shibboleth is and how can it help BOE systems etc...
Thank you for the suggestion, I added in a bit at the top and clarified some other pieces.
Hi Brian,
I need to integrate Okta with BOBJ BI - Tomcat as a Service Provider. Can you help me with some step by step instructions please?
Rgds,
Ali
Mr. Hill has a great guide here (THANK YOU!) *but* it does assume some working knowledge of SAML to fill in the blanks.
I would add that the most important piece in getting this setup working with a commercial IdP like Okta (or any other) is mapping an attribute (or set of attributes) using the provider's 'Attribute Statements' for the defined application. Then, on the Shibboleth SP side, make sure to edit '/etc/shibboleth/attribute-map.xml' to reflect the chosen attributes. Without these additional steps, you only have the attributes Shibboleth provides out-of-the-box which doesn't include something like the "uid" referenced for the REMOTE_USER value in this guide (aside from LDAP-based setups). Here's what it looks like added to attribute-map.xml:
<!-- Example of Okta attributes needed in Shibboleth's attribute-map.xml ! -->
<Attribute name="uid" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" id="uid">
<AttributeDecoder xsi:type="StringAttributeDecoder"/>
</Attribute>
Without proper assignment and mapping of attributes between the IdP and Shibboleth SP you will be pulling your hair out wondering why nothing is being populated and passed via REMOTE_USER. There are also a couple of other things you need to make this setup work with Okta specifically.
The first is that it is more helpful to use Okta's deprecated SAML2 application template for this BOBJ/Tomcat/Apache/Shibboleth setup as opposed to their newer wizard as it gives a little more field flexibility when defining attribute statements to pass to the SP. Make sure to double and triple check that you don't have fields such as "Post Back URL", "Recipient", "Audience Restriction", "Destination" or "Default Relay State" mismatched. Having one or more of those improperly defined can put you in a world of hurt when trying to pass assertions (infinite redirect loops are not fun to troubleshoot).
Referencing this guide for BOBJ and the recommended, deprecated SAML2 application template from Okta, typical input would be as follows:
Post Back, Recipient, and Destination URLs: https://<HOST_FQDN>:443/Shibboleth.sso/SAML2/POST
(This would usually be known as the Assertion Consumer Service, or ACS, endpoint)
Audience Restriction and Default Relay State URLs:
https://<HOST_FQDN>:443/BOE/BI
(Audience Restriction assumes '.../BOE/BI' URL is the 'entityID' you chose for your SP in 'shibboleth2.xml' . It is not necessary to define Default Relay State if authentication is always/only SP-initiated)
Other (possibly required) fields of note in the template:
Name ID Format = Transient
authnContextClassRef = PasswordProtectedTransport
Request = Compressed
Attribute Statments = uid|${user.userName}
The second important piece is downloading the metadata file from Okta and making sure you load up certs for the virtual SSL hosts that Apache makes use of (443 and 4443 as referenced). If you haven't messed about in shibboleth2.xml before then it may not be 100% clear where and how you reference the IdP metadata. SSO 'entityID' should be the same referenced in the metadata (i.e. http://www.okta.com/<APP_ID_STRING>) and you can reference your metadata file directly from the filesystem like so (note the importance of the forward slashes even if you're on a Windows platform):
<MetadataProvider type="XML" file="C:/opt/shibboleth-sp/etc/shibboleth/Okta_metadata.xml"/>
The Apache virtual SSL hosts' certs/keys are defined in the 'httpd-ssl.conf' file like this:
SSLCertificateFile "c:/Apache24/conf/certificate.crt"
SSLCertificateKeyFile "c:/Apache24/conf/private.key"
Of course certs should come from a CA that the client browser trusts. If the cert is self-signed without a trusted root CA on the client side, the standard browser warnings can throw off the SAML assertion exchange between IdP and SP (retries, timeouts, etc.).
That's about all I can think of for now. Okta does have a built-in template for BOBJ Secure Web Authentication as well but that requires a browser plug-in and does not use SAML as the setup in this guide does.
Just wanted to add that I followed this document and implemented successfully a couple of weeks ago. Thanks for putting this out there. I may want to share my experiences and tweaks here and there in another post referencing your document as the starting point. It can be a pain to get it to work and implement. But it's one of those things where you get it to work on one then it's the same for the others.
Thanks a ton. We've been trying to implement this with Shibboleth for a while.
I followed this blog, but can't get it to work.
We successfully setup trusted authentication as described in SAP note 1593638.
Then we followed this blog to set up redirect to Okta using shibboleth:
Redirect also works.
When we go to https://boserver.company.com/BOE/BI it redirects to Okta.
After log on in Okta it returns to BO, but we still get the BO logon page.
In shibboleth logs we can see that Okta authentication was successful.
We got SAML token and user id back, but user id doesn't get routed to BO.
Anybody have any ideas what might be missing or can check our configuration?
Your help is greatly appreciated.
Thanks,
Dieter
We are trying to implement Okta integration via SAML with SAP BI 4.2 (Windows+Tomcat).
Installed Apache+Shibboleth (to acts as Service Provider).
However we are seeing errors is shibboleth logs
"error building CredentialResolver: FilesystemCredentialResolver given mismatched key/certificate, check for consistency." & "Shibboleth.SessionInitiator.SAML2 [1]: no credential resolver installed, leaving message unsigned".
End result is looping between Okta and SAP BI.
Can anyone share their Shibboleth2.xml file and any other relevant files (or) any documentation.
Configuring Service Provider seems to be out of SAP Support. I wish they have included SAML Authentication like Tableau which has inbuilt.
-Thanks,
Deepu.