Can the SimpleSAMLphp built in discovery service determine previously logged in IdP?

[Philip Cummins]

Hello,

I was hoping some more experienced users of SimpleSAMLphp may be able to assist in helping me understand how the built in SimpleSAMLphp discovery service (disco.php) operates with user workflows.

We currently have region based IdP's that provide authentication services for the region based SP's which is working fine. However, with increased requirements we have added a SimpleSAMLphp SP instance that uses the built in discovery service (disco.php) to select which regional IdP to authenticate from. However, I've noticed that even if you are previously logged into a regional IdP the discovery service is unable to determine which IdP to authenticate from if you haven't set the "Remember my choice" cookie. As an example:

1) Log into Region IdP.

2) Access SP that is federated with multiple regional IdP's.

3) SP's discovery service will always ask which regional IdP to authenticate from (unless "Remember by choice" is set).

4) Once the correct IdP is selected SSO works as per expected.

Is it possible for the discovery service to know which IdP the user previously logged into or is always dependent on the "Remember my choice" cookie to help streamline this process or to have the user select which IdP to use?

Thanks,

Philip

[Jaime Perez Crespo]

Hi Philip,

I think you are kind of answering yourself. If the user checks the “Remember my choice” box, then a cookie will be set and the discovery service will know what IdP to use. If the box is unchecked, then the user should be able to choose again during the next login, right? If the discovery service “remembered” your choice always, what would be the purpose of the “Remember my choice” checkbox? And if you don’t do that with a cookie, how would the DS know what IdP you have chosen previously?

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
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

[Philip Cummins]

Hello,

I think you are kind of answering yourself. If the user checks the “Remember my choice” box, then a cookie will be set and the discovery service will know what IdP to use. If the box is unchecked, then the user should be able to choose again during the next login, right? If the discovery service “remembered” your choice always, what would be the purpose of the “Remember my choice” checkbox? And if you don’t do that with a cookie, how would the DS know what IdP you have chosen previously?

Thanks for the response - it's more to determine if this is the best workflow at present with the SimpleSAMLphp built-in discovery service (disco.php). Our non-technical support staff believe it should work something along the lines of:

1) User accesses an existing regional SP and logs into the local regional IdP. This short cuts the discovery service as we always log into the local regional IdP.

2) User accesses the cross-regional SP which they believe should know which IdP the user was logged in from and automatically authenticate from that without asking (or requiring a cookie).

If the user accesses the cross-regional SP without being logged in then they believe it would be reasonable to have the user pick which regional IdP to authenticate from, so they were hoping the streamline the process above when a user is already logged in at least once. In general, most of our users would log in via the regional IdP's initially so it was to hopefully streamline the process when the user was logged into a single IdP only.

I did do some reading up about PingFederation which uses a common domain cookie to set which IdP was logged in from (see here) as well as the PingPong IdP Discovery Protocol (here) but not sure if this was being considered or implemented for SimpleSAMLphp?

Thanks,

Philip

[Jaime Perez Crespo]

Hi again,

On 4 Apr 2017, at 10:02 AM, Philip Cummins <pcum...@gmail.com> wrote:
> Hello,
>
>> I think you are kind of answering yourself. If the user checks the “Remember my choice” box, then a cookie will be set and the discovery service will know what IdP to use. If the box is unchecked, then the user should be able to choose again during the next login, right? If the discovery service “remembered” your choice always, what would be the purpose of the “Remember my choice” checkbox? And if you don’t do that with a cookie, how would the DS know what IdP you have chosen previously?
>
> Thanks for the response - it's more to determine if this is the best workflow at present with the SimpleSAMLphp built-in discovery service (disco.php). Our non-technical support staff believe it should work something along the lines of:
>
> 1) User accesses an existing regional SP and logs into the local regional IdP. This short cuts the discovery service as we always log into the local regional IdP.

That’s doable. If a “reginoal SP” will only allow you to login with a specific “regional IdP”, you can specify its entityID in the “idp” configuration option of the SP (config/authsources.php), and then the discovery will be bypassed.

> 2) User accesses the cross-regional SP which they believe should know which IdP the user was logged in from and automatically authenticate from that without asking (or requiring a cookie).

That’s not how SAML works, I’m afraid.

> If the user accesses the cross-regional SP without being logged in then they believe it would be reasonable to have the user pick which regional IdP to authenticate from, so they were hoping the streamline the process above when a user is already logged in at least once.

If you really want to go that way, you could send passive authentication requests to every IdP to see if the user is already logged into any of them. If an IdP replies with an assertion (meaning the user was indeed authenticated), then you will be logged in automatically and you don’t even need to go to the IdP. However, consider the pitfalls:

- From your sentence, I get that a user could be logged into several IdPs at the same time. What happens in that case? What IdP would you use? Shouldn’t the user decide which IdP to use?
- What if the user is logged into one IdP, but wants to use another one?

> In general, most of our users would log in via the regional IdP's initially so it was to hopefully streamline the process when the user was logged into a single IdP only.

In that case, I don’t think it’s a big issue that users reaching the “cross-regional SP” need to choose which IdP they want to use to authenticate.

