SAML authentication with LDAP authorization

[tlmayes]

Ask the question of Splunk support and was told "not possible". I am counting on the fact that we are not the only organization running into this problem.

Or organization is a heavy user of AD for our RBAC solution. Granular roles are managed by one of MANY corporate wide RBAC solutions, all accessed via LDAP. We have the option of LDAP or SAML for authentication, but only SAML for 2-factor. We now need to integrate Splunk with SAML for 2-factor.

The challenge: PingIdentity is used for Authentication only and the IDP team will provide two roles only (Admin, Users). Any additional roles must be presented via the App (splunk) or LDAP. Not finding a way to perform Authentication via SAML and Authorization via something else, and Splunk support is confirming with a "not possible".

[smarius]

I manage to use saml to map everyone in my company to one AD with user role so every time that a new user come with have the saml auth. with a role that cant do anything, just point them to a portal that will use splunk api to create and add/remove roles with that user(ldap) on splunk and if that ldap exist in splunk it will take precedence over saml when he logs with the roles that he requested.

[tlmayes]

No. Load balancer in front of SH cluster only. Your suggestion of installing Apache locally is a great idea and will investigate. Sometimes the forest gets in the way of the trees, but for simplicity purposes would be ideal if a single proxy (maybe one dedicated to management servers) could host all management servers. Will investigate as well as an option.

Additional challenge as I work through this. The answer may be in the deployment as discussed above, but don't know yet. On management servers, there is a requirement to login via CLI in order to execute package deployments, etc. This requires a "local" account, which bypasses SSO/SAML. This also creates a backdoor for all SSO users (they are all admins on these servers). Defeats the purpose of having SSO. Have found no way around this using SSO/SAML directly between mgmt servers and IDP, but the local proxy solution might help. Will follow-up with results

[cboston]

I'm about to need to do something similar. We're using an IDP (RSA SecurID Access) that can't seem to pass through multivalued attributes except as a comma-delimited string, which Splunk doesn't want to parse as a group list. The IDP is very limited so there's no easy way to pass useful role data from AD into the SAML assertion. We're currently using AD/LDAP authentication successfully, but having true SSO would be nice so I can be lazy and not have to type my password.

I think I'm going to have to use header-based SSO instead. This is a bit complex, because it involves setting up a proxy and running the SP there instead of using Splunk's built-in SAML support. Fortunately I have experience there -- I already have a working setup to do something similar for OWA. In that case it's an Apache2 proxy in front of Exchange, with a Shibboleth SP and a special module I wrote to convert the assertion to a Kerberos ticket (S4U2Proxy aka Kerberos-constrained delegation) to pass to OWA.

The setup for Splunk will be a bit simpler than that -- Splunk doesn't need Kerberos and can just trust the proxy to set an HTTP header with the authenticated username.

As "Proxy SSO" doesn't include any kind of authorization data in the headers, you can continue to use LDAP for that, according to the documentation at least.

https://docs.splunk.com/Documentation/Splunk/7.0.1/Security/HowSplunkSSOworks
https://docs.splunk.com/Documentation/Splunk/7.0.1/Security/ConfigureSplunkSSO

So, Apache2/mod_shibboleth sits as a proxy in front of Splunk and just passes on a header with the username. The proxy can even be on the same machine and listen on 443 if you want (leave Splunk on 8000). It's not ideal, but it should work.

Will update with any gotchas or caveats once I've tried this.

[cboston]

I can confirm that this does work. Quite well, actually. LDAP authentication stays active so all of the users and roles populate from that source, and if you leave it open you can still connect to port 8000 and log in with LDAP credentials. Coming in through the proxy on port 443 uses SAML authentication and automatically logs you in to Splunk.

For my setup I disabled SSL on SplunkWeb and am letting the Apache proxy handle it. I believe it's possible to leave it enabled if you want; just takes a little more work to get mod_proxy to connect to an https backend.

On the splunk side, I put this in server.conf:

[general]
trustedIP = 127.0.0.1

and web.conf:

[settings]
SSOMode = permissive
trustedIP = 127.0.0.1
remoteUser = X-Remote-User

You could also use SSOMode=strict to disable the ability to log in via LDAP username/password on port 8000.

I configured the IDP to send userPrincipalName as a persistent name identifier, as that's what we're using as the Splunk username. Shibboleth's default attribute-map.xml needs to be modified to change the persistent-id decoders from "$NameQualifier!$SPNameQualifier!$Name" to just "$Name". The usual setup of shibboleth2.xml needs to be done to configure it to talk to the IDP.

On the Apache side, I put this in my <VirtualHost _default_:443> section:

ProxyPreserveHost On
ShibURLScheme https

<Location />
        AuthType shibboleth
        ShibRequestSetting requireSession 1
        Require shib-session

        RequestHeader unset X-Remote-User
        RequestHeader set X-Remote-User %{REMOTE_USER}s
        ProxyPass "http://localhost:8000/"
</Location>

<Location /Shibboleth.sso>
        AuthType None
        Require all granted
        ProxyPass !
</Location>

<Location /shibboleth-sp>
        AuthType None
        Require all granted
        ProxyPass !
</Location>

The "RequestHeader unset" bit may be overkill as RequestHeader set will remove any existing headers a sneaky client may try to send, but I'd rather be paranoid in case there is some corner case where REMOTE_USER isn't set.

So far it seems to just work.

[tlmayes]

Interested in how you were able to achieve both SSO and LDAP. Currently have LDAP working and integrated with Splunk roles, all defined in Splunk Authentication/Authorization.conf. Have one production server working with SSO, Ping Identity as the IDP, controlling access to the Splunk WFE. The challenge is that our IDP solution administratively allow only (2) roles so restricted to Splunk Admin, & Splunk Users. Extremely limiting.

Any help on how I might be able to leverage both LDAP (for authorization/roles) and the IDP (for authentication) would be appreciated, knowing that our IDP solution is administratively very limited.

[tlmayes]

Read through the docs (and several others) regarding dual use of SAML & LDAP, which all require offloading of SAML to the proxy/load balancer. Is either of your setups protecting the management servers as well with SSO using the same reverse proxy, or are you addressing only the SHC? Our target at this point are our management servers, and will later address our SHC. Interested in hearing more.

[cboston]

We're currently not doing it for the management server, but the same setup would work for that as well. Would just need to set it up as a separate relying party.

Are you currently using the same load balancer for the management servers as for the search heads? I thought most people kept those separate. If so, how do you have it set up?

If you only have independent single servers for management, the easiest way is to just install Apache on the server itself and proxy to localhost. Otherwise you'd insert it at the same point in the chain that your load balancer lives. Or if you're using a fancy enough load balancer (F5 for instance), you could do the SAML/header proxying there.

[elliotproebstel]

I have done exactly this (Apache/Shibboleth in front of Splunk) for a large enterprise deployment. If you run into issues, I can probably help out.

[cboston]

It actually turned out to be really easy -- have it working already. 🙂

About to write up some details for the thread.