<div dir="ltr"><div dir="ltr">On Tue, Sep 3, 2019 at 7:18 AM Miguel Salinas Vivancos <<a href="mailto:msalinas@bcn.sia.es">msalinas@bcn.sia.es</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Steve, thank you for your answer.<br>
If the hypothesis is a SAML Response rejected by the SP, then it will only happen with specific Google Applications, right? The rest of users are accessing to Gmail without problems.<br>
I don't know if Google stores the users but it's strange that they check it in just some apps.<br></blockquote><div><br></div><div>We've seen it historically for users who initiate logins at specific vanity URL's (e.g., <a href="http://gcal.lbl.gov">http://gcal.lbl.gov</a>) that are have CNAME records pointing to Google.  It's not all of them; Calendar has historically been the worst.  We've never had problems with Gmail.  After wasting too much time on it, my solution for users has been, "Don't do that."  I probably should have just removed the domain mapping.  </div><div><br></div><div>AFAIK, it has not happened to users when visiting the direct service URL's.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The assertion is quite simple as we only send the mail attribute.<br>
<br>
I've found this link <a href="https://developers.google.com/admin-sdk/reports/v1/appendix/activity/saml" rel="noreferrer" target="_blank">https://developers.google.com/admin-sdk/reports/v1/appendix/activity/saml</a>, maybe we can try to lookup the SP logs...<br></blockquote><div><br></div><div>Those logs are for the G Suite IdP, not the SP.</div><div><br></div><div><br></div><div>Greg</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If we find the answer, we'll post it.<br>
<br>
<br>
Miguel Salinas Vivancos<br>
Identity Management Integrator <br>
Tel.: +34 639 198 154 - <a href="mailto:mail%3Amsalinas@bcn.sia.es" target="_blank">mail:msalinas@bcn.sia.es</a><br>
<br>
Grupo SIA<br>
Citypark, Edificio Atenas, Ctra. Hospitalet 147. 08940 Cornellá de Llobregat - Barcelona<br>
<a href="http://www.sia.es" rel="noreferrer" target="_blank">www.sia.es</a>  - Twitter: @SIA_es  - LinkedIn: Grupo SIA<br>
<br>
<br>
-----Mensaje original-----<br>
De: users [mailto:<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>] En nombre de Losen, Stephen C (scl)<br>
Enviado el: martes, 3 de septiembre de 2019 12:31<br>
Para: Shib Users<br>
Asunto: RE: Massive authentications from SP GoogleApps<br>
<br>
Hi Miguel,<br>
<br>
I have seen looping like this, but not necessarily involving Google. The user visits the SP, which redirects the user to our IDP for authentication. After success, the IDP redirects the user back to the SP. However, the SP does not accept the credentials (assertion). Perhaps the SP has its own database of users and the SP fails to find the user. Perhaps the assertion for this user is unacceptable for some other reason. The SP should display an error page, but instead lets the user try again. The SP redirects the user back to our IDP for authentication with a new auth request. But this time the user has an IDP session, so the IDP displays no login page and redirects the user back to the SP with another assertion, which the SP rejects. And this sets up a redirect loop.<br>
<br>
The IDP is unaware of any problem and the IDP logs show no errors. But the logs do show a large number of normal logins to the same SP by the same user. <br>
<br>
Steve Losen<br>
ITS - Enterprise Infrastructure<br>
University of Virginia<br>
mailto:<a href="mailto:scl@virginia.edu" target="_blank">scl@virginia.edu</a>    434-924-0640<br>
<br>
From: users <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>> On Behalf Of Miguel Salinas Vivancos<br>
Sent: Monday, September 2, 2019 1:04 PM<br>
To: <a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a><br>
Subject: Massive authentications from SP GoogleApps<br>
<br>
Hi,<br>
We are using Shibboleth IDP 3.4.4 over Java 1.8, deployed in a Tomcat 8.5.<br>
We have multiple SPs configured to authenticate against our IDP, including big commercial ones like Amazon, Adobe and Microsoft.<br>
<br>
Our problem is that sometimes (maybe once or twice a week), we receive a huge amount of authentications from GoogleApps.<br>
I'm talking over 250 logins in a few seconds when the average for that SP is 5 per minute. <br>
<br>
At the logs we have seen that on that peek the user is always the same, and Shibboleth is generating different sessions. On different peeks, the users are different so it doesn't seem a problem of specific users.<br>
<br>
This also happened to us with IDP 3.1.2 over Java 1.7 in a Tomcat 7, so the version of the components neither seems to be the problem.<br>
<br>
Has anyone faced something similar? Maybe one of the applications of GoogleApps or the OS/device of the users?<br>
<br>
Thank you in advance<br>
<br>
<br>
Miguel Salinas Vivancos<br>
Identity Management Integrator <br>
Tel.: +34 639 198 154 - <a href="mailto:mail%3Amsalinas@bcn.sia.es" target="_blank">mail:msalinas@bcn.sia.es</a><br>
<br>
Grupo SIA<br>
Citypark, Edificio Atenas, Ctra. Hospitalet 147. 08940 Cornellá de Llobregat - Barcelona<br>
<a href="http://www.sia.es/" rel="noreferrer" target="_blank">http://www.sia.es/</a>  - Twitter: @SIA_es  - LinkedIn: Grupo SIA<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div></div>