> I did do some reading up about PingFederation which uses a common domain cookie to set which IdP was logged in from (see here) as well as the PingPong IdP Discovery Protocol (here) but not sure if this was being considered or implemented for SimpleSAMLphp?

I was unaware of that, and of course there’s no support for it in SimpleSAMLphp nor any plans to support it. It’s clearly a custom development by Ping Identity and a risky one, I would say, if they allow SPs to read the user’s cookies in a different domain by using iframes and javascript.

My advice is to avoid twisting the protocols and the software to fit them to a corner case. If IdP discovery works like this, it’s in general for a reason, and what might be a good idea from the user experience point of view, could end up being a nightmare for other corner cases.

[Philip Cummins]

Hello,

Thanks for the reply -

> 2) User accesses the cross-regional SP which they believe should know which IdP the user was logged in from and automatically authenticate from that without asking (or requiring a cookie).

That’s not how SAML works, I’m afraid.

That's pretty much what I was discovering while reading around so good to know this is by design.

> If the user accesses the cross-regional SP without being logged in then they believe it would be reasonable to have the user pick which regional IdP to authenticate from, so they were hoping the streamline the process above when a user is already logged in at least once.

If you really want to go that way, you could send passive authentication requests to every IdP to see if the user is already logged into any of them. If an IdP replies with an assertion (meaning the user was indeed authenticated), then you will be logged in automatically and you don’t even need to go to the IdP. However, consider the pitfalls:

- From your sentence, I get that a user could be logged into several IdPs at the same time. What happens in that case? What IdP would you use? Shouldn’t the user decide which IdP to use?
- What if the user is logged into one IdP, but wants to use another one?

We were considering in the few instances where someone was logged into multiple IdP's (just our own staff) the discovery service would be displayed which would make sense.

 

> In general, most of our users would log in via the regional IdP's initially so it was to hopefully streamline the process when the user was logged into a single IdP only.

In that case, I don’t think it’s a big issue that users reaching the “cross-regional SP” need to choose which IdP they want to use to authenticate.

Yes I agreed with that view however the other non-technical staff disagreed and felt the choice of IdP between two company controlled websites should be more streamlined. From their point of view (which was tempered from the the previous experience of only using a single IdP) users should be able to navigate from our primary application site to our support site without needing to choose which IdP to use again.

Looking further around it looks like there is a hidden saml:idp argument in the as_login.php code that enables discovery service/WAYF bypassing that was set up here so I was able to use an URL as follows:

https://sp.website.com/simplesaml/module.php/core/as_login.php?AuthId=default-sp&saml:idp=[Selected IdP]&ReturnTo=https://sp.website.com/

Which appears to do the job and is already in the SimpleSAMLphp code?

> I did do some reading up about PingFederation which uses a common domain cookie to set which IdP was logged in from (see here) as well as the PingPong IdP Discovery Protocol (here) but not sure if this was being considered or implemented for SimpleSAMLphp?

I was unaware of that, and of course there’s no support for it in SimpleSAMLphp nor any plans to support it. It’s clearly a custom development by Ping Identity and a risky one, I would say, if they allow SPs to read the user’s cookies in a different domain by using iframes and javascript.

I believe the cookie system uses a common domain cookie so only would work with company controlled SP's - the PingPong system was more of a guide to hint to the user which IdP's they were currently logged into to reduce the IdP selection down, it looked like the user would still select which IdP to use.

My advice is to avoid twisting the protocols and the software to fit them to a corner case. If IdP discovery works like this, it’s in general for a reason, and what might be a good idea from the user experience point of view, could end up being a nightmare for other corner cases.

I'm trying to avoid this where possible however always good to get some extra feedback on this (as you can tell, the non-technical staff expectations are not always in sync with how things work).

Thanks,

Philip

[Jaime Perez Crespo]

Hi Philip,

On 6 Apr 2017, at 08:50 AM, Philip Cummins <pcum...@gmail.com> wrote:
>>> > If the user accesses the cross-regional SP without being logged in then they believe it would be reasonable to have the user pick which regional IdP to authenticate from, so they were hoping the streamline the process above when a user is already logged in at least once.
>>
>> If you really want to go that way, you could send passive authentication requests to every IdP to see if the user is already logged into any of them. If an IdP replies with an assertion (meaning the user was indeed authenticated), then you will be logged in automatically and you don’t even need to go to the IdP. However, consider the pitfalls:
>>
>> - From your sentence, I get that a user could be logged into several IdPs at the same time. What happens in that case? What IdP would you use? Shouldn’t the user decide which IdP to use?
>> - What if the user is logged into one IdP, but wants to use another one?
>
> We were considering in the few instances where someone was logged into multiple IdP's (just our own staff) the discovery service would be displayed which would make sense.

Bear in mind that it’s not possible to be authenticated by several IdPs at the same time. The authentication status is tied to the authentication source (a SAML service provider), and once you authenticate with an IdP, you are authenticated and cannot authenticate again with another IdP without logging out first.

You could on the other hand add as many SAML authentication sources as IdPs you have, so that simultaneous authentication at different IdPs is possible. But in that case, it’s up to you to display a discovery and choose between any of the auth sources.

