Return 401 on expired/missing session?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Return 401 on expired/missing session?

Peter Schober
For an application where the "frontend" is written in JavaScript and
running in the browser (accessing a server-based "backend" proteced
with mod_shib) we're having issues with the frontend code not being
able to detect that the Shib session has meanwhile expired:
All HTTP 30x codes returned are transparently followed by the JS code
(according to some XHR spec) and so far attempts at intercepting those
redirects in the JS framework used have failed.

Is there an easy way to have mod_shib (or httpd) return, say, HTTP 401
instead of a redirect to the IDP (or SAMLDS) in case where no valid
session exists?
Obviously that would leave people stuck but I guess we could let them
initiate a new session using the SP's Login handler (manually or in
this case via the "frontend" application that would detect this status
code and initate a new session automatically).

I feel I must be missing something obvious..

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Jim Fox

My experience is that the 302 redirect is followed, but considered a
cross-site redirect error by the idp.  This causes a final response code
of zero, not 200 or 302.  I detect the zero response code to mean the user
has to reauthenticate.

Jim

On Mon, 9 Apr 2018, Peter Schober wrote:

> Date: Mon, 9 Apr 2018 11:01:27
> From: Peter Schober <[hidden email]>
> To: [hidden email]
> Reply-To: Shib Users <[hidden email]>
> Subject: Return 401 on expired/missing session?
>
> For an application where the "frontend" is written in JavaScript and
> running in the browser (accessing a server-based "backend" proteced
> with mod_shib) we're having issues with the frontend code not being
> able to detect that the Shib session has meanwhile expired:
> All HTTP 30x codes returned are transparently followed by the JS code
> (according to some XHR spec) and so far attempts at intercepting those
> redirects in the JS framework used have failed.
>
> Is there an easy way to have mod_shib (or httpd) return, say, HTTP 401
> instead of a redirect to the IDP (or SAMLDS) in case where no valid
> session exists?
> Obviously that would leave people stuck but I guess we could let them
> initiate a new session using the SP's Login handler (manually or in
> this case via the "frontend" application that would detect this status
> code and initate a new session automatically).
>
> I feel I must be missing something obvious..
>
> -peter
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to [hidden email]
>
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Return 401 on expired/missing session?

Cantor, Scott E.
In reply to this post by Peter Schober
> Is there an easy way to have mod_shib (or httpd) return, say, HTTP 401
> instead of a redirect to the IDP (or SAMLDS) in case where no valid session
> exists?

That's been left to the passive session feature, which leaves it up to the application. A passive session plus a static require rule would generally return a 403. That could probably be made more configurable as a response code vs. trying to bastardize what the requireSession feature does.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Peter Schober
In reply to this post by Jim Fox
* Jim Fox <[hidden email]> [2018-04-09 20:12]:
> My experience is that the 302 redirect is followed, but considered a
> cross-site redirect error by the idp.  This causes a final response
> code of zero, not 200 or 302.  I detect the zero response code to
> mean the user has to reauthenticate.

