Why is SSP detecting POST and HTTP and returning an HTML page with code 303?

[SSP Tyro]

Hello--

I'm working on a web app that uses SSP configured as an SP.

The app is being developed in the Zend framework.

The client has the IdP.

I can authenticate initially and everything works as expected.

But once the default-sp session expires (90 secs), when I try to access a

resource, the browser gets a 303.

The 303 is generated by the Utilities.php file that looks for the

following condition:

if($_SERVER['SERVER_PROTOCOL'] === 'HTTP/1.1' &&

$_SERVER['REQUEST_METHOD'] === 'POST') {

When this condition is encountered, SSP generates a simple

web page with a redirect link.

The event path seems to be this:

1) the client tries to access a resource.

2) SSP redirects the client to the login page.

3) client authenticates.

4) client tries to access a controller via AJAX.

5) the controller uses curl to call a web-service.

6) the web-service returns a JSON object.

7) the controller returns an HTML string to the AJAX call in the client.

8) the client displays the HTML.

9) the world sings and is happy.

10) default-sp session expires.

11) client tries to access a controller via AJAX.

12) SSP tries to redirect to the login page, but hangs and reports a 303.

As far as I can tell, everything I'm doing is HTTPS.    How can it be that the protocol is HTTP?  In fact, the same call will succeed and then (after about 90 seconds) fail with a 303.

I dumped the $_SERVER variable in php.  It looks like this:

(

    [REDIRECT_HTTPS] => on

    [REDIRECT_SSL_TLS_SNI] => xxx.yyy.com

    [REDIRECT_STATUS] => 200

    [HTTPS] => on

    [SSL_TLS_SNI] => xxx.yyy.com

    [HTTP_HOST] => xxx.yyy.com

    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0

    [HTTP_ACCEPT] => */*

    [HTTP_ACCEPT_LANGUAGE] => en-US,en;q=0.5

    [HTTP_ACCEPT_ENCODING] => gzip, deflate

    [CONTENT_TYPE] => application/x-www-form-urlencoded; charset=UTF-8

    [HTTP_X_REQUESTED_WITH] => XMLHttpRequest

    [HTTP_REFERER] => https://xxx.yyy.com/c-i

    [CONTENT_LENGTH] => 13

    [HTTP_COOKIE] => PHPSESSID=1235b33356639297c6eaed04faa0e26a; SimpleSAMLAuthToken=_12358f74131b28fca78c1906a06ea01f75e87a84d5

    [HTTP_CONNECTION] => keep-alive

    [HTTP_PRAGMA] => no-cache

    [HTTP_CACHE_CONTROL] => no-cache

    [PATH] => /sbin:/usr/sbin:/bin:/usr/bin

    [SERVER_SIGNATURE] => 

    [SERVER_SOFTWARE] => Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.1c PHP/5.4.12

    [SERVER_NAME] => xxx.yyy.com

    [SERVER_ADDR] => 10.10.3.51

    [SERVER_PORT] => 443

    [REMOTE_ADDR] => 10.10.1.39

    [DOCUMENT_ROOT] => /my/root/htdocs/public

    [SERVER_ADMIN] => ad...@admin.com

    [SCRIPT_FILENAME] => /my/root/htdocs/public/index.php

    [REMOTE_PORT] => 58522

    [REDIRECT_URL] => /c-i/f-i/

    [GATEWAY_INTERFACE] => CGI/1.1

    [SERVER_PROTOCOL] => HTTP/1.1

    [REQUEST_METHOD] => POST

    [QUERY_STRING] => 

    [REQUEST_URI] => /c-i/f-i/

    [SCRIPT_NAME] => /index.php

    [PHP_SELF] => /index.php

    [REQUEST_TIME_FLOAT] => 1373919762.78

    [REQUEST_TIME] => 1373919762

    [argv] => Array

        (

        )

    [argc] => 0

)

I checked my SSP log for the same transaction and found this:

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] Session: 'default-sp' not valid because it is expired.

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] Saved state: '_696a5a35f4dbba6d89f3daa52dee014963a1dbd45c'

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] Sending SAML 2 AuthnRequest to 'https://client.idp.com'

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] Sending message:

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_696a5a35f4dbba6d89f3daa52dee014963a1dbd45c" Version="2.0" IssueInstant="2013-07-15T20:22:42Z" Destination="https://client.idp.com/saml2sso" AssertionConsumerServiceURL="https://xxx.yyy.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45]   <saml:Issuer>https://xxx.yyy.com</saml:Issuer>

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45]   <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"/>

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] </samlp:AuthnRequest>

Jul 15 16:22:42 simplesamlphp DEBUG [fdbed45d45] Redirect to 801 byte URL: https://client.ipd.com/saml2sso?SAMLRequest=fVJLb9swDP4rhu5%2BJs4WIQmQNhgWoOuCJt1hl4K26FiYLKmi1G7%2Ffoq9Yd2hOREgvwf5gSuCQVm%2BDb7XD%2FgckHzyc1Ca%2BDhYs%2BA0N0CSuIYBifuWH7df7niVFdw6401rFHtDuc4AInReGs2S%2FW7NnhbLBdQwq7u5aBpYiI%2FLbiYA6kogFuV8uZhBKRoxr1uWfENHkblmUSjSiQLuNXnQPraKcpYWH9KyPlUFryo%2Br76zZBevkRr8yOq9t8TzXAqbCq8h9XGaPUPWOZTn3iup0WWtGXLoulds4qIvskXKbWiUbPPLcRWRYcn27xG3RlMY0B0n6OPD3T%2Bbi0Ufmsz3Uv9owZ3NqE1ysAovWvlgRFCY2d6O2jlNtUqhpbErsIOgfEqWJYc%2FUd9ILaQ%2BX0%2B5mUDEP59Oh%2FTw9Xhim9VFm4%2Bpuc31JVf5W%2Bxq%2BpD76LLfHUyM4lfyybgB%2FPtLlFk5dqRIuxHKgyaLrewkihigUub11iF4XDPvArJ8M5n%2B%2F4mb3w%3D%3D&RelayState=https%3A%2F%2Fxxx.yyy.com%2Fsimplesaml%2Fmodule.php%2Fcore%2Fpostredirect.php%3FRedirId%3D_0997b56794cf2952c68edb0c75520d6fe3e6fc0261

I've checked my controllers to make sure I don't have any stray blank lines that would make the headers choke.

Can anyone point me in the right direction for resolving this?

Thanks--

SSP Tyro

[Jaime Pérez Crespo]

Hi,

On Jul 15, 2013, at 23:36 PM, SSP Tyro <hub.c...@gmail.com> wrote:

Hello--

I'm working on a web app that uses SSP configured as an SP.

The app is being developed in the Zend framework.

The client has the IdP.

I can authenticate initially and everything works as expected.

But once the default-sp session expires (90 secs), when I try to access a

resource, the browser gets a 303.

Why setting the session so short?

The 303 is generated by the Utilities.php file that looks for the

following condition:

if($_SERVER['SERVER_PROTOCOL'] === 'HTTP/1.1' &&

$_SERVER['REQUEST_METHOD'] === 'POST') {

That's standard behavior. HTTP 303 appears in HTTP/1.1 and is suitable to redirect a client when the request is a POST, hence both checks.

When this condition is encountered, SSP generates a simple

web page with a redirect link.

The event path seems to be this:

1) the client tries to access a resource.

2) SSP redirects the client to the login page.

3) client authenticates.

4) client tries to access a controller via AJAX.

5) the controller uses curl to call a web-service.

6) the web-service returns a JSON object.

7) the controller returns an HTML string to the AJAX call in the client.

8) the client displays the HTML.

9) the world sings and is happy.

10) default-sp session expires.

11) client tries to access a controller via AJAX.

12) SSP tries to redirect to the login page, but hangs and reports a 303.

What does it mean "hangs and reports a 303"? A HTTP 303 status code is a redirection with a Location header. Therefore, the browser should redirect to the value contained in that header, but never "hang and report".

As far as I can tell, everything I'm doing is HTTPS.    How can it be that the protocol is HTTP?  In fact, the same call will succeed and then (after about 90 seconds) fail with a 303.

Indeed, there's nothing indicating that you are using plain HTTP. If you say that because of the previous code that generates the 303, bear in mind that the check is for the _version_ of HTTP, not whether it is secured inside SSL/TLS or not.

I dumped the $_SERVER variable in php.  It looks like this:

(

    [REDIRECT_HTTPS] => on

See? Your requests are HTTPS, which has nothing to do with the version of HTTP, which is what SSP verifies. All modern browsers use 1.1.

Everything looks correct. Your session is expired, therefore you need to go to the IdP to renew it (or re-authenticate the user, if the session in the IdP expired too). 

I've checked my controllers to make sure I don't have any stray blank lines that would make the headers choke.

Can anyone point me in the right direction for resolving this?

My advise is to use firefox + SAML tracer extension or something analogous, capture all the messages required to login (fresh start, no cookies) and to trigger the error, save them to a file, and go through them to see the responses from SSP and why the browser is not following the redirection. My impression is that your problem is related to the use of AJAX on resources unnecessarily protected by SSP. Maybe you should manually capture the redirection and force a refresh of the page when that happens. And, of course, raise the session time. 90 secs is just too short.

--

Jaime Pérez

UNINETT / Feide

mail: jaime...@uninett.no

xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[SSP Tyro]

Jaime--

Thanks for your reply.  I've interspersed responses below.

But once the default-sp session expires (90 secs), when I try to access a

resource, the browser gets a 303.

Why setting the session so short?

I did not modify any timeout settings.  I say the session expires in 90 seconds based only on my testing.  If there's a way to lengthen that timeout, that's fine.  But I did not change any default timeouts.  This is simply the behavior I'm observing.

 

The 303 is generated by the Utilities.php file that looks for the

following condition:

if($_SERVER['SERVER_PROTOCOL'] === 'HTTP/1.1' &&

$_SERVER['REQUEST_METHOD'] === 'POST') {

That's standard behavior. HTTP 303 appears in HTTP/1.1 and is suitable to redirect a client when the request is a POST, hence both checks.

The problem is that the redirect isn't actually happening.

What does it mean "hangs and reports a 303"? A HTTP 303 status code is a redirection with a Location header. Therefore, the browser should redirect to the value contained in that header, but never "hang and report".

## Correct.  I expect it to redirect, but it doesn't.

 

Indeed, there's nothing indicating that you are using plain HTTP. If you say that because of the previous code that generates the 303, bear in mind that the check is for the _version_ of HTTP, not whether it is secured inside SSL/TLS or not.

## Thanks for pointing this out.  That makes sense.

 

Everything looks correct. Your session is expired, therefore you need to go to the IdP to renew it (or re-authenticate the user, if the session in the IdP expired too). 

## Correct.  It seems though that when it tries to go to the IdP, a 303 is reported and further processing stops.

 

My advise is to use firefox + SAML tracer extension or something analogous, capture all the messages required to login (fresh start, no cookies) and to trigger the error, save them to a file, and go through them to see the responses from SSP and why the browser is not following the redirection.

Thanks for pointing this tool out.

POST https://xxx.yyy.com/c-i/f-i/ HTTP/1.1
Host: xxx.yyy.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://xxx.yyy.com/c-i
Content-Length: 13
Cookie: PHPSESSID=23f5b33356639297c6eaed04faa0e26a; SimpleSAMLAuthToken=_604ef0009fa0e991de803b11a42881815711246612

HTTP/?.? 303 See Other
Date: Tue, 16 Jul 2013 13:47:42 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.1c PHP/5.4.12
X-Powered-By: PHP/5.4.12
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Location: https://client.idp.com/saml2sso?SAMLRequest=123Lj9MwEP4rke95tkqK1VYqWyEqLVBtC4e9rBx73Fg4ttdjs%2FDvcZNFLAd6Gmnme8x8mjWyUTu6i2EwD%2FAcAUP2c9QG6TTYkOgNtQwVUsNGQBo4Pe0%2B3dOmqKjzNlhuNXlDuc1giOCDsoZkh%2F2GPLVysRJctvwd62HVNaLqG7ashaialey7FetWTdO1C9mS7Bt4TMwNSUKJjhjhYDAwE1Krqhd51eV1e64XdNnRZfNIsn26RhkWJtYQgkNalkq4XATD8pCmxTMrpAd1GYJWBnzB7VgyKV%2BgT4v%2BUBywdLHXipfX4xpES7LdnyPurME4gj%2FN0K8P939trhZD7IswKPOdM3%2Bxkzaq0Wm4apWjFVFD4QY3aZc41yZnHKeuAMmiDjk6kh1fo36vjFDmcjvlfgYh%2FXg%2BH%2FPjl9OZbNdXbTql5re3l1yXb7Hr%2BUM%2BJ5fD%2FmhTFL%2ByD9aPLPx%2Fibqop44SuZygNBp0wJVUIFKAWtuXOw8swIYEH4GU29n030%2Fc%2FgY%3D&RelayState=https%3A%2F%2Fxxx.yyy.com%2Fsimplesaml%2Fmodule.php%2Fcore%2Fpostredirect.php%3FRedirId%3D_b88dca1eafd2c27648d6641ab8b05e418ca25f2a23
Content-Length: 2946
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

The request decodes to this:

<samlp:AuthnRequest 
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
  ID="_6f38dcf6c9abe872d0b2a41dd028fb78a7822763f6" 

  Version="2.0" 
  IssueInstant="2013-07-16T13:47:42Z" 
  Destination="https://client.idp.com/saml2sso"
  AssertionConsumerServiceURL="https://xxx.yyy.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">

  <saml:Issuer>

    https://xxx.yyy.com</saml:Issuer><samlp:NameIDPolicy   

    Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" 
    AllowCreate="true"/>

</samlp:AuthnRequest>

 

When I get this 303 response, the browser does not redirect.  

It just sits around smoking a cigarette and asking for another beer.

 

My impression is that your problem is related to the use of AJAX on resources unnecessarily protected by SSP.

It is currently the case that every resource is protected by SSP.  Thus, any time a user tries to access a resource (directly or by AJAX), we check his session.  In what case would resources not be protected on a site for which every resource should only be accessible to users who have authenticated through SAML?

 

Maybe you should manually capture the redirection and force a refresh of the page when that happens.

And, of course, raise the session time. 90 secs is just too short.

I agree, but I didn't change any defaults.  The 90 secs that I reported is based on my observations in using the system and reviewing the logs.

[Daniel Tsosie]

If your timeout is occurring earlier than configured, it is more likely an issue with your session store. If you have any other apps sharing your session store (file dir location or memcache instance) I'd investigate those first.

-Dan Tsosie

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jaime Pérez Crespo]

Hi again,

On Jul 16, 2013, at 16:38 PM, SSP Tyro <hub.c...@gmail.com> wrote:

Why setting the session so short?

I did not modify any timeout settings.  I say the session expires in 90 seconds based only on my testing.  If there's a way to lengthen that timeout, that's fine.  But I did not change any default timeouts.  This is simply the behavior I'm observing.

That's strange. I think by default the cookies are configured as session cookies, which means the session does not end until you close your browser. Can you take a look into the config.php and see if these 90 secs are coming from some option there?

Everything looks correct. Your session is expired, therefore you need to go to the IdP to renew it (or re-authenticate the user, if the session in the IdP expired too). 

## Correct.  It seems though that when it tries to go to the IdP, a 303 is reported and further processing stops.

When you say "processing", you mean some javascript/AJAX code, or the browser? I see no reason why a browser should not follow a 303 redirection, _but_, if the request is made by a script, that might change things a bit.

POST https://xxx.yyy.com/c-i/f-i/ HTTP/1.1

Host: xxx.yyy.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://xxx.yyy.com/c-i
Content-Length: 13
Cookie: PHPSESSID=23f5b33356639297c6eaed04faa0e26a; SimpleSAMLAuthToken=_604ef0009fa0e991de803b11a42881815711246612

HTTP/?.? 303 See Other

You didn't modify the HTTP version number, did you? Could you somehow verify if you are actually receiving that "HTTP/?.?" string? That sounds like a source of problems. But honestly, I have no idea on where that problem could come from...

Date: Tue, 16 Jul 2013 13:47:42 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.1c PHP/5.4.12
X-Powered-By: PHP/5.4.12
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Location: https://client.idp.com/saml2sso?SAMLRequest=123Lj9MwEP4rke95tkqK1VYqWyEqLVBtC4e9rBx73Fg4ttdjs%2FDvcZNFLAd6Gmnme8x8mjWyUTu6i2EwD%2FAcAUP2c9QG6TTYkOgNtQwVUsNGQBo4Pe0%2B3dOmqKjzNlhuNXlDuc1giOCDsoZkh%2F2GPLVysRJctvwd62HVNaLqG7ashaialey7FetWTdO1C9mS7Bt4TMwNSUKJjhjhYDAwE1Krqhd51eV1e64XdNnRZfNIsn26RhkWJtYQgkNalkq4XATD8pCmxTMrpAd1GYJWBnzB7VgyKV%2BgT4v%2BUBywdLHXipfX4xpES7LdnyPurME4gj%2FN0K8P939trhZD7IswKPOdM3%2Bxkzaq0Wm4apWjFVFD4QY3aZc41yZnHKeuAMmiDjk6kh1fo36vjFDmcjvlfgYh%2FXg%2BH%2FPjl9OZbNdXbTql5re3l1yXb7Hr%2BUM%2BJ5fD%2FmhTFL%2ByD9aPLPx%2Fibqop44SuZygNBp0wJVUIFKAWtuXOw8swIYEH4GU29n030%2Fc%2FgY%3D&RelayState=https%3A%2F%2Fxxx.yyy.com%2Fsimplesaml%2Fmodule.php%2Fcore%2Fpostredirect.php%3FRedirId%3D_b88dca1eafd2c27648d6641ab8b05e418ca25f2a23
Content-Length: 2946
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Except for the problem in the status line, at first sight everything looks fine. The expiration date is weird though (1981?), but I guess it might be related to cache-control?

The request decodes to this:

<samlp:AuthnRequest 
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
  ID="_6f38dcf6c9abe872d0b2a41dd028fb78a7822763f6" 

  Version="2.0" 
  IssueInstant="2013-07-16T13:47:42Z" 
  Destination="https://client.idp.com/saml2sso"
  AssertionConsumerServiceURL="https://xxx.yyy.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">

  <saml:Issuer>

    https://xxx.yyy.com</saml:Issuer><samlp:NameIDPolicy   

    Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" 
    AllowCreate="true"/>

</samlp:AuthnRequest>

Looks good too.

When I get this 303 response, the browser does not redirect.  

It just sits around smoking a cigarette and asking for another beer.

Not even willing to share the beer? :-)

Is it doing exactly nothing? Or is it trying to load something (unsuccessfully)?

My impression is that your problem is related to the use of AJAX on resources unnecessarily protected by SSP.

It is currently the case that every resource is protected by SSP.  Thus, any time a user tries to access a resource (directly or by AJAX), we check his session.  In what case would resources not be protected on a site for which every resource should only be accessible to users who have authenticated through SAML?

Well, I was thinking that you might be using your own sessions. If you are not handling sessions at all, delegating that to SSP, then that's fine. Anyway, I still think that your problem is related to AJAX. It might be that AJAX calls are not following the redirection, or it might be that they are following them, but they reach a 200 OK without the data they are expecting. Are you printing what you get with AJAX directly to the browser? Or are you expecting some data to be processed and then converted into HTML to display to the user?

And, of course, raise the session time. 90 secs is just too short.

I agree, but I didn't change any defaults.  The 90 secs that I reported is based on my observations in using the system and reviewing the logs.

Check the config. If the config is fine, then there's a problem somewhere causing your sessions to die after 90 secs, which is pretty strange...

[Jaime Pérez Crespo]

On Jul 16, 2013, at 18:06 PM, Jaime Pérez Crespo <jaime...@uninett.no> wrote:

HTTP/?.? 303 See Other

You didn't modify the HTTP version number, did you? Could you somehow verify if you are actually receiving that "HTTP/?.?" string? That sounds like a source of problems. But honestly, I have no idea on where that problem could come from...

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Except for the problem in the status line, at first sight everything looks fine. The expiration date is weird though (1981?), but I guess it might be related to cache-control?

My fault, I've just realized that both things are standard output produced by SAML tracer, which doesn't sound normal to me, so I'm putting that into my ToDo list.

Sorry for the noise.

[Olav Morken]

On Tue, Jul 16, 2013 at 18:06:22 +0200, Jaime P�rez Crespo wrote:
> Well, I was thinking that you might be using your own sessions. If you are not handling sessions at all, delegating that to SSP, then that's fine. Anyway, I still think that your problem is related to AJAX. It might be that AJAX calls are not following the redirection, or it might be that they are following them, but they reach a 200 OK without the data they are expecting. Are you printing what you get with AJAX directly to the browser? Or are you expecting some data to be processed and then converted into HTML to display to the user?

Hi,

just to jump into the discussion here. The reason is almost certainly
the AJAX requests. When your SP sends a redirect to the IdP in response
to an AJAX request, it is trying to make the browser send an AJAX
request to a third-party site (the IdP). This runs afoul of the
browsers security model (same-origin restrictions), so the browser
won't follow the redirect.

I'd suggest replacing any requireAuth()-calls in the AJAX endpoints with
isAuthenticated()-calls, and returning an error instead when the user
is logged out. You could then handle that from javascript, e.g. by
redirecting the browser the the IdP properly, or by displaying a
message to the user saying that the user is logged out, and giving them
a login link that they can follow to log back in.

Best regards,
Olav Morken
UNINETT / Feide