>>> > In general, most of our users would log in via the regional IdP's initially so it was to hopefully streamline the process when the user was logged into a single IdP only.
>>
>> In that case, I don’t think it’s a big issue that users reaching the “cross-regional SP” need to choose which IdP they want to use to authenticate.
>
> Yes I agreed with that view however the other non-technical staff disagreed and felt the choice of IdP between two company controlled websites should be more streamlined. From their point of view (which was tempered from the the previous experience of only using a single IdP) users should be able to navigate from our primary application site to our support site without needing to choose which IdP to use again.

One alternative that you could explore is using a proxy. Then, all your SPs would just ask for authentication to the proxy, and the proxy would be the one allowing users to choose the IdP. However, once the user is authenticated, it won’t be possible to select another IdP.

> Looking further around it looks like there is a hidden saml:idp argument in the as_login.php code that enables discovery service/WAYF bypassing that was set up here so I was able to use an URL as follows:
>
> https://sp.website.com/simplesaml/module.php/core/as_login.php?AuthId=default-sp&saml:idp=[Selected IdP]&ReturnTo=https://sp.website.com/
>
> Which appears to do the job and is already in the SimpleSAMLphp code?

Yes, but that’s only supported when creating “login links”, not in the API. If you want, you could use the getLoginLink() method from SimpleSAML_Auth_Simple to get such URL with a custom return URL, and add manually the “saml:idp” parameter (as I said, it’s not supported throughout the API). The URL you provide as a parameter must be then a script that you control, that checks if the user is authenticated, gets the attributes, and does whatever you need afterwards.

In any case, this allows you to bypass the discovery, yes, but you still won’t know if the user is authenticated or not.

>> My advice is to avoid twisting the protocols and the software to fit them to a corner case. If IdP discovery works like this, it’s in general for a reason, and what might be a good idea from the user experience point of view, could end up being a nightmare for other corner cases.
>
> I'm trying to avoid this where possible however always good to get some extra feedback on this (as you can tell, the non-technical staff expectations are not always in sync with how things work).

I know pretty well :-)

In any case, good luck with it! Hope you find a solution or manage to convince your colleagues.

[Philip Cummins]

Hello,

> We were considering in the few instances where someone was logged into multiple IdP's (just our own staff) the discovery service would be displayed which would make sense.

Bear in mind that it’s not possible to be authenticated by several IdPs at the same time. The authentication status is tied to the authentication source (a SAML service provider), and once you authenticate with an IdP, you are authenticated and cannot authenticate again with another IdP without logging out first.

You could on the other hand add as many SAML authentication sources as IdPs you have, so that simultaneous authentication at different IdPs is possible. But in that case, it’s up to you to display a discovery and choose between any of the auth sources.

Thanks - I'll add it into the notes for testing since in theory only our own staff should be able to log into multiple IdP's at a time vs our users.

 

> Yes I agreed with that view however the other non-technical staff disagreed and felt the choice of IdP between two company controlled websites should be more streamlined. From their point of view (which was tempered from the the previous experience of only using a single IdP) users should be able to navigate from our primary application site to our support site without needing to choose which IdP to use again.

One alternative that you could explore is using a proxy. Then, all your SPs would just ask for authentication to the proxy, and the proxy would be the one allowing users to choose the IdP. However, once the user is authenticated, it won’t be possible to select another IdP.

Yes we're looking at this step next as we will eventually need to start federating with other IdP's that we don't control to release our own internal attributes (as well as some authorisation checks) so inevitably a discovery service will be used. I believe this should be more acceptable to our staff since it will ask only on login vs navigating from one site to another, so it's on our list to develop further.

 

> Looking further around it looks like there is a hidden saml:idp argument in the as_login.php code that enables discovery service/WAYF bypassing that was set up here so I was able to use an URL as follows:
>
> https://sp.website.com/simplesaml/module.php/core/as_login.php?AuthId=default-sp&saml:idp=[Selected IdP]&ReturnTo=https://sp.website.com/
>
> Which appears to do the job and is already in the SimpleSAMLphp code?

Yes, but that’s only supported when creating “login links”, not in the API. If you want, you could use the getLoginLink() method from SimpleSAML_Auth_Simple to get such URL with a custom return URL, and add manually the “saml:idp” parameter (as I said, it’s not supported throughout the API). The URL you provide as a parameter must be then a script that you control, that checks if the user is authenticated, gets the attributes, and does whatever you need afterwards.

In any case, this allows you to bypass the discovery, yes, but you still won’t know if the user is authenticated or not.

In our case we only ever use these links in a previously authenticated environment and we control both sides so it was able to work. I've put some large caveats on this (ie it won't work with proprietary or 3rd party systems) but hopefully will smooth things out until a proxy system is developed instead.

> I'm trying to avoid this where possible however always good to get some extra feedback on this (as you can tell, the non-technical staff expectations are not always in sync with how things work).

I know pretty well :-)
In any case, good luck with it! Hope you find a solution or manage to convince your colleagues.

With the above method they were happier with the workflow for the time being.

Thanks,

Philip