Elsevier Federated Authentication changes (was RE: Hello and brief intro)
Sure happy to. For reference, it is probably useful for me to crosspost here a message I posted yesterday to the JISC lis-e-resources list:
As some of you have noted, we have recently made some updates to the institutional sign in user experience on ScienceDirect. These are part of a set of changes we are making in an effort to solve some long-standing difficulties users have accessing our products, and to ensure that the sign-in and access experience is consistent across all of Elsevier.
I want to take this chance to apologise for any confusion caused as we make these changes, and to reassure you that they do not represent a change in our policies: we have always offered users the ability to access subscribed content by signing in with their institution without having to register for an Elsevier account. Similarly, when users opt to create an Elsevier account and link it to their institutional credentials to access personalised features such as alerts, we have always asked for a minimal set of information comprising name and email address.
In our new approach, we are assuming that users who click the “Sign in” option want to access personalised features provided by an Elsevier account. We ask them for their email upfront so that we can check if they already have an account, and if so, allow them to link their institutional credentials to their existing account. This we hope will reduce a major source of user frustration when users create duplicate accounts inadvertently and then can’t access all of their personalised settings in once place.
Users who want to access content without creating an Elsevier account can click on the “Check Access” button which currently appears on non-subscribed article pages, which will lead them through a flow which allows them to authenticate via their institution and access the content directly and anonymously if that’s their preference.
Early feedback from users and customers has revealed that we need to make further improvements to make this distinction clearer. We are planning to make the following changes over the new few weeks: • Change the wording on the “sign in via institution” screen to explain why we’re asking users for their email • Give the users the option to skip the step of creating an Elsevier account if that’s not what they intended to do • Improve the visibility of the Check Access option in the ScienceDirect user interface.
We will continue to monitor and make further adjustments as needed, so we welcome any and all feedback on this new approach. Our goal is to make it as quick and convenient as possible for users to access resources by signing in via their institution. Crucially, this is not at the expense of their personal data: we are committed to making access easier while improving, not chipping away at, user privacy. We firmly believe that users should only have to sign in to an Elsevier account if there’s a reason, and a benefit to them.
Thanks
_________________________ Chris Shillum VP Identity and Platform Strategy ELSEVIER | Research Products
c.shillum@elsevier.com https://orcid.org/0000-0002-1108-3660
-----Original Message----- From: Jiri Pavlik jiri.pavlik@mzk.cz Sent: Thursday, 12 September, 2019 5:43 AM To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Hello and brief intro
Dear Chris,
could you let us know, please, once currently planned changes in sign in at Science Direct are in place?
It is great to have you and Meshna at FIM4L so we can work together and make sure that ScienceDirect, Scopus and other other Elsevier services follow FIM4L recommendations in the best way possible.
All the best
Jiri
On Sat, Sep 7, 2019 at 2:05 PM Raoul Teeuwen raoul.teeuwen@surfnet.nl wrote:
Hi Chris.
Welcome, great you’re on board ...
Not to ‘welcome’ you with a potential unpleasant discussion, and i do not know what you heard about the discussion after people saw what buttons Elsevier has put online at ScienceDirect, but: do you see any possibiity to either roll back the changes in access/sign in-buttons to a previous version (and maybe 1st have a discussion with people in the identity and access management field, or fix the current situation? Or is this a case of Elsevier balancing all aspects, of which ‘strategies to make money’ of course is one, which leads to, accorinding to many in our field, the strange current UI/UX? Redefining ‘access’ and ‘sign in’, and argumenting that it’s just a matter of users getting used to that, sounds a bit ... ‘unreal’...
With kindest regards, met vriendelijke groet,
Raoul
tel:+31641195989
On 06/09/2019, 21:15, "FIM4L on behalf of Shillum, Chris (ELS-NYC)" <fim4l-bounces@lists.daasi.de on behalf of c.shillum@elsevier.com> wrote:
Hi All
My name’s Chris Shillum. I’m VP of Identity Management and Platform Strategy at Elsevier, looking after Elsevier’s access management system among other things. I’m also a member of the SeamlessAccess.org governance group and we co-chair of the RA21 project.
I’ve been involved in federated authentication for many years and looking forward for joining the discussions of this group
Happy for my name and affiliation to be published on the website.
Cheers
Chris
Chris Shillum
VP Identity and Platform Strategy
ELSEVIER | Research Products
+1 212 462 1987 office
+1 646 250 8029 mobile
c.shillum@elsevier.com
https://orcid.org/0000-0002-1108-3660
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
On 12/09/2019, 22:28, "FIM4L on behalf of Shillum, Chris (ELS-NYC)" <fim4l-bounces@lists.daasi.de on behalf of c.shillum@elsevier.com> wrote:
... We are planning to make the following changes over the new few weeks: ... • Give the users the option to skip the step of creating an Elsevier account if that’s not what they intended to do
+1
cheers, Jos
Hi,
thanks a lot for sharing the info at FIM4L list, Chris. I like the planned changes as Jos does.
Are you going to add required attributes at Elsevier SP metadata in eduGAIN [1] similary to the SP metadata in eduID.at[2] or SWITCHAii/SWITCH edu-ID? Actually I believe Elsevier is using name and e-mail address if provided by IdP so displayName, mail, givenName, sn can be among optional attributes in the SP metadata.
Best regards
Jiri
1. https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c... 2. https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
On Fri, Sep 13, 2019 at 8:14 AM Jos Westerbeke jos.westerbeke@eur.nl wrote:
On 12/09/2019, 22:28, "FIM4L on behalf of Shillum, Chris (ELS-NYC)" <fim4l-bounces@lists.daasi.de on behalf of c.shillum@elsevier.com> wrote:
... We are planning to make the following changes over the new few weeks: ... • Give the users the option to skip the step of creating an Elsevier account if that’s not what they intended to do
+1
cheers, Jos
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Jiri,
Thanks for your question.
We are not going to change our metadata in the federations.
Elsevier SP requires an entitlements attribute through some federations but not all. The reason we don't require it through all federations, yet, is our historical implementation and the fact if we start requiring it from all IdPs, those that aren't able to release it would lose access. We would like to require it as a rule but that is currently just not possible. Adding an entitlement attribute as a requirement to our metadata when we aren't able to honor it would be misleading.
Elsevier SP recommends the release of ePTID or a Persistent NameID that is being used for personalization. We recommend its release but we don't require it.
We don't need any other user attributes and those are that being sent to us are just being ignored.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Jiri Pavlik Sent: Tuesday, September 17, 2019 13:58 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Elsevier Federated Authentication changes (was RE: Hello and brief intro)
*** External email: use caution ***
Hi,
thanks a lot for sharing the info at FIM4L list, Chris. I like the planned changes as Jos does.
Are you going to add required attributes at Elsevier SP metadata in eduGAIN [1] similary to the SP metadata in eduID.at[2] or SWITCHAii/SWITCH edu-ID? Actually I believe Elsevier is using name and e-mail address if provided by IdP so displayName, mail, givenName, sn can be among optional attributes in the SP metadata.
Best regards
Jiri
1. https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c... 2. https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
On Fri, Sep 13, 2019 at 8:14 AM Jos Westerbeke jos.westerbeke@eur.nl wrote:
On 12/09/2019, 22:28, "FIM4L on behalf of Shillum, Chris (ELS-NYC)" <fim4l-bounces@lists.daasi.de on behalf of c.shillum@elsevier.com> wrote:
... We are planning to make the following changes over the new few weeks: ... • Give the users the option to skip the step of creating an Elsevier account if that’s not what they intended to do
+1
cheers, Jos
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
_______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
On 2019-09-18 00:22, Koren, Meshna (ELS-AMS) wrote:
Hi Jiri,
Thanks for your question.
We are not going to change our metadata in the federations.
Elsevier SP requires an entitlements attribute through some federations but not all. The reason we don't require it through all federations, yet, is our historical implementation and the fact if we start requiring it from all IdPs, those that aren't able to release it would lose access. We would like to require it as a rule but that is currently just not possible. Adding an entitlement attribute as a requirement to our metadata when we aren't able to honor it would be misleading.
Elsevier SP recommends the release of ePTID or a Persistent NameID that is being used for personalization. We recommend its release but we don't require it.
We don't need any other user attributes and those are that being sent to us are just being ignored.
Kind regards, Meshna
This brings up an important point: whatever this group agrees to in terms of signalling for privacy-focused attribute release we have to think about how to transition from whatever is done today to how we want things to work tomorrow.
Any such transition will likely look like a breaking change for the SP for much the same reasons so its probably a good idea for us to think about and discuss some transition strategies.
On idea might be to have multiple SPs for the same entity and involve the federation operator to make a choice to facilitate the transition by filtering one or the other entity. The local federation op is often the one that can communicate with IdP etc
Cheers Leif
Indeed - I think this is probably best done via the creation of a new Entity Category, rather than signalling required/optional attributes in our SP metadata. We've found that support for required/optional attributes across various federations is patchy to say the least. We recently went through an exercise to make our SP metadata as consistent as possible across all federations we participate in, yet we see quite a bit of variability in our metadata in Edugain because of how each federation supports and handles various attributes.
Cheers Chris
-----Original Message----- From: Leif Johansson leifj@sunet.se Sent: Wednesday, 18 September, 2019 3:07 AM To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Elsevier Federated Authentication changes (was RE: Hello and brief intro)
On 2019-09-18 00:22, Koren, Meshna (ELS-AMS) wrote:
Hi Jiri,
Thanks for your question.
We are not going to change our metadata in the federations.
Elsevier SP requires an entitlements attribute through some federations but not all. The reason we don't require it through all federations, yet, is our historical implementation and the fact if we start requiring it from all IdPs, those that aren't able to release it would lose access. We would like to require it as a rule but that is currently just not possible. Adding an entitlement attribute as a requirement to our metadata when we aren't able to honor it would be misleading.
Elsevier SP recommends the release of ePTID or a Persistent NameID that is being used for personalization. We recommend its release but we don't require it.
We don't need any other user attributes and those are that being sent to us are just being ignored.
Kind regards, Meshna
This brings up an important point: whatever this group agrees to in terms of signalling for privacy-focused attribute release we have to think about how to transition from whatever is done today to how we want things to work tomorrow.
Any such transition will likely look like a breaking change for the SP for much the same reasons so its probably a good idea for us to think about and discuss some transition strategies.
On idea might be to have multiple SPs for the same entity and involve the federation operator to make a choice to facilitate the transition by filtering one or the other entity. The local federation op is often the one that can communicate with IdP etc
Cheers Leif
Teilnehmer (5)
-
Jiri Pavlik -
Jos Westerbeke -
Koren, Meshna (ELS-AMS) -
Leif Johansson -
Shillum, Chris (ELS-NYC)