Using the Go-URL in OAS
The OBIEE Go-URL functionality is widely used and it's deprecation in OAS is causing issues for companies wishing to upgrade to OAS.
This is a feature of OBIEE that allows a report to be accessed directly from a URL, enabling links from other applications - often with optional parameters passed through to filter the report - and usually bypassing the login screen by including user credentials within the URL parameters.
Typically a single user-id is used for Go-URL access to OBIEE reports thus avoiding the need to either enter/detect user details or to provide login credentials for users who would not login to OBIEE directly.
With the first release of OAS, Oracle have announced that the Go URL functionality is being deprecated and may be removed in a future release. Also, since OBIEE 12.2.1.3, the advent of the combined bi security login screen for both Analytics and DV has meant the NQUser and NQPassword parameters no longer work, so it is not possible to specify a user for the Go URL and hence it cannot login.
There are currently two scenarios under which the Go-URL does work in OAS:
-
If full Single Sign-on to OAS has been implemented - via Oracle Access Manager or Apache, currently the only recognised methods for SSO in OAS - then the Go-URL will work under the user-id that SSO signs in under. In other words, the user credential parameters in the URL are ignored, the user logs in automatically under their credentials and the requested report displays as normal.
However this is often not appropriate - if users are clicking on Go-URL links outside the scope of the SSO environment, for instance connecting via the internet or from other networks within the company LAN where SSO could not operate. Also if reports are designed to work under a specific user, perhaps with special security rules, a users own security levels may result in different data appearing in a report.
- Disable the lightweight SSO option in OAS. This separates the security for Analytics and DV. For Analytics this returns to the classic login screen and the NQUser and NQPassword parameters on the Go-URL work correctly, but this causes issues for DV making it virtually unusable. This is only really an option if you do not want to use DV in your implementation of OAS.
There is however a third option we have discovered which uses the Single Sign-On approach, but without the need to actually detect user credentials via an SSO service. Instead a specific user-id can be provided, just like the NQUser parameter in the Go URL.
Instead of the Go URL passing the NQUser and NQPassword parameters, Apache can be used to re-direct access to OAS, providing the user-id to login with during the re-direct. The effect is that the Go URL will still display the same report output whilst logging in with the same user-id, albeit supplied by Apache rather than the NQUser parameter.
This works by using the Single-Sign-On configuration between Apache and OAS.
In a normal SSO configuration, Apache would authenticate users via a standard SSO service, for example, Kerberos, and once the user has passed authentication, redirect the URL to OAS, providing the user credentials as request-headers, so that OAS can automatically login the user in, bypassing the login screen.
The Oracle document ID 2707401.1 explains this process in detail.
We can however ignore the SSO authentication within Apache and instead hard-code the User-id we want to login to OAS with. Apache will still send this user-id in the request-header to OAS, which in turn will recognise it as a pre-authenticated user and log the session in. In the case of a Go URL, the rest of the URL which points to a report or dashboard will continue to process as normal, displaying it to the user.
The user is totally unaware of the difference - they click on a link and see a report in OAS just as they did in OBIEE.
Just as with the Go URL there are security implications of this. The user-id and password are no longer sent in plain text in the URL, which is an improvement, but calling the URL will automatically login you into OAS. if you just use the core URL of http://oas-server:port/analytics, you will be logged in to OAS and end up at the home screen, without any user/password challenge.
It is important therefore to restrict the permissions and privileges of this hard-coded user so it can only access the reports/data it needs to and cannot create new content, access other subject areas etc. Using the Apache configuration, OAS can be tied down so that just the /analytics URL can be opened for this, so no access can be given to /dv, /xmlpserver or any other area of OAS unless explicitly required.
By using Apache to control access to OAS you create a separate port to call OAS on for the Go-URL. This means the port you installed OAS with (e.g. 9502/9503) will remain as the main port for logging into OAS via the login screen - users manually connecting to OAS for analytics, DV and all the other functionality, should continue to use this port. These connections will not go via Apache.
The Go-URL will use the port provided by Apache - in the instructions below I’ve set this up as port 9603 - and Apache will re-direct the user seamlessly to OAS’s main port. Apache can also be configured to use SSL certificates, and if installed on the same server as OAS, the same certificates as OAS. In this example I’m not using SSL, but the instructions for doing so are included.
Assuming you have already OAS installed, below are the steps to install and configure Apache to act as the “SSO” front-end for the Go-URL. The instructions below were carried out on an Oracle Enterprise Linux 7.8 server - other versions of Linux or using Windows will be slightly different.
Start by installing Apache HTTP Server
As the root user, use yum to download and install Apache and the required SSL and SSO plug-ins:
yum -y install httpd mod_ssl mod_auth_kerb mod_auth_token
Then enable and start Apache:
systemctl enable httpd.service systemctl start httpd.service
Next enable Apache to connect to the network and allow access on port 9603. In this case I’ve installed policycoreutils to get the semanage command as I have SELinux enabled.
yum -y install policycoreutils-python
/usr/sbin/setsebool -P httpd_can_network_connect 1
semanage port -a -t http_port_t -p tcp 9603
semanage port -l | grep http
The final command above confirms port 9603 is now available:
Next open the firewall port for 9603:
firewall-cmd --zone=public --add-port=9603/tcp --permanent service
firewalld stop service
firewalld start
systemctl restart httpd.service
Now Apache is is installed, we can configure it. Edit the file /etc/httpd/conf/httpd.conf
Set the Listen port and, if SSL is required, add the SSL virtual host properties with the correct server, port and SSL certificate file values (I’ve included the SSL virtual host in httpd.conf, but it could reside in it’s usual place in ssl.conf instead)
Listen 9603
<VirtualHost oasvm3.local.com:9603>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
ServerName oasvm3.local.com
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /u01/oas55/ssl/certificate.crt
SSLCertificateKeyFile /u01/oas55/ssl/certificate.key
SSLCertificateChainFile /u01/oas55/ssl/certificate_chain.pem
SSLCACertificateFile /u01/oas55/ssl/ca_certificate.crt
SSLProxyCACertificateFile /u01/oas55/ssl/ca_certificate.crt
RequestHeader set WL-Proxy-SSL "true"
RequestHeader set IS_SSL "ssl"
RewriteEngine On
RewriteOptions Inherit
ProxyPreserveHost On
</VirtualHost>
save and close, then restart apache:
systemctl restart httpd.service
Then try the Apache URL in a Browser: http://oasvm3.local.com:9603 (or https for ssl)
if using SSL check for the padlock icon in the address bar.
Configure Apache for OAS
Re-open the httpd.conf file and locate the line:
#ServerName www.example.com:80
below this add the following lines - these are typical recommended settings for OAS
###### Various default settings ######
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 6000
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 0
#
# KeepAliveTimeout: Number of seconds to wait for the next request from
# the same client on the same connection.
#
KeepAliveTimeout 60
#
#####################################
Now add the following lines to the end of the file, altering the OAS URLs appropriately. The ProxyPass URLs must be the original SSL or Non-SSL OAS URLs.
Define GoUser reportuser
RewriteEngine On Proxy
PreserveHost On
# Protected Resources
<Location "/analytics">
ProxyPass "http://oasvm3.local.com:9502/analytics"
ProxyPassReverse "/analytics"
#SSLRequireSSL
RequestHeader unset Authorization
RequestHeader set OAM_REMOTE_USER ${GoUser}
RequestHeader set iv-user ${GoUser}
RequestHeader set SM_USER ${GoUser}
</Location>
ProxyErrorOverride Off
# Unprotected Resources
<Location "/bi-security-login">
ProxyPass "http://oasvm3.local.com:9502/bi-security-login"
ProxyPassReverse "/bi-security-login"
</Location>
The first line defines the user which will login to OAS, in this case I’ve created a user called ‘reportuser’. This is then substituted into the request headers below.
Ideally this user should exist in the provider used for authentication in Weblogic - so that any security groups can be picked up to control this user's access with OAS.
Note the SSLRequireSSL is hashed out, the hash must be removed if SSL is required.
save and close, then restart Apache:
systemctl restart httpd.service
Configure Weblogic to accept SSO calls from Apache
To enable Weblogic to recognise SSO tokens to Apache we use the OAM Identity Asserter.
Login to the Weblogic admin console, Navigate to Security Realms → myrealm → Providers, then Click Lock & Edit, then click New.
Click New. Enter a name and choose OAMIdentityAsserter as the type.
Click OK to add the provider:
Click on the new OAM Asserter provider to edit it. Change the Control Flag to REQUIRED & click Save. The remaining default settings are fine.
Return to the providers screen, click Reorder and move the OAM Asserter so it is second in the list below the main user directory, in this case PaulsAD is the main active directory authenticator
This next step isn’t strictly necessary - the Weblogic Plug-in is required to allow access to Data Visualizer and if you have no intention of allowing access to DV via Apache, this step can be skipped.
The Weblogic Plug-in needs enabling in three locations.
From the Domain Structure window click on bi
Go to the Web Applications tab
Scroll down to the WebLogic Plugin Enabled option and check it. then click Save.
From the Domain Structure window expand Environment and click on Servers. Click on bi_server1 in the Configuration tab.
Scroll down the General, click on the Advanced link, then locate the WebLogic Plug-In Enabled option and set it to ‘yes’. Click save.
From the Domain Structure window click on Clusters. Click on bi_cluster
Again in the General tab click on Advanced then set the WebLogic Plug-In Enabled option to ‘yes’. Click save.
All changes are now complete. Click Activate Changes.
A full stop and restart of Weblogic & OAS is required under the oracle user:
/u01/oas55/config/domains/bi/bitools/bin/stop.sh
/u01/oas55/config/domains/bi/bitools/bin/start.sh
Enable Lightweight SSO
For this method of accessing OAS to work, the internal lightweight SSO must be enabled. It will be enabled by default, but if it has been disabled, for example to make the Go-URL work, then re-enable it:
Stop OAS, open the WLST command line:
cd /u01/oas55/product/oracle_common/common/bin ./wlst.sh
Re-enable SSO (alter the domain path to suit your environment)
wls:/offline> enableBISingleSignOn('/u01/oas55/config/domains/bi','/bi-security-login/logout?redirect=/dv');
wls:/offline> exit();
Then restart OBIEE to reflect the changes.
The Apache configuration is now complete and you should be able to login to OAS on the Apache URL, e.g. http://oasvm3.local.com:9603/analytics
The SSO configuration should automatically log you in under the user defined in the apache configuration above:
The Original OAS URL remains on port 9503 and will take you to the normal login screen:
Note than when you login via the Apache you can’t sign-out! You can click the sign-out link, but the SSO process will simply login you back in again rather than displaying the login screen. To login normally close the browser and reopen with the standard OAS URL.
Apache Log files
If you have any issues with the above, there are five log files for Apache you can use investigate whats going on.
/var/log/audit/audit.log Contains SELinux issues
/var/log/messages Contains general activity messages
/var/log/httpd/error_log Contains errors generated by Apache,including some SSL and Kerberos messages
/var/log/httpd/ssl_error_log Contains SSL errors generated by Apache
/var/log/httpd/ssl_access_log Contains messages related to users connecting over SSL
The logging level in the error_log file is governed by the LogLevel setting in /etc/httpd/conf/httpd.conf This is normally be set to ‘warn’, but can be set to debug to display detailed messages.
Testing the Go URL
With Apache/SSO now enabled, the Go URL can be used:
http://oasvm3.local.com:9603/analytics/saw.dll?Go&Path=%2Fshared%2FPipeline QuickAnalytics%2FPipeline%2FSales Pipeline-Charts&locale=en-en&lang=en
Note that if the Go URL includes the NQUser and NQPassword parameters, they will be ignored.
Alternatively the Dashboard parameter can be used to take a user fully into OAS to view a dashboard:
http://oasvm3.local.com:9603/analytics/saw.dll?dashboard&PortalPath=%2Fshared%2FPipeline QuickAnalytics%2F_portal%2FSales Effectiveness
An important point here is that the user is now logged into OAS and can access other content. As mentioned earlier, the user used for Go URL access should have their permissions and privileges tightly controlled to limit access to just what it required.
Accessing other areas of OAS
The instructions above only provide access to the core /analytics functionality via the Apache SSO URL. Other areas of OAS, such as /dv or /xmlpserver are not enabled:
If these are required the location entries must be added to the httpd.conf file and Apache restarted.
The full list locations can be found in the Oracle doc mentioned earlier, and includes protected and unprotected locations (as some must be visible prior to logging into OAS, e.g. the bi-security-login URL). As an example, here is the location required to enable DV:
<Location "/dv">
ProxyPass "http://oasvm3.local.com:9502/dv"
ProxyPassReverse "/dv"
#SSLRequireSSL
RequestHeader unset Authorization
RequestHeader set OAM_REMOTE_USER
${GoUser} RequestHeader set iv-user
${GoUser} RequestHeader set SM_USER
${GoUser}
</Location>
Thats it, your now ready to use the Go-URL with the Apache URL and not include the NQUser/NQPassword parameters.
This solution is not ideal and does have security implications you must take care of, although it does avoid the user/password appearing in the URL, which is a definite positive.
One downside of this is that you can’t use multiple user-ids - all the Go URL’s will connect with the same user, it is not possible (well we’ve not found a way yet) to allow different Go URLs to connect with different user-ids. Apache will only allow one redirect to /analytics on the main listen port.
Enjoy!