<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SSO sometimes fails with &amp;quot;deeper&amp;quot; URLs in Security</title>
    <link>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81773#M2726</link>
    <description>&lt;P&gt;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)&lt;/P&gt;</description>
    <pubDate>Wed, 04 Sep 2013 07:28:21 GMT</pubDate>
    <dc:creator>wsw70</dc:creator>
    <dc:date>2013-09-04T07:28:21Z</dc:date>
    <item>
      <title>SSO sometimes fails with "deeper" URLs</title>
      <link>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81771#M2724</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;

&lt;P&gt;I am trying to troubleshoot an SSO issue with "deep" URLs.&lt;BR /&gt;
SSO is configured with a reverse proxy which handles the CAS authentication via &lt;CODE&gt;auth_mod_cas&lt;/CODE&gt; on Apache. It usually works.&lt;/P&gt;

&lt;P&gt;I noticed that if the session gets stale I can recover by refreshing the home page of my splunk installation. &lt;/P&gt;

&lt;P&gt;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.&lt;/P&gt;

&lt;P&gt;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?&lt;/P&gt;

&lt;P&gt;Thank you for any pointers, hopefully this is not a bug but a misconfiguration on my side.&lt;/P&gt;

&lt;H3&gt;Apache configuration&lt;/H3&gt;

&lt;P&gt;&lt;EM&gt;All instances of "&amp;lt;" or "&amp;gt;" are replaced by respectively "[" and "]" since they are interpreted by the forum engine&lt;/EM&gt;&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[VirtualHost splunk.example.com:80]
ServerName splunk.example.com
DocumentRoot /var/www   
CASCookiePath /var/cache/apache2/mod_auth_cas/
CASLoginURL &lt;A href="https://cas.example.com/cas/login?gateway=true" target="test_blank"&gt;https://cas.example.com/cas/login?gateway=true&lt;/A&gt;
CASValidateURL  &lt;A href="https://cas.example.com/cas/proxyValidate" target="test_blank"&gt;https://cas.example.com/cas/proxyValidate&lt;/A&gt;
[Location /]
        Authtype CAS
        require valid-user
        CASAuthNHeader Cas-User
[/Location]
ProxyPreserveHost On
ProxyPass        / &lt;A href="http://localhost:8000/" target="test_blank"&gt;http://localhost:8000/&lt;/A&gt;
ProxyPassReverse / &lt;A href="http://localhost:8000/" target="test_blank"&gt;http://localhost:8000/&lt;/A&gt;
[/VirtualHost]
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;H3&gt;splunk's web.conf&lt;/H3&gt;

&lt;PRE&gt;&lt;CODE&gt;SSOMode = strict
trustedIP = 127.0.0.1
remoteUser = Cas-User
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;&lt;CODE&gt;server.conf&lt;/CODE&gt; has a &lt;CODE&gt;trustedIP=127.0.0.1&lt;/CODE&gt; line&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;UPDATE&lt;/STRONG&gt;: in case if someone finds this issue: it is still under review by the splunk dev team (looks like a complicated bug)&lt;/P&gt;</description>
      <pubDate>Tue, 02 Apr 2013 09:22:38 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81771#M2724</guid>
      <dc:creator>wsw70</dc:creator>
      <dc:date>2013-04-02T09:22:38Z</dc:date>
    </item>
    <item>
      <title>Re: SSO sometimes fails with "deeper" URLs</title>
      <link>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81772#M2725</link>
      <description>&lt;P&gt;Were you able to resolve this?&lt;/P&gt;

&lt;P&gt;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".&lt;/P&gt;

&lt;P&gt;My CAS settings are slightly different and I am using CAS 3.3.5:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;CASLoginURL &lt;A href="https://sso.example.com/cas/login" target="test_blank"&gt;https://sso.example.com/cas/login&lt;/A&gt;
CASValidateURL &lt;A href="https://sso.example.com/cas/serviceValidate" target="test_blank"&gt;https://sso.example.com/cas/serviceValidate&lt;/A&gt;
CASProxyValidateURL &lt;A href="https://sso.example.com/cas/proxyValidate" target="test_blank"&gt;https://sso.example.com/cas/proxyValidate&lt;/A&gt;
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;The &lt;CODE&gt;?gateway=true&lt;/CODE&gt; part of your &lt;CODE&gt;CASLoginURL&lt;/CODE&gt; is odd; from what I can tell, it is this:  &lt;A href="https://wiki.jasig.org/display/CAS/Using+CAS+without+the+CAS+login+screen"&gt;https://wiki.jasig.org/display/CAS/Using+CAS+without+the+CAS+login+screen&lt;/A&gt; 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 &lt;CODE&gt;proxyValidate&lt;/CODE&gt; URL instead of the &lt;CODE&gt;serviceValidate&lt;/CODE&gt; URL.&lt;/P&gt;</description>
      <pubDate>Tue, 03 Sep 2013 18:05:44 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81772#M2725</guid>
      <dc:creator>Wilcooley</dc:creator>
      <dc:date>2013-09-03T18:05:44Z</dc:date>
    </item>
    <item>
      <title>Re: SSO sometimes fails with "deeper" URLs</title>
      <link>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81773#M2726</link>
      <description>&lt;P&gt;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)&lt;/P&gt;</description>
      <pubDate>Wed, 04 Sep 2013 07:28:21 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81773#M2726</guid>
      <dc:creator>wsw70</dc:creator>
      <dc:date>2013-09-04T07:28:21Z</dc:date>
    </item>
    <item>
      <title>Re: SSO sometimes fails with "deeper" URLs</title>
      <link>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81774#M2727</link>
      <description>&lt;P&gt;Follow up: Setting &lt;STRONG&gt;&lt;CODE&gt;CASScope&lt;/CODE&gt;&lt;/STRONG&gt; in the virtual host &lt;STRONG&gt;&lt;CODE&gt;Location&lt;/CODE&gt;&lt;/STRONG&gt; section to &lt;STRONG&gt;"&lt;CODE&gt;/&lt;/CODE&gt;"&lt;/STRONG&gt; seems to have fixed this issue for me:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;
    &amp;lt;Location /&amp;gt;
      ...
      AuthType Cas
      CASScope /
      ...
    &amp;lt;/Location&amp;gt;
&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Mon, 17 Mar 2014 17:21:23 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Security/SSO-sometimes-fails-with-quot-deeper-quot-URLs/m-p/81774#M2727</guid>
      <dc:creator>Wilcooley</dc:creator>
      <dc:date>2014-03-17T17:21:23Z</dc:date>
    </item>
  </channel>
</rss>

