"Password leak at Elsevier"

[Peter Schober]

* Steven Carmody <steven_carmody at brown.edu> [2019-03-29 20:54]:
> There was an early Shib Use Case that described sending a persistent
> opaque identifier to these sites; the publisher would recognize the
> user across multiple sessions but wouldn't know who the person
> is. That was intended to avoid this exact situation.
> 
> Do any of these publishers support that model ? Is there any
> approach we can give to our users to help them avoid creating
> passwords at these sites ?

By far not all IDPs support persistent NameIDs so IDP and federation
operators will often prefer to only provide authorization (e.g. using
the common-lib-terms eduPersonEntitlement attribute value or an agreed
upon eduPersonScopedAffiliation attribute value) but not provide an
identifier allowing to recognise a returning subject.
(This may stem from the desire to avoid sending personal data/PII,
ignoring AssertionIDs and other technical artifacts.)

So while many publishers would probably support so far most of those
SPs also work without sending an identifier in the SAML and therefore
requre manually registering/setting up Yet Another Account at each of
those SPs.
Clearly this is an anti-pattern in many respects (UX, security, etc.),
but a very common model nonetheless.

>From recent comments on the FIM4L mailing list it seems that some
publishers intend to move to a model with *only* federated logins
doing away with IP-based access control completely usually argued by
enabling them to block individual users, but I'm guessing the fact
that this also enables them to create personal usage profiles more
easily will not exactly be unwelcome.

So this may well become more common in the future, possibly to the
point of becoming the only way to use many of those services that
traditionally could be used pretty much anonymously.
-peter