Re: [simplesamlphp-users] Exception on dp, handle it without an errorURL redirect?

[Jaime Pérez Crespo]

Hi Adam,

On 10 Mar 2020, at 14:24, Adam Wicks <ad...@ecancer.org> wrote:
> My main goal is to see if someone has a session at the idp without requiring auth. This is for public pages that may show the user they are logged in and some app specific details. The idp is the source of truth for auth.
>
> To do this I have used:
>
> $as->login([
> 'isPassive' => true,
> 'ErrorURL' => $thisPageURL
> ]);
>
> and a session variable to make sure the errorURL doesn't make an infinite loop.
>
> I don't want to use a redirect, for many reasons. It will depending on my session logic redirect on every page load until it is a requireAuth page! Or it will create other errors if I limit the redirects.

It’s not like you have much of a choice. SAML works in a way that redirects are absolutely necessary, so it’s not up to you to decide whether you use them or not. Of course there are mechanisms to limit those redirects, by communicating protocol messages in a back channel, but the user’s session resides in the web browser anyway, so at some point you *need* a redirect.

If the reason is that you don’t want to get redirected on every page load, then introduce a variable in your session to disable further checks, at least for a given amount of time (that is, cache the response you got in the first place). Not sure I understand what you mean by “limit the redirects”, but that’s not something you should/can do anyway.

Also, if you are using PHP sessions in your application, and you also use the PHP session handler in SimpleSAMLphp, make sure to close SSP’s session and reload yours in your application after returning from SSP’s API, as described in the documentation. Otherwise all your session information might be lost, as you could be saving it to SimpleSAMLphp’s session instead of your app’s.

> How do I catch this NoPassive exception on the SP, handle it by ignoring it, all on the same page? I could not find any documentation on this.

If you don’t care about the user not being authenticated and you just need to check in order to improve user experience or something like that, yes, you can just ignore it.

$loggedIn = false;
$attributes = [];
try {
$auth->login([‘isPassive’ => true]);
$loggedIn = true;
$attributes = $auth->getAttributes();
} catch (\Exception $e) {
}

--
Jaime Pérez
Uninett / Feide

PGP: 9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

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

[Adam Wicks]

Thank you for the reply,

Apologies for my poor wording of what I am doing. I have found this which is pretty much the same as my code: https://groups.google.com/d/msg/simplesamlphp/UsLdIPeeJiM/FQyQaTK1T3cJ

It's fair to say I don't care in this authentication check if the person is logged in or not and that it is only for improved user experience. If logged in via a different sp to our idp, the user will expect to arrive to this sp logged in. That includes this situation where the page they arrive on doesn't require auth to access but will show that they are logged in if they are.

I thought a try/catch would work but it doesn't. It will still throw the error to the browser. I figured I need to hook into the SP to change it's behaviour on this error but I don't know how to go about that.

Test page code:

require_once('/var/simplesamlphp/lib/_autoload.php');
$as = new SimpleSAML\Auth\Simple('sso-ssptestsp2');

$attributes = [];

try {
    $as->login(['isPassive' => true]);
    $attributes = $as->getAttributes();
} catch (\Exception $e) {
}

$session = \SimpleSAML\Session::getSessionFromRequest();
$session->cleanup();

The backtrace the sp puts to the browser:

Backtrace:
1 www/_include.php:17 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: SimpleSAML\Module\saml\Error\NoPassive: Responder/NoPassive: Passive authentication not supported.
Backtrace:
3 modules/saml/lib/Error.php:164 (SimpleSAML\Module\saml\Error::toException)
2 modules/saml/www/sp/saml2-acs.php:144 (require)
1 lib/SimpleSAML/Module.php:254 (SimpleSAML\Module::process)
0 www/module.php:10 (N/A)

[Peter Schober]

* Adam Wicks <ad...@ecancer.org> [2020-03-10 17:17]:

> It's fair to say I don't care in this authentication check if the
> person is logged in or not and that it is only for improved user
> experience. If logged in via a different sp to our idp, the user
> will expect to arrive to this sp logged in.

