Strange behavior: lots of logins by one user

[Manolo Garcia Alvarez]

That makes sense Stephen, thanks a lot.

We are reducing the suspects to Google Suite (which is the SP that's
causing the logins), an specific browser or a combination of both. About
your "Force Authentication" suggestion, we are running 3,1 and this is a
production environment and will affect a lot of users, so I don't think
it's possible.  We're now trying to identify the browser of the users with
huge number of logins, but as you said it's clear the problem it's on the
SP.

Thanks again !!

------------------------------
Manolo García
Arquitectura i Sistemes
Universitat Oberta de Catalunya

93 326 (3451) | 689 88 30 93 | mgarciaal at uoc.edu
Parc Mediterrani de la Tecnologia (edifici B3)
Av. Carl Friedrich Gauss, 5.
08860 Castelldefels
[image: Universitat Oberta de Catalunya]
Aquest missatge s'adreça exclusivament a qui va destinat i pot contenir
informació privilegiada o confidencial i dades de caràcter personal, la
difusió de les quals és regulada per la Llei orgànica de protecció de dades
i la Llei de serveis de la societat de la informació. Si no sou la persona
destinatària indicada (o la responsable de lliurar-lo a qui va destinat),
no heu de copiar aquest missatge ni lliurar-lo a tercers per cap concepte.
Si heu rebut aquest missatge per error o l'heu aconseguit per altres
mitjans, us demanem que ens ho comuniqueu immediatament per aquesta mateixa
via i l'elimineu irreversiblement.

Abans d'imprimir aquest missatge electrònic penseu en el medi ambient.


El mié., 30 ene. 2019 a las 12:48, Losen, Stephen C (scl) (<scl at virginia.edu>)
escribió:

> Hi Manolo,
>
>
>
> I suspect a redirect loop.  The user logs in to the IDP and the IDP passes
> the assertion to the browser. The browser presents the assertion to the
> SP.  For some reason the SP rejects the login, perhaps because the user is
> missing from the SP’s own user database, or an attribute value is missing
> or unacceptable to the  SP.  Instead of displaying an error page, the SP
> redirects the browser back to the SP’s own login URL.  This would be
> reasonable if the SP were displaying its own username/password page. (When
> login fails, let the user try again.)  But in the case of SAML, redirecting
> back to the SP login URL results in a redirect to your IDP to authenticate
> again.  The user has a valid SSO session, so the IDP silently gives the
> browser another assertion and the browser presents it to the SP, which
> rejects it and redirects to the SP login URL again, etc.  The browser
> address window at the top probably shows at least two URLs flickering back
> and forth, and each trip through the loop gets logged on the IDP as a
> successful login.
>
>
>
> The solution is not on the IDP.  It is behaving normally and correctly.
> The culprit is the SP, which should display an error instead of redirecting
> to login again.  If the SP has a configuration “dashboard” then this
> behavior may be configurable.  Otherwise you need to notify the SP admins.
>
>
>
> Or I suppose you could configure “Forced Authentication” for the
> troublesome SP.  This will cause your IDP to display its login page rather
> than silently redirect.  I think you can do this in conf/relying-party.xml
> with an override for the SP.  A quick check of the IDP wiki shows this is
> possible if you are running IDP 3.4.
>
>
>
> Stephen C. Losen
>
> ITS - Systems and Storage
>
> University of Virginia
>
> scl at virginia.edu    434-924-0640
>
>
>
> *From:* users [mailto:users-bounces at shibboleth.net] *On Behalf Of *Manolo
> Garcia Alvarez
> *Sent:* Wednesday, January 30, 2019 5:49 AM
> *To:* Shib Users <users at shibboleth.net>
> *Subject:* Strange behavior: lots of logins by one user
>
>
>
> Hi,
>
>
>
> we are using Shibboleth as an IdP with a lot of SP's for a community of
> about 50.000 active users, without problems so far. Nevertheless, our
> idp-audit shows a strange behavior of some users: a few number of users are
> registering successful logins in a short period of time (1 hour typically):
>
>
>
> This is one of them:
>
>
>
> [image: image.png]
>
>
>
> The bump on the graph shows just one user (login amartingil) who has more
> than 1800 logins in one hour according to the idp-login.log, so it's clear
> that's not possible for one real user. In this example, the SP is Google
> and all the logins are registered in one of three the servers that are
> running Shibboleth. That's just one case, but we find this everyday with
> another set of users and another period of time. I can attach the relevant
> parts of the logs if it's useful.
>
>
>
> I have done some research in the list and internet but I can't find
> anybody with the same problem. Is there someone with the same problem or
> information about this issue?
>
>
>
> Thanks a lot !
>
>
> ------------------------------
>
> *Manolo García*
> Arquitectura i Sistemes
> *Universitat Oberta de Catalunya*
>
> 93 326 (3451) | 689 88 30 93 | mgarciaal at uoc.edu
>
> Parc Mediterrani de la Tecnologia (edifici B3)
>
> Av. Carl Friedrich Gauss, 5.
>
> 08860 Castelldefels
>
> [image: Universitat Oberta de Catalunya]
> Aquest missatge s'adreça exclusivament a qui va destinat i pot contenir
> informació privilegiada o confidencial i dades de caràcter personal, la
> difusió de les quals és regulada per la Llei orgànica de protecció de dades
> i la Llei de serveis de la societat de la informació. Si no sou la persona
> destinatària indicada (o la responsable de lliurar-lo a qui va destinat),
> no heu de copiar aquest missatge ni lliurar-lo a tercers per cap concepte.
> Si heu rebut aquest missatge per error o l'heu aconseguit per altres
> mitjans, us demanem que ens ho comuniqueu immediatament per aquesta mateixa
> via i l'elimineu irreversiblement.
>
> Abans d'imprimir aquest missatge electrònic penseu en el medi ambient.
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190131/870c5fdb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6895 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20190131/870c5fdb/attachment.png>