Security

SSO sometimes fails with "deeper" URLs

wsw70
Communicator

Hello,

I am trying to troubleshoot an SSO issue with "deep" URLs.
SSO is configured with a reverse proxy which handles the CAS authentication via auth_mod_cas on Apache. It usually works.

I noticed that if the session gets stale I can recover by refreshing the home page of my splunk installation.

If, however, I try instead to directly access a deeper url (specific results of a search for instance) I get an empty result page (the splunk chrome is there but the contents are empty). If I then navigate to the home page and come back to my "deeper" URL the results are displayed fine.

This looks like a SSO issue but I fail to pinpoint the root cause -- it might be the reverse proxy (configuration below) but in that case why only some URLs are problematic?

Thank you for any pointers, hopefully this is not a bug but a misconfiguration on my side.

Apache configuration

All instances of "<" or ">" are replaced by respectively "[" and "]" since they are interpreted by the forum engine

[VirtualHost splunk.example.com:80]
ServerName splunk.example.com
DocumentRoot /var/www   
CASCookiePath /var/cache/apache2/mod_auth_cas/
CASLoginURL https://cas.example.com/cas/login?gateway=true
CASValidateURL  https://cas.example.com/cas/proxyValidate
[Location /]
        Authtype CAS
        require valid-user
        CASAuthNHeader Cas-User
[/Location]
ProxyPreserveHost On
ProxyPass        / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
[/VirtualHost]

splunk's web.conf

SSOMode = strict
trustedIP = 127.0.0.1
remoteUser = Cas-User

server.conf has a trustedIP=127.0.0.1 line

UPDATE: in case if someone finds this issue: it is still under review by the splunk dev team (looks like a complicated bug)

Tags (1)

Wilcooley
Path Finder

Follow up: Setting CASScope in the virtual host Location section to "/" seems to have fixed this issue for me:


    <Location />
      ...
      AuthType Cas
      CASScope /
      ...
    </Location>
0 Karma

Wilcooley
Path Finder

Were you able to resolve this?

I am seeing basically the same problem that you have described, also using CAS for SSO. Deep links, such as a bookmark to a view or dashboard will sometimes not work. It seems to affect people who only look at the deep link; I usually do not see it myself, unless it's my first time hitting splunkweb since a browser restart or something -- I usually do not see it, in fact, because I usually hit the root path and get bounced through language detection into "search/flashtimeline", which is what I assume you mean by "the home page".

My CAS settings are slightly different and I am using CAS 3.3.5:

CASLoginURL https://sso.example.com/cas/login
CASValidateURL https://sso.example.com/cas/serviceValidate
CASProxyValidateURL https://sso.example.com/cas/proxyValidate

The ?gateway=true part of your CASLoginURL is odd; from what I can tell, it is this: https://wiki.jasig.org/display/CAS/Using+CAS+without+the+CAS+login+screen which were I not having the same problem seems like it could be part of the problem. I am also unclear why you've used the proxyValidate URL instead of the serviceValidate URL.

0 Karma

wsw70
Communicator

Thanks for your input. I worked out the CAS URLs with our SSO team but I will modify them to see if it helps. The SSO itself works fine (you exactly reproduce my scenario). I opened a ticket with splunk and the resolution is on its way (hopefully :)) -- the first hint being an issue with the caching mechanism (to be confirmed)

0 Karma
Get Updates on the Splunk Community!

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...