What's the difference between authentication using ProxySSO and authentication using SSO with reverse proxy?
They sound similar and even the configurations look similar.
Authentication using Proxy SSO: https://docs.splunk.com/Documentation/Splunk/latest/Security/AboutProxySSO
Authentication using single sign-on with reverse proxy: https://docs.splunk.com/Documentation/Splunk/latest/Security/HowSplunkSSOworks
The ProxySSO doc appears to be a method that uses LDAP responses to your proxy in order to set the user & group information in splunk. Thereby removing the need for a LDAP configuration in authentication.conf to pull the groups.
The advantage is it takes the LDAP workload off of Splunk and puts it onto your proxy.
Whereas the reverse proxy method (traditional / original SSO method I helped some large entities pioneer), still relies on splunk to query LDAP to find the group that the user belongs to. Then splunk matches the ldap group to authorization settings to determine your user's RBAC settings.
Both methods are technically reverse-proxy SSO methods.
Wether you call it a reverse proxy or proxy really just implies the direction the user traffic is flowing. If your user is coming from somewhere internal going through a proxy to get to resources externally, we call that a proxy. If your user is coming from somewhere external through your proxy to your internal service, that's when we call it a reverse proxy.
There are other proxy methods too! You could pull the usernames and groups from a database, or a flat file, or you could dynamically generate them on the proxy based on any number of things (Apache as proxy can do just about anything, but you could also build your own proxy with nginx, haproxy, or even code your own using python or any other number languages that have proxy libraries).
You may wish to do the LDAP thing in splunk or do it on your proxy or like I said above, not even use LDAP.
The ProxySSO doc appears to be a method that uses LDAP responses to your proxy in order to set the user & group information in splunk. Thereby removing the need for a LDAP configuration in authentication.conf to pull the groups.
The advantage is it takes the LDAP workload off of Splunk and puts it onto your proxy.
Whereas the reverse proxy method (traditional / original SSO method I helped some large entities pioneer), still relies on splunk to query LDAP to find the group that the user belongs to. Then splunk matches the ldap group to authorization settings to determine your user's RBAC settings.
Both methods are technically reverse-proxy SSO methods.
Wether you call it a reverse proxy or proxy really just implies the direction the user traffic is flowing. If your user is coming from somewhere internal going through a proxy to get to resources externally, we call that a proxy. If your user is coming from somewhere external through your proxy to your internal service, that's when we call it a reverse proxy.
There are other proxy methods too! You could pull the usernames and groups from a database, or a flat file, or you could dynamically generate them on the proxy based on any number of things (Apache as proxy can do just about anything, but you could also build your own proxy with nginx, haproxy, or even code your own using python or any other number languages that have proxy libraries).
You may wish to do the LDAP thing in splunk or do it on your proxy or like I said above, not even use LDAP.
Thanks a lot! Your explanation is very clear.
My pleasure!