AFAIK in our case the JS in the browser silently (when one is not
checking the browser's JS console) fails with a CORS error due to the
redirect to the IDP (or rather from the next redirect within the IDP).

I guess one workaround would be not actively protecting the
application with shib, then lack of attributes sent in API responses
signals a need to refresh the session, but without confusing the JS
code with redirects meant for the browser...

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Peter Schober
In reply to this post by Jim Fox
* Jim Fox <[hidden email]> [2018-04-09 20:12]:
> My experience is that the 302 redirect is followed, but considered a
> cross-site redirect error by the idp.  This causes a final response code of
> zero, not 200 or 302.  I detect the zero response code to mean the user has
> to reauthenticate.

Ah, I think I see what you mean. After the IDP internal redirects
trigger the CORS error...

  Failed to load https://idp.example.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=...
  Redirect from
  'https://idp.example.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=...'
  to
  'https://idp.example.org/idp/profile/SAML2/Redirect/SSO;jsessionid=...?execution=e1s1'
  has been blocked by CORS policy: No 'Access-Control-Allow-Origin'
  header is present on the requested resource. Origin
  'https://sp.example.net' is therefore not allowed access.

I do seem to end up with a status code of zero due to "unknown error":

HttpErrorResponse {headers: HttpHeaders, status: 0, statusText: "Unknown Error", url: null, ok: false, …}

I'll pass this on to the developer, maybe we can work with this.

Thanks,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Peter Schober
In reply to this post by Cantor, Scott E.
* Cantor, Scott <[hidden email]> [2018-04-09 20:14]:
> > Is there an easy way to have mod_shib (or httpd) return, say, HTTP 401
> > instead of a redirect to the IDP (or SAMLDS) in case where no valid session
> > exists?
>
> That's been left to the passive session feature, which leaves it up
> to the application. A passive session plus a static require rule
> would generally return a 403. That could probably be made more
> configurable as a response code vs. trying to bastardize what the
> requireSession feature does.

Ah, you mean something like this?

  AuthType shibboleth
  ShibRequestSetting requireSession false
  Require shib-attr eppn ~ ^.+$

I always thought I can't have require rules when not enforcing
sessions? I.e., with passive protection any authorization would have
to be performed within the application?

Anyway, I now have active protection on / (for browser access) and the
above for /api (meant only for the JS to access) and that seems to
work fine: The browser establishes an SP session before even loading
the JS, the JS then accesses the /api just fine, once the shib session
expires the XHRs to /api will get HTTP 401 from the server.

Thanks Scott and Jim!

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Return 401 on expired/missing session?

Cantor, Scott E.
> I always thought I can't have require rules when not enforcing sessions? I.e.,
> with passive protection any authorization would have to be performed
> within the application?

You can, it's just usually not done because you'd obviously never get in, but if it's all intended to be programmatically controlled, that might be the outcome you want. But I believe it always returns 403 right now.

> Anyway, I now have active protection on / (for browser access) and the
> above for /api (meant only for the JS to access) and that seems to work fine:
> The browser establishes an SP session before even loading the JS, the JS
> then accesses the /api just fine, once the shib session expires the XHRs to
> /api will get HTTP 401 from the server.

I think the SP itself is just returning 403s on require failures.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Takeshi NISHIMURA
On 2018/04/10 4:38, Cantor, Scott wrote:
>> then accesses the /api just fine, once the shib session expires the XHRs to
>> /api will get HTTP 401 from the server.
> I think the SP itself is just returning 403s on require failures.

On CentOS 7 (Apache httpd 2.4) I always see "401 Unauthorized" instead of 403.

CentOS 6 returns 403 for sure.

Takeshi
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Return 401 on expired/missing session?

Cantor, Scott E.
> On CentOS 7 (Apache httpd 2.4) I always see "401 Unauthorized" instead of
> 403.
>
> CentOS 6 returns 403 for sure.

Is 6 running 2.4 also? I don't remember. Any inconsistency here is probably something Apache is doing, possibly some other layer steps in because of the 2.4 addition of stacking auth modules. The module just informs Apache of a require outcome, it doesn't actually control the response. The cases where an actual code come from the SP are the handlers (e.g. denying access to the status handler).

-- Scott
 
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Takeshi NISHIMURA
No, it is 2.2 on CentOS 6.

Furthermore, on 2.4, customizing that page using access="accessError.html" in <Errors> seems to be broken.
It is not a regression on SP 3.0 as 2.6.1 behaves identically.

Takeshi

> 2018/08/02 22:15, Cantor, Scott <[hidden email]> wrote:
>
>> On CentOS 7 (Apache httpd 2.4) I always see "401 Unauthorized" instead of
>> 403.
>>
>> CentOS 6 returns 403 for sure.
>
> Is 6 running 2.4 also? I don't remember. Any inconsistency here is probably something Apache is doing, possibly some other layer steps in because of the 2.4 addition of stacking auth modules. The module just informs Apache of a require outcome, it doesn't actually control the response. The cases where an actual code come from the SP are the handlers (e.g. denying access to the status handler).
>
> -- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Return 401 on expired/missing session?

Cantor, Scott E.
> No, it is 2.2 on CentOS 6.

That would account for the difference.

> Furthermore, on 2.4, customizing that page using access="accessError.html"
> in <Errors> seems to be broken.

It again has to do with the fact that it's not the SP itself actually responding with that status code, so it's not broken, it's just impossible to do it there, at least if you're talking about the require rules. If the status page or things like that aren't working the same way, then it's probably not intentional, or at least not understood why it changed. But I definitely know why the main authz logic is different in 2.4, the APIs are very different because of the module stacking support.

It's always better to do this in Apache anyway, most of those features were an IIS thing, and even IIS can do this better itself now.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Takeshi NISHIMURA
Thanks Scott. I remember.

On 2018/08/03 1:26, Cantor, Scott wrote:

>> No, it is 2.2 on CentOS 6.
>
> That would account for the difference.
>
>> Furthermore, on 2.4, customizing that page using access="accessError.html"
>> in <Errors> seems to be broken.
>
> It again has to do with the fact that it's not the SP itself actually responding with that status code, so it's not broken, it's just impossible to do it there, at least if you're talking about the require rules. If the status page or things like that aren't working the same way, then it's probably not intentional, or at least not understood why it changed. But I definitely know why the main authz logic is different in 2.4, the APIs are very different because of the module stacking support.
>
> It's always better to do this in Apache anyway, most of those features were an IIS thing, and even IIS can do this better itself now.
>
> -- Scott
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Return 401 on expired/missing session?

Peter Schober
In reply to this post by Takeshi NISHIMURA
* Takeshi NISHIMURA <[hidden email]> [2018-08-02 10:56]:
> On 2018/04/10 4:38, Cantor, Scott wrote:
> > > then accesses the /api just fine, once the shib session expires
> > > the XHRs to /api will get HTTP 401 from the server.
> >
> > I think the SP itself is just returning 403s on require failures.
>
> On CentOS 7 (Apache httpd 2.4) I always see "401 Unauthorized"
> instead of 403.

For the record, the 401 I got was on Debian stable, so httpd 2.4, too.
Since it was what I (or rather the devloper) expected it's all good.
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]