In a world with more than one SAML SP in it and where SPs may be
locally hosted or provided by third parties that's simply an
unreasonable expectation.
(Such things may be possible when *everything* is closely coupled with
one central system, but you're not Faceboogle so you're not going to
be that one system-to-rule-them-all in the middle. Neither should you
aspire to become that. SAML is decentralised for a reason.)

Every SAML entity has its own local sessions, independently from any
other SAML entities' sessions.

>> Backtrace:
> 1 www/_include.php:17 (SimpleSAML_exception_handler)
> 0 [builtin] (N/A)
> Caused by: SimpleSAML\Module\saml\Error\NoPassive: Responder/NoPassive: Passive authentication not supported.

Well, you're sending an authentication request with isPassive to the
IDP but the IDP tells you it doesn't even support that.

So you can stop doing all that, there's nothing left for you to do.

-peter

[Adam Wicks]

I don't think the situation I am describing breaks SAML decentralisation. Moving between SPs would be unaffected. I am suggesting each SP may want to check login with an IDP but not throw an error if not logged in. That should be local to each SP and their own session, it's just how it handles the response to a login.

The mixing of required auth and not required auth content on pages is very common. SSO over multiple eCommerce sites for instance. Commonly most of their pages are public for browsing but should also display content requiring auth like your basket/cart, my account link etc. As an alternative to making the user click login on each site they visit we could make this login check whatever page they land on and not throw an error if the user isn't logged in with the idp. It would be up to the SP whether they have this behaviour. I understand many may not want this when someone visits from another SP/third party SP but I and I suspect others would value the improved user experience over that concern. 

Currently with the error URL redirect on login and a session variable to stop it looping, this IDP login check can be made. However that is very ugly with an extra redirect on the SP.

Forgive me if I am misunderstanding and thanks for your time.

[Peter Schober]

* Adam Wicks <ad...@ecancer.org> [2020-03-19 13:35]:

> I don't think the situation I am describing breaks SAML decentralisation.
> Moving between SPs would be unaffected. I am suggesting each SP may
> want to check login with an IDP but not throw an error if not logged
> in. That should be local to each SP and their own session, it's just
> how it handles the response to a login.

That is fine, even though in my world there's not only a single IDP
that could be used for login, but dozens or thousands.

I'm not sure what you want from this group, though:
You showed logs that the IDP you're trying to use isPassive with does
not support isPassive. Nothing SSP can do about it and AFAIU that's
also the end of your project of redirecting people around only to
"improve" their user experience (when redirecting them elsewhere and
back is unlikely to improve the user experience).

If you're saying the documented APIs and the examlpe code shared on
this list does not work as advertised then feel free to report a bug
about it in the issue tracker.

So what's needed from you here are not generic statements about
possible use-cases for isPassive but concrete technical statements
about what works and what doesn't.

> Currently with the error URL redirect on login and a session
> variable to stop it looping, this IDP login check can be
> made. However that is very ugly with an extra redirect on the SP.

Did you mean to write "extra redirect to the IDP"?
Either way, SAML 2.0 authentication requests with isPassive are to be
handled as prescribed in the SAML specification, warts and all.

So not sure what you want SSP to do about this, either.

-peter

[Christoph]

First of all, I want to thank everybody contributing here. This mailing list has a ton of valuable information, thanks to all you guys!

I had the same requirements as OP, and this is what I came up with:

The Structure:
We have an idP and 3 SPs -> The 3 SPs use exclusively our idP, and the idP only has our 3 SPs 

The requirement:
When the user is logged in on our idP, and visits one of the three SPs, the user should be logged in to the visited SP automatically, with no user interaction at all.

The issue

Unfortunately, there currently is no good way of checking on the SP if the user is logged into the idP without user interaction. 

The common way to do it is just to call the requireAuth() method on the SP, which redirects the user to the idP, and if he is logged in he gets redirected to a target URL, and if not, Auth Procedure is started on the idP.

Using isPassive = true setting in the requireAuth() method is not viable, because if the user is not logged in on the idP, it returns an error (even when the idP actually supports isPassive).

It is pretty confusing, because the error says "Passive authentication not supported." which is not what the problem is. The idP actually supports isPassive, but the user has no session, so this error is thrown.

