SSO Story : Splunkweb and OpenAM/OpenSSO

1.0 Background

To integrate the Splunkweb in to a SSO environment, there are multiple options that customers could employ. One such method I have outlined in my earlier post. While using proxy based solution you have to instruct the proxy to perform the authentication by specifically configuring to the identity repository. It is also possible to have the proxy act like a simple proxy with out doing any authentication or authorization instead it will simply delegate the authentication to other systems including an identity and access management(IAM) system. OpenSSO/OpenAM is one such IAM system derived from Sun Access Manager product. In this article I am going to explain how Splunkweb can be  integrated in to an enterprise whose authentication is managed by the OpenAM.  You can learn more  about OpenAM  by visiting

2.0 The Theory

It is relatively very simple process to integrate the splunkweb in to an existing OpenAM/OpenSO infrastructure. As you know the splunkweb is front-ended by a proxy server, traditionally  it is the proxy server that will authenticate to the backend identity repository  and sets the appropriate HTTP request header which will be consumed by  splunkd to create the authenticated session.  In this deployment the  identity in the HTTP request header is set by the  OpenAM after a successful authentication. This is achieved by  the OpenAM web agent plugin that is installed in the proxy server that is sitting in front of the splunkweb(refer the image below). When a request for the splunkweb URI comes to the proxy from the client, the OpenAM agent intercepts and authenticates it before letting it go through(assuming it is not already been authenticated) as part of this process the HTTP request header will be set by the OpenAM agent plugin running as part of the proxy server. From then on it takes the normal course of performing the SSO process as described in my earlier post.


2.1 OpenAM Configuration

In the OpenAM side you just need to create a agent profile that will be installed on the proxy server. The agent profile name is called ‘splunk’. Once you have created make sure you perform the following configuration changes

  • Enable the Request Host/Port override, since it is a proxy agent

  • Set the SSO only mode, we do not want the authorization from OpenAM, just authentication is sufficient

  • Set the profile attributes in the HTTP request header ( Splunk-User-Commonname ), this will be consumed by Splunk to perform the SSO integration. Even though you set header name in all lowercase, it comes out as Splunk-User-Common, hence this is the one you have to use in your web.conf property file.

Once you make all of these configurations, then your OpenAM is all set to work with Splunkweb.

Here is the configuration of the agent profile named ‘splunk’[uid]=splunkuser-useridcom.sun.identity.agents.config.cleanup.interval=30com.sun.identity.agents.config.fqdn.check.enable=truecom.sun.identity.agents.config.notenforced.url.attributes.enable=falsecom.sun.identity.agents.config.notenforced.url[0]=com.sun.identity.agents.config.ignore.preferred.naming.url=truesunIdentityServerDeviceStatus=Activecom.sun.identity.agents.config.login.url[0]=[0][0]=agentRootURL=[0]|com.sun.identity.agents.config.debug.file.rotate=truecom.sun.identity.agents.config.debug.level=Messagecom.sun.identity.agents.config.fqdn.mapping[]=com.sun.identity.agents.config.local.log.rotate=falsecom.sun.identity.agents.config.repository.location=centralizedcom.sun.identity.agents.config.cookie.reset[0]=com.sun.identity.agents.config.client.ip.validation.enable=falsecom.sun.identity.agents.config.override.protocol=falsecom.sun.identity.agents.config.agent.logout.url[0]{SHA-1}6UJOfiqIYKDTGYp5TpQiLXoQg9I=com.sun.identity.agents.config.log.disposition=REMOTEcom.sun.identity.agents.config.postdata.preserve.enable=falsecom.sun.identity.agents.config.agenturi.prefix=[]=com.sun.identity.agents.config.debug.file.size=10000000com.sun.identity.agents.config.change.notification.enable=truecom.sun.identity.agents.config.anonymous.user.enable=falsecom.sun.identity.agents.config.cdsso.cdcservlet.url[0]=[cn]=splunk-user-commonnamecom.sun.identity.agents.config.response.attribute.mapping[]=com.sun.identity.agents.config.logout.url[0]=[0]=com.sun.identity.agents.config.locale=en_UScom.sun.identity.agents.config.postcache.entry.lifetime=10

2.2 Apache Proxy Configurations

Apache proxy is the key component in this deployment. It is the proxy that forwards the HTTP header set by the OpenAM agent to the downstream Splunkweb.  It is important to note the OpenAM agent is installed and configured to protect the root end point of the URL, apprently it is the Splunkweb URL.  It is the OpenAM agent that redirect to the OpenAM for authentication and eventually to set the HTTP header in this case Splunk-User-Common. Besides this you only need to configure the Proxy forwarding of requests to the backend Splunk Server as shown below.

ProxyRequests OffProxyPassInterpolateEnv OnProxyPass / /

That complete the proxy configuration. Next let us see what are the configurations we need to make in the Splunk.

2.3 Splunk Specific Configurations

In the Splunk you only have to modify the web.conf and server.conf.  Here is the configuration of my Splunk server’s web.conf

[settings]trustedIP =,, = Splunk-User-Commonname

The trustedIP is the key for the SSO to be successful, rest of the properties I left to their default values.
On the server.conf only the trustedIP has to be introduced, this is almost always the loopback interface address.

guid = 955E271B-05DC-4407-BBFE-BF51E9A0279B
serverName = splunk

Create a LDAP strategy that would point to the LDAP server  which is used by OpenAM for authentication and authorization.  As part of this you have to provide a mapping of OpenAM groups in to Splunk roles appropriately. If this mapping for authorization is not done then your SSO will fail due to authorization failure. It is one of the critical step in this whole scenario. Alternatively you can create local users that match the common name of the OpenAM users and map them to a valid Splunk role. The following screen shot shows the mapping of a OpenAM defined LDAP group “Splunk Admin” to Splunk role called “admin”.

3.0 Testing

The configuration part is done. You can test the SSO scenario now by invoking the proxy url using new browser instance, this will redirect to the OpenAM login page as there is no prior session existed. At this point provide the user identity and password, up on successful authentication, the OpenAM agent plugin running on the proxy server will set the common name of the user(in this case indira thangasamy) in the Splunk-User-Commonname HTTP request header. This header along with its value will be forwarded to the Splunkweb which inturn talks to the splunkd to perform the authorization, upon successfull verification of authorization(the user identity in the HTTP header should have a role mapping in Splunk), This user will be authorized because it is part of the Splunk Admin group in OpenAM which inturn mapped in to Splunk ‘admin’ role. This will let the user access the administrative user interface of Splunkweb.

As you notice, the HTTP header Splunk-User-Commonname is the key to get the whole thing working. If this value is not set then the SSO will fail. Ignore the yellow rectangle in the following screen shot, it is placed to mask some sensitive host data.

4.0 Conclusion

It is relatively a straight forward process to integrate Splunkweb in an enterprise identity and access management system(IAM). In this manner splunkweb can be integrated in to other IAM infrastructure including Oracle Access   Manager and Siteminder. If you want to integrate with   federated  SSO environment, you could do this by using SAML client APIs to interpret the SAML assertion and extract the identity from the subject or  with attribute query statement.



Posted by