hiding the SSP admin page from prying eyes and brute-force attacks
866 views
Skip to first unread message
Harmen Meijer
Aug 16, 2018, 5:44:33 AM8/16/18
to simple...@googlegroups.com
Hi,
We've had our SP security tested and received the following advice:
------------------------------------
The target application was found to be publicly exposing an administrative login page. This is not inline with good security practice as it attracts unwanted attention and exposes the application to a variety of potential attacks, including brute-force password attacks. As authentication was out of scope for this particular instance of the assessment, no brute-force attacks have been performed.
The following administrative login page was found to be publicly available: https://example.com/simplesaml/module.php/core/loginuserpass.php?AuthState=_4ac84ffb8e431edc0a5d83fe261ea436b9e5b372e0%3Ahttps%3A%2F%2Fexample.com%2Fsimplesaml%2Fmodule.php%2Fcore%2Fas_login.php%3FAuthId%3Dadmin%26ReturnTo%3Dhttps%253A%252F%252Fexample.com%252Fsimplesaml%252Fmodule.php%252Fcore%252Ffrontpage_welcome.php
Please note that the Username field is disabled, and shows the "admin" user as the only user to log on to the application. Technically, this would be categorised as username enumeration, only without the need to perform an enumeration attack against the target.
Recommendation
Restrict public access to the administrative login. If remote access is necessary, consider restricting access to authorised IP addresses by using VPN technology and/or enforcing strong authentication and/or two (or more) factor authentication.
--------------------------------------
Following their advice I restricted access to the admin login pages by ip range 10.0.0.0/24 from httpd.conf like this:
<Location "/simplesaml/module.php/core/loginuserpass.php">
Order deny,allow
Deny from all
Allow from 10.0.0.0/24
</Location>
Problem solved but it seems odd that I need to implement security measures to secure SSP security software. Is there a better way to secure the admin pages? Or is there an out of the box one, maybe from within the SSP application config?
Thanks,
Harmen Meijer
We've had our SP security tested and received the following advice:
------------------------------------
The target application was found to be publicly exposing an administrative login page. This is not inline with good security practice as it attracts unwanted attention and exposes the application to a variety of potential attacks, including brute-force password attacks. As authentication was out of scope for this particular instance of the assessment, no brute-force attacks have been performed.
The following administrative login page was found to be publicly available: https://example.com/simplesaml/module.php/core/loginuserpass.php?AuthState=_4ac84ffb8e431edc0a5d83fe261ea436b9e5b372e0%3Ahttps%3A%2F%2Fexample.com%2Fsimplesaml%2Fmodule.php%2Fcore%2Fas_login.php%3FAuthId%3Dadmin%26ReturnTo%3Dhttps%253A%252F%252Fexample.com%252Fsimplesaml%252Fmodule.php%252Fcore%252Ffrontpage_welcome.php
Please note that the Username field is disabled, and shows the "admin" user as the only user to log on to the application. Technically, this would be categorised as username enumeration, only without the need to perform an enumeration attack against the target.
Recommendation
Restrict public access to the administrative login. If remote access is necessary, consider restricting access to authorised IP addresses by using VPN technology and/or enforcing strong authentication and/or two (or more) factor authentication.
--------------------------------------
Following their advice I restricted access to the admin login pages by ip range 10.0.0.0/24 from httpd.conf like this:
<Location "/simplesaml/module.php/core/loginuserpass.php">
Order deny,allow
Deny from all
Allow from 10.0.0.0/24
</Location>
Problem solved but it seems odd that I need to implement security measures to secure SSP security software. Is there a better way to secure the admin pages? Or is there an out of the box one, maybe from within the SSP application config?
Thanks,
Harmen Meijer
Tim van Dijen
Aug 16, 2018, 6:00:27 AM8/16/18
to SimpleSAMLphp
Hello Harmen,
The file config/authsources.php defines the admin authentication source.
By default, this is configured to use the password set in the main configuration, but you can use anything you want here..
See config-templates/authsources.php for a bunch of examples and you'll get an idea of the possibilities. All those authsources can be used for admin-login, and you can even combine them with multi-auth!
- Tim
Jaime Perez Crespo
Aug 16, 2018, 6:42:35 AM8/16/18
to simple...@googlegroups.com
Hi Harmen,
https://github.com/simplesamlphp/simplesamlphp/blob/master/config-templates/config.php#L118-L123
In any case, the countermeasures they are suggesting are a bit misguided, in the sense that “hiding” the fact that there’s an administrative login is essentially "security by obscurity”, which is generally considered as bad practice. The security of something should not depend on it being unknown or hidden. Additionally, they are kind of missing the point of SSP. The same problem applies to regular login. Obviously, it sounds really weird to use a VPN and/or restrict access by IP address in order to use a software that’s *precisely* intended to avoid IP access controls and VPNs.
That given, and to answer your comment about "implementing security measures to secure SSP”, it makes full sense since SSP is basically a web application, and as such, it cannot anticipate and protect against all possible attack surfaces (e.g. the server where you host it must be secure, and SSP cannot do anything to protect its signing key if no proper access rules are enforced in the server). An application that provides any kind of security cannot make your infrastructure secure beyond the limits of the application itself.
In this particular scenario (brute force attacks), there’s not much the software could do. It could slow down each authentication request for the admin auth source, so that it’s really hard for an attacker to test many passwords in a small amount of time. However, a smart attacker would simply perform the attack in parallel, running the countermeasure ineffective. If many passwords are tested in parallel, that could in fact lead to a Denial of Service on your installation, when the maximum number of clients allowed is hit by the attacker. This is something that needs to be accounted for outside the software, in the server and in the network.
Another alternative would be to record the amount of passwords tried per IP address, but there are as well techniques that can be used to circumvent this limitation (e.g. using botnets with thousands of different IP addresses) and it would make it more difficult to deploy (an extra database would be needed) and require more resources (two queries to the database per request, one to test if the client passed the limit, another to increase the attempt count).
So, as you can see, nothing really useful that SSP can do on its own. I’d recommend you to set a very long, alphanumeric password to the admin user, making it unfeasible to guess by brute force in a reasonable amount of time. If you are worried about attackers with enough resources to do a successful brute force attack, you should worry about them breaking your user’s passwords rather than the admin password (which doesn’t really offer them much). In that case, you’d need to deploy detection measures in your network, in order to detect possible brute force attacks and restrict access at the network level.
--
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
In any case, the countermeasures they are suggesting are a bit misguided, in the sense that “hiding” the fact that there’s an administrative login is essentially "security by obscurity”, which is generally considered as bad practice. The security of something should not depend on it being unknown or hidden. Additionally, they are kind of missing the point of SSP. The same problem applies to regular login. Obviously, it sounds really weird to use a VPN and/or restrict access by IP address in order to use a software that’s *precisely* intended to avoid IP access controls and VPNs.
That given, and to answer your comment about "implementing security measures to secure SSP”, it makes full sense since SSP is basically a web application, and as such, it cannot anticipate and protect against all possible attack surfaces (e.g. the server where you host it must be secure, and SSP cannot do anything to protect its signing key if no proper access rules are enforced in the server). An application that provides any kind of security cannot make your infrastructure secure beyond the limits of the application itself.
In this particular scenario (brute force attacks), there’s not much the software could do. It could slow down each authentication request for the admin auth source, so that it’s really hard for an attacker to test many passwords in a small amount of time. However, a smart attacker would simply perform the attack in parallel, running the countermeasure ineffective. If many passwords are tested in parallel, that could in fact lead to a Denial of Service on your installation, when the maximum number of clients allowed is hit by the attacker. This is something that needs to be accounted for outside the software, in the server and in the network.
Another alternative would be to record the amount of passwords tried per IP address, but there are as well techniques that can be used to circumvent this limitation (e.g. using botnets with thousands of different IP addresses) and it would make it more difficult to deploy (an extra database would be needed) and require more resources (two queries to the database per request, one to test if the client passed the limit, another to increase the attempt count).
So, as you can see, nothing really useful that SSP can do on its own. I’d recommend you to set a very long, alphanumeric password to the admin user, making it unfeasible to guess by brute force in a reasonable amount of time. If you are worried about attackers with enough resources to do a successful brute force attack, you should worry about them breaking your user’s passwords rather than the admin password (which doesn’t really offer them much). In that case, you’d need to deploy detection measures in your network, in order to detect possible brute force attacks and restrict access at the network level.
--
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
Keith Wessel
Aug 16, 2018, 10:04:46 AM8/16/18
to simple...@googlegroups.com
The key takeaway from your note, Jaime, is "the admin password that doesn't really offer them much". I think you were saying what I was thinking the whole time I was reading this email thread: so, they get the admin password. What does that gain them? At this point, the admin interface offers read access to a bunch of information, none of which is very sensitive. I can't think of any huge harm that could come from someone cracking my SSP admin password that they couldn't do without it. Yes, it might give a few vectors for DOS attacks, but honestly one could come up with ways to bog down the server and launch a similar attack without bothering to crack the password first.
This seems to me to be another case of security scanning software over-generalizing things. Yes, it's an admin URL, but it doesn't give the hacker the keys to the kingdom. I think your security folks might be making a mountain out of a mole hill, Harmen.
Keith
--
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.
For more options, visit https://groups.google.com/d/optout.
This seems to me to be another case of security scanning software over-generalizing things. Yes, it's an admin URL, but it doesn't give the hacker the keys to the kingdom. I think your security folks might be making a mountain out of a mole hill, Harmen.
Keith
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.
For more options, visit https://groups.google.com/d/optout.
Harmen Meijer
Aug 16, 2018, 10:51:39 AM8/16/18
to simple...@googlegroups.com
Hi Jaime, Keith and Tim,
Thanks for your answers and input!
Harmen
-----Oorspronkelijk bericht-----
Van: simple...@googlegroups.com [mailto:simple...@googlegroups.com] Namens Jaime Perez Crespo
Verzonden: Thursday 16 August 2018 12:38
Aan: simple...@googlegroups.com
Onderwerp: Re: [simplesamlphp-users] hiding the SSP admin page from prying eyes and brute-force attacks
Hi Harmen,
On 16 Aug 2018, at 11:44 AM, Harmen Meijer <harmen...@bsl.nl> wrote:
> Hi,
>
> We've had our SP security tested and received the following advice:
>
> ------------------------------------
> The target application was found to be publicly exposing an administrative login page. This is not inline with good security practice as it attracts unwanted attention and exposes the application to a variety of potential attacks, including brute-force password attacks. As authentication was out of scope for this particular instance of the assessment, no brute-force attacks have been performed.
>
> The following administrative login page was found to be publicly available: https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_simplesaml_module.php_core_loginuserpass.php-3FAuthState-3D-5F4ac84ffb8e431edc0a5d83fe261ea436b9e5b372e0-253Ahttps-253A-252F-252Fexample.com-252Fsimplesaml-252Fmodule.php-252Fcore-252Fas-5Flogin.php-253FAuthId-253Dadmin-2526ReturnTo-253Dhttps-25253A-25252F-25252Fexample.com-25252Fsimplesaml-25252Fmodule.php-25252Fcore-25252Ffrontpage-5Fwelcome.php&d=DwIFaQ&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=9jpZoSz9hqgzBa5Rv9G13Dq2-0-e7lsTgw1j4vdt1eQ&m=eXSktswWxF9nehdEk0gKB2B1_a2Xigm67Polo-5S4vc&s=ts76zwA5Px-EBEHYJIz19NH9sXmRm4IOdralPyVVP_k&e=
In any case, the countermeasures they are suggesting are a bit misguided, in the sense that “hiding” the fact that there’s an administrative login is essentially "security by obscurity”, which is generally considered as bad practice. The security of something should not depend on it being unknown or hidden. Additionally, they are kind of missing the point of SSP. The same problem applies to regular login. Obviously, it sounds really weird to use a VPN and/or restrict access by IP address in order to use a software that’s *precisely* intended to avoid IP access controls and VPNs.
That given, and to answer your comment about "implementing security measures to secure SSP”, it makes full sense since SSP is basically a web application, and as such, it cannot anticipate and protect against all possible attack surfaces (e.g. the server where you host it must be secure, and SSP cannot do anything to protect its signing key if no proper access rules are enforced in the server). An application that provides any kind of security cannot make your infrastructure secure beyond the limits of the application itself.
In this particular scenario (brute force attacks), there’s not much the software could do. It could slow down each authentication request for the admin auth source, so that it’s really hard for an attacker to test many passwords in a small amount of time. However, a smart attacker would simply perform the attack in parallel, running the countermeasure ineffective. If many passwords are tested in parallel, that could in fact lead to a Denial of Service on your installation, when the maximum number of clients allowed is hit by the attacker. This is something that needs to be accounted for outside the software, in the server and in the network.
Another alternative would be to record the amount of passwords tried per IP address, but there are as well techniques that can be used to circumvent this limitation (e.g. using botnets with thousands of different IP addresses) and it would make it more difficult to deploy (an extra database would be needed) and require more resources (two queries to the database per request, one to test if the client passed the limit, another to increase the attempt count).
So, as you can see, nothing really useful that SSP can do on its own. I’d recommend you to set a very long, alphanumeric password to the admin user, making it unfeasible to guess by brute force in a reasonable amount of time. If you are worried about attackers with enough resources to do a successful brute force attack, you should worry about them breaking your user’s passwords rather than the admin password (which doesn’t really offer them much). In that case, you’d need to deploy detection measures in your network, in order to detect possible brute force attacks and restrict access at the network level.
--
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
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://urldefense.proofpoint.com/v2/url?u=https-3A__simplesamlphp.org_docs_stable_&d=DwIFaQ&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=9jpZoSz9hqgzBa5Rv9G13Dq2-0-e7lsTgw1j4vdt1eQ&m=eXSktswWxF9nehdEk0gKB2B1_a2Xigm67Polo-5S4vc&s=TYtQPtKvk38EQiNBvJZo7zZ-_0OvPKOsz662RGgz40M&e=
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:
https://urldefense.proofpoint.com/v2/url?u=http-3A__catb.org_-7Eesr_faqs_smart-2Dquestions.html&d=DwIFaQ&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=9jpZoSz9hqgzBa5Rv9G13Dq2-0-e7lsTgw1j4vdt1eQ&m=eXSktswWxF9nehdEk0gKB2B1_a2Xigm67Polo-5S4vc&s=C2e2KUf0QeKfr4GFnaBUtYmHykIrPR_0f3rrdc8b1UU&e=
Thanks for your answers and input!
Harmen
-----Oorspronkelijk bericht-----
Van: simple...@googlegroups.com [mailto:simple...@googlegroups.com] Namens Jaime Perez Crespo
Verzonden: Thursday 16 August 2018 12:38
Aan: simple...@googlegroups.com
Onderwerp: Re: [simplesamlphp-users] hiding the SSP admin page from prying eyes and brute-force attacks
Hi Harmen,
On 16 Aug 2018, at 11:44 AM, Harmen Meijer <harmen...@bsl.nl> wrote:
> Hi,
>
> We've had our SP security tested and received the following advice:
>
> ------------------------------------
> The target application was found to be publicly exposing an administrative login page. This is not inline with good security practice as it attracts unwanted attention and exposes the application to a variety of potential attacks, including brute-force password attacks. As authentication was out of scope for this particular instance of the assessment, no brute-force attacks have been performed.
>
>
> Please note that the Username field is disabled, and shows the "admin" user as the only user to log on to the application. Technically, this would be categorised as username enumeration, only without the need to perform an enumeration attack against the target.
>
> Recommendation
> Restrict public access to the administrative login. If remote access is necessary, consider restricting access to authorised IP addresses by using VPN technology and/or enforcing strong authentication and/or two (or more) factor authentication.
> --------------------------------------
>
> Following their advice I restricted access to the admin login pages by ip range 10.0.0.0/24 from httpd.conf like this:
>
> <Location "/simplesaml/module.php/core/loginuserpass.php">
> Order deny,allow
> Deny from all
> Allow from 10.0.0.0/24
> </Location>
>
> Problem solved but it seems odd that I need to implement security measures to secure SSP security software. Is there a better way to secure the admin pages? Or is there an out of the box one, maybe from within the SSP application config?
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_simplesamlphp_simplesamlphp_blob_master_config-2Dtemplates_config.php-23L118-2DL123&d=DwIFaQ&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=9jpZoSz9hqgzBa5Rv9G13Dq2-0-e7lsTgw1j4vdt1eQ&m=eXSktswWxF9nehdEk0gKB2B1_a2Xigm67Polo-5S4vc&s=J82Pa3lg4fWMEwcZAfnINaIL_kkES3Izggw2peteRNY&e=
> Please note that the Username field is disabled, and shows the "admin" user as the only user to log on to the application. Technically, this would be categorised as username enumeration, only without the need to perform an enumeration attack against the target.
>
> Recommendation
> Restrict public access to the administrative login. If remote access is necessary, consider restricting access to authorised IP addresses by using VPN technology and/or enforcing strong authentication and/or two (or more) factor authentication.
> --------------------------------------
>
> Following their advice I restricted access to the admin login pages by ip range 10.0.0.0/24 from httpd.conf like this:
>
> <Location "/simplesaml/module.php/core/loginuserpass.php">
> Order deny,allow
> Deny from all
> Allow from 10.0.0.0/24
> </Location>
>
> Problem solved but it seems odd that I need to implement security measures to secure SSP security software. Is there a better way to secure the admin pages? Or is there an out of the box one, maybe from within the SSP application config?
In any case, the countermeasures they are suggesting are a bit misguided, in the sense that “hiding” the fact that there’s an administrative login is essentially "security by obscurity”, which is generally considered as bad practice. The security of something should not depend on it being unknown or hidden. Additionally, they are kind of missing the point of SSP. The same problem applies to regular login. Obviously, it sounds really weird to use a VPN and/or restrict access by IP address in order to use a software that’s *precisely* intended to avoid IP access controls and VPNs.
That given, and to answer your comment about "implementing security measures to secure SSP”, it makes full sense since SSP is basically a web application, and as such, it cannot anticipate and protect against all possible attack surfaces (e.g. the server where you host it must be secure, and SSP cannot do anything to protect its signing key if no proper access rules are enforced in the server). An application that provides any kind of security cannot make your infrastructure secure beyond the limits of the application itself.
In this particular scenario (brute force attacks), there’s not much the software could do. It could slow down each authentication request for the admin auth source, so that it’s really hard for an attacker to test many passwords in a small amount of time. However, a smart attacker would simply perform the attack in parallel, running the countermeasure ineffective. If many passwords are tested in parallel, that could in fact lead to a Denial of Service on your installation, when the maximum number of clients allowed is hit by the attacker. This is something that needs to be accounted for outside the software, in the server and in the network.
Another alternative would be to record the amount of passwords tried per IP address, but there are as well techniques that can be used to circumvent this limitation (e.g. using botnets with thousands of different IP addresses) and it would make it more difficult to deploy (an extra database would be needed) and require more resources (two queries to the database per request, one to test if the client passed the limit, another to increase the attempt count).
So, as you can see, nothing really useful that SSP can do on its own. I’d recommend you to set a very long, alphanumeric password to the admin user, making it unfeasible to guess by brute force in a reasonable amount of time. If you are worried about attackers with enough resources to do a successful brute force attack, you should worry about them breaking your user’s passwords rather than the admin password (which doesn’t really offer them much). In that case, you’d need to deploy detection measures in your network, in order to detect possible brute force attacks and restrict access at the network level.
--
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
--
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://urldefense.proofpoint.com/v2/url?u=https-3A__simplesamlphp.org_support&d=DwIFaQ&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=9jpZoSz9hqgzBa5Rv9G13Dq2-0-e7lsTgw1j4vdt1eQ&m=eXSktswWxF9nehdEk0gKB2B1_a2Xigm67Polo-5S4vc&s=LSqGjsBvoBNSL_YoC_lVxnWKIg0Ju3_LK9aU_2RjVL8&e=
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:
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:
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:
---
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.
For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIFaQ&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=9jpZoSz9hqgzBa5Rv9G13Dq2-0-e7lsTgw1j4vdt1eQ&m=eXSktswWxF9nehdEk0gKB2B1_a2Xigm67Polo-5S4vc&s=BrrkJ3Q8K2M_C0TvRPuCrYTi58lAhRq_wO4_0XtvrDo&e=.
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.
Reply all
Reply to author
Forward
0 new messages