The solution

The solution for silent checking if the user is logged in on the idP is to use an iframe on the SP, which calls requireAuth() with isPassive = true on every pageload, if the user is not logged in on the SP.

If the user is logged in on the idP, he will be logged in on the SP as well after first pageload, if we reload the page from the iframes parent page when user is loggedin on the idP.

It is a good solution because iframes do not block anything if implemented properly, and no redirects in the main window are needed.

Now, as explained above, requireAuth() with isPassive = true returns an error when the user has no session on the idp, and this causes two issues:

1. The default error page is loaded on every pageload inside the iframe.

2. The included iframe on the SP has Error 500 status (internal server error)

The solution here is very simple. just specify an empty php file on your SP server for the error url when you call requireAuth(), like this:

'ErrorURL' => 'http://test/simpleSamlAuthError.php'

And done. all requirements met, it does not block pageload and it is completly invisible to the user.

The proof of concept code for the iframe solution can be found here at the bottom: https://groups.google.com/forum/#!topic/simplesamlphp/r5EdD_udn88

If somebody knows how to improve this solution, please let me know!

Cheers!

[Peter Schober]

* Christoph <christoph...@gmail.com> [2020-03-24 16:27]:

> The solution for silent checking if the user is logged in on the idP
> is to use an iframe on the SP

That breaks down when subjects block third-party cookies.

(Why would you want to allow others to track your every move across
the WWW? So blocking third-party cookies is the first thing I do on
every browser and sometimes it's even there by default.)

-peter

[Christoph]

This is a valid concern, thanks for mentioning it, Peter. It is definively a case that needs to be handled. 

I checked how some other companies handle this case (no third party cookies), and it seems like google for example does some redirects during the login process, in order to set cookies on other domains, such as youtube, mail.google.com etc.

We could do something similar during the login process in case all third party cookies are disabled: Redirecting to all SPs and calling requireAuth() with isPassive setting on each of them. This will cause a lot of redirects though and this solution must also have proper error handling in place, in case something unexpected happens, so that we always can redirect the user back to the page where he initiated the login process for a good UX.

Apart from that, I do not see any other solutions which could work to handle that specific case.

The simplified redirect chain could look like this (using ReturnTo) and idP / SP setup from my previous post:

SP1 -> idP -> SP2 -> idP -> SP3 -> idP -> SP1

Errors could be handled with a function that redirects users back to SP1 in case of an error.

One thing that might be possible is to distribute the the token ourselves, which would shorten the redirect chain to something like this:

SP1 -> idP -> SP2 -> SP3 -> SP1

However, it would ptobably require significant changes to the core, which should probably be avoided. 

The third possibility would probably be to structure the chain in a zigzag fashion like this:

SP1 -> idP -> SP1 -> SP2 -> idP -> SP1 -> SP3 idP -> SP1

However, I do not see any real advantages over method 1 at the current stage of investigating this.

The drawback of this of course is that this solution can not handle many SPs - but I think we will be fine with 3

Any comments are very welcome :)

Am Dienstag, 24. März 2020 16:41:37 UTC+1 schrieb Peter Schober:

* Christoph <christop...@gmail.com> [2020-03-24 16:27]:

[Peter Schober]

* Christoph <christoph...@gmail.com> [2020-03-25 15:18]:

> Any comments are very welcome :)

Personally I think it's not worth it, by far: It's completely within
reason that people have to click "login" if they want to be logged in.
/Especially in SSO-enabled systems where they're back at/in the SP
within a second or so.

That also avoids the massive UX issues of chains of redirects ("wtf is
going on here?", breaking the back button even further than SSO
already does, etc.) and also has a competely sane UX if the subject
does /not/ have an SSO session at/with the IDP: If you yourself
initiate SSO from an SP and you don't have a session at the IDP you
log in there. Nothing special or surprising about it.

SAML WebSSO has been around for 15 years now (published March 2005)
and I can't recall more than a handful of requests for simultaneous
login to "all SPs". People can deal with it. Move on to other
problems.

Or maybe you'll need to restructure your application architecture.
Or maybe switch SSO protocols.
It all depends.

-peter

[Christoph]

I think the answer to if it is worth it or not could is very different from project to project. if the SPs are all different sites with a different purpose, then I fully agree. that this one click is not an issue at all. however, if they are all part of the same application, with only for example regional content differences, then I think it would make sense to log the user in automatically in order to give him the feeling that he is using a single application (which he actually is in our case), which just happens to have different domains. We use different domains for different countries, but they are all pointed to the same system which serves content according to the domain. but for example the dashboards for the users are exactly the same on each domain, all instances use the same database etc.

I am not sure yet how big of an issue the redirects are, I did not test it yet, but I am working on it and will report back when the test are finished.

With other protocols, there will be issues as well. I first want to fully test everything before considering switching. Because in the end, no matter what protocol we use, some of the issues will be the same. for example if we would use openid, we would still have the exact same issue when it comes to autologin, just because of the different domains we use. Because for openid, we also need to save the token in the browser, and we still can not use the token from one domain on a different one, no different than for SAML,

Thanks for your very useful input, Peter, I appreciate it!

Am Mittwoch, 25. März 2020 16:16:30 UTC+1 schrieb Peter Schober:

* Christoph <christop...@gmail.com> [2020-03-25 15:18]:

[Peter Schober]

* Christoph <christoph...@gmail.com> [2020-03-26 15:38]:

> however, if they are all part of the same application, with only for
> example regional content differences, then I think it would make sense to
> log the user in automatically in order to give him the feeling that he is
> using a single application (which he actually is in our case), which just

> happens to have different domains. [...]

I don't claim to understand what the above entails but that's why I
also included:

> > Or maybe you'll need to restructure your application architecture.

That could mean many different things, of course.
Maybe only use SAML with one system/SP (as some kind of gateway) and
have a different protocol from the SAML SP to all the applications,
maybe something custom based on symmetric encryption of a shared
secret, maybe using a shared DNS domain for some state (if blocked 3rd
party cookies/localStorage/sessionStorage can be ruled out), etc.

-peter

[Brian Clinkenbeard]

**Security Issue with the idea of login to multiple SPs at once. 

As Peter said, this has been asked for only several times and there IS a reason for this.  WITH, an authentication is an IMPLIED INTENT TO ACCESS, USE, or perform SOME action, that IS SPECIFIC TO ONE SP...

Not only is one login to may NOT NEEDED, it is also RIDICULOUSLY DUMB for what that IS, IN BEING ONE login to multiple locations WHERE, the TRUST relationship is based on ANOTHER SP, TO and FROM which there is NO ESTABLISHED RELATIONSHIP!

EACH SP, other than where AN SP, that is among many FOR ONE COMPANY, should be INDEPENDENT of any other as, ONE, does not have and need not KNOW, you are signed in elsewhere, and yet THEY KNOW NOT, by which specific credentials and UNIQUE ACCOUNT that is a REGISTERED USER at the SPECIFIC SP.

FOR an IDP,,, TO, assert TO a handful of other ancillary SPs, it must then have STORED, the IDENTS assigned BY those SPs which means THAT IDP, knows ALL AND EVERY, has the IDENTs in DATA, and UNLESS the development and architecture is 100% secure, a BREACH OF ANY ONE SP, would mean access to ALL AND EVERY account you have elsewhere...

THAT, is NOT and never has been PROPER design for anything as it is ONE set of credentials for access to more than one SITE.

A Company HAS THE MEANS TO DO THIS already IF, they set the SimpleSaml IDP up to be the IDENTITY PROVIDER for their AAD with an OnPremAD and ADDsync.  OR, even if they only have AAD in Azure.  AS the identity provider IN ADFS, the APPS that CAN BE ACCESSED with ONE CLICK are the APPS set up by the Company IN Azure.  IE: The OFFFICE 365 LANDING PAGE.  MiniOrange ALSO has an IDP that CAN accept SimpleSAML asserts and redirect back in with an APPS panel for one click TO OTHER SPs in the MiniOrange Portal. 

BOTH, also allow A user in that system TO SIGN IN, with SAML, and then once back, ALSO PASS FORWARD to those others with OAUTH, and KERBOS etc.

Please take no offense here, but SimpleSAML is NOT where you put a PORTAL that is the GO ANYWHERE or APP Central, or, Store all the credentials. SimpleSAML is the PROTOCOL for what IT does that is the FUNCTION for which it is designed and the OTHER has nothing to do with that. 

YOU CAN HOWEVER, use SimpleSaml in and to send assertions from ANY SP that you code, TO, and ENDPOINT SOLUTION you code that HAS those functions...

SAML is a protocol, NOT AN application. 

The APPLICATION stated prior to Peter's comment IS NOT a protocol.

I will state this from a SECURITY PERSPECTIVE:
Trust a FaceBook, Google, or ANY OTHER BULK FREE PUBLIC ACCOUNT systems ASSERTED USER as YOUR USER, and you are not thinking Security AT ALL.

They forward you a GUID as if that is SOMEONE YOU CAN TRUST.  Not even they know if that is a end user or, a bot generated user that is a bot..

IF, your COMPANY and for auto login to assets controlled BY your company and assets ALLOWED by the company then sure, you can write one.  Put that on the public Internet??? YOU CANNOT afford the fees you will be charged in a breach or the lawsuits that breach WILL create. 

AS TO THE "massive UX" issues...   SAML REDIRECTS DO NOT EVEN REQUIRE UI, unless the SPECIFIC IDP that is in the path of all of those HAS SOME SPECIFIC function those PRIOR, DO NOT HAVE.  It is SEAMLESS and fast.

AS TO logging in AT the IDP, and then going somewhere: THAT, was a MISTAKE we made decades back in trying to solve knowing who the end user was..

The REDIRECT URI, is TO FIX that mistake IF USED properly. 

ANY IDP, that is on PUBLIC INTERNET, should NOT ALLOW IDP DIRECT LOGIN!  USERS should be required to hit AN SP, so the IP, Device, Allowed Login Times, and phone etc, CAN BE KNOWN and CHECKED before sending them to where the HACKERS can CRACK AT THE PASSWORD direct AT the IDP.

ADFS, Domain Joined computer, Allowed login time, they entered an EMAIL or IDENT that is found, and IF THOSE OTHERS ALL LINE UP > Sent with an assertion, and assertion IS required and ONLY IF the REDIRECT URI from a REGISTERED SP is sent AND, the account exists AT THE IDP side, THEN > ALL ELSE HAS BEEN CHECKED, THE IP at IDP, damn sure better match that sent FROM ADFS, the machine name also CAN be sent, as can THE O/S version etc... and IF THE USER HITTING THE IDP is coming from another IP > or O/S the SP did not provide in the assertion BODY attribute elements,,,   BYE, HAVE A NICE DAY Mr/Mrs HACKER and thanks for playing!

I would say that the ONLY TIME a single IDP login should even remotely be considered IS > when it is a company end user, accessing a system that is NOT PUBLIC, and or ACCESSABLE, unless they are ON that network or IN A VPN, when remote.

Even then, Signing in at one and being logged in at ALL,,, MAY SEEM EASIER for the End User but that DOES NOT JUSTIFY the additional traffic and resource usages AT those other SPs and the ENDPOINTS behind them that DO NOT GET USED during the login SESSION. 

IT IS, in this case as DUMB to do as were you to run the entire house unlocking every window and door to only go out or look out of one door or window.

ONLY, open connections to RESOURCES you INTEND TO USE, and your logging servers, will not have 50 unneeded events every time there should only be ONE.


Plus, the things you missed in the concept of redirection passthru to multiple other SPs, and a RATHER HARD CARVED IN STONE FACT,,, if that redirect is handed to 1, 2, 3, 4, 5, 6, 7, 8, 9 and then the LAST SP #10,,, and there is ANY latency/outage of one before 10,,,  YOU WON'T GET THERE!
IF, in similar fashion you send that way a post to LOG OFF, then any one in the chain that is out, WILL LEAVE YOU SIGNED IN to any after. 

This, WILL result in several PAINFUL MASSIVE impacts OPEN sessions FAILED sessions logs that are 5, 10 20 times as huge, COSTS for storing those in space and traffic, and IMPOSSIBLE TO TROUBLESHOOT situations IN a breach incident investigation when you are trying to chase ONE of however many UNUSED connections that were established. 

It JUST IS NOT SECURE BY DESIGN...

The COSTs and TIME expense TO develop a secure solution that COULD > Cannot be justified when for an E3 subscription for Office 365, OR, licensing of a product that DOES portal to provide a simple link are as cheap as they are per user with all the OTHER network, application layer, WAF, etc, so they can sign in once and click a link there. IN AN APP, that LITERALLY HAS nothing to do with SimpleSAML other than for the login. 

I ENCOURAGE ALL, to grasp the concept that ONLY FROM and with an assertion SENT from an SP, should anyone ever see the login page at the IDP. 
Once logged in and returned to the ENDPOINT, then YOU CAN render an assertion back TO the IDP with the redirect TO THE IDP, for the user to then manage the account on the IDP...  OTHER THAN FOR DEV, exposing that login at the IDP without an assertion from the SP, means ALL I NEED IS YOUR EMAIL entered there TO PWN your account AND, via that everything that IDP is for. 

IF, there is any legitimate requirement for login AT THE IDP for access TO the IDP by admin or end user for account maintenance there,  SET UP AN SP, FOR that.

Make it ASSERTION REQUIRED at IDP from a LEGIT registered SP, and that cuts 95% plus out of random hacks ever even hitting it. 
MAKE any ADMIN functions at the IDP to where allowed ONLY FROM an INTERNAL SP, and they cannot hit that PAM level, AT ALL. 

I also advise that SHOULD you do a massive redirect path that you REFRAIN from any SPs that you do not OWN/CONTROL, or you are injecting a dependency that can PREVENT ANY ACCESS internal SHOULD the Internet be out OR, that SP not be reachable...

FAIL BACK to internal. ONLY path redirects to those YOU control.

ELSE, plan for endless outages. 

Been there, done that, 

 Trust me here! After having done SAML "stuff" pre-oasis effort and since in the early 2000s,  THAT GETS REALLY nasty FAST!

-Brian

---

From: simple...@googlegroups.com <simple...@googlegroups.com> on behalf of Christoph <christoph...@gmail.com>
Sent: Thursday, March 26, 2020 9:38 AM
To: SimpleSAMLphp <simple...@googlegroups.com>
Subject: Re: [simplesamlphp-users] Exception on dp, handle it without an errorURL redirect?

 

I think the answer to if it is worth it or not could is very different from project to project. if the SPs are all different sites with a different purpose, then I fully agree. that this one click is not an issue at all. however, if they are all part of the same application, with only for example regional content differences, then I think it would make sense to log the user in automatically in order to give him the feeling that he is using a single application (which he actually is in our case), which just happens to have different domains. We use different domains for different countries, but they are all pointed to the same system which serves content according to the domain. but for example the dashboards for the users are exactly the same on each domain, all instances use the same database etc.

I am not sure yet how big of an issue the redirects are, I did not test it yet, but I am working on it and will report back when the test are finished.

With other protocols, there will be issues as well. I first want to fully test everything before considering switching. Because in the end, no matter what protocol we use, some of the issues will be the same. for example if we would use openid, we would still have the exact same issue when it comes to autologin, just because of the different domains we use. Because for openid, we also need to save the token in the browser, and we still can not use the token from one domain on a different one, no different than for SAML,

Thanks for your very useful input, Peter, I appreciate it!

Am Mittwoch, 25. März 2020 16:16:30 UTC+1 schrieb Peter Schober:

* Christoph <christop...@gmail.com> [2020-03-25 15:18]:

--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
 
https://simplesamlphp.org/support
 
Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
 
Make sure to read the documentation:
 
https://simplesamlphp.org/docs/stable/
 
If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
 
http://catb.org/~esr/faqs/smart-questions.html
---
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 view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp/d954a66a-4094-4318-bda2-30950718362b%40googlegroups.com.