[Fim4l] Reasonable lenght of SP's session

Raoul Teeuwen raoul.teeuwen at surfnet.nl
Wed Feb 26 13:50:19 CET 2020


Hi Meshna.

Isn't 'cost' one aspect for deciding on this? If the person being 
allowed to access content is still counted as usage and therefor the 
institution is charged (extra) for that user by the publisher, that 
could be a reason for institutions not to want this?

I also wonder (but i don't work in a librariy) how often access includes 
access to information that is somehow seen as sensitive. What for 
instance if a person is found to be an agent from a regime where some 
nations have restrictions to what you're allowed to share with, but they 
would be allowed access for many extra months?

Kindest regards,

Raoul.

On 26-02-2020 13:28, Koren, Meshna (ELS-AMS) wrote:
> Thanks Nick and Bernd for your responses so far.
>
> You're right; federated access is used to establish the session and in that regard it isn't very long and I wasn't directly referring to that.
>
> I'd like to explore this some more:
> "And there might be something like a "remember me" feature which allows the user to come back later and setup a new application session without having to authenticate again. I assume your question is about how long this should be possible? My recommendation would be to not offer a "remember me" feature in comination with FIM because (a) the IdP usually supports single sign-on so authenticating again should be easy (at least when it is easy to select the institution) and (b) this might cause problems when there is an incident like a mass download - after some time the library might no longer be able to identify the user (in our
> case: after a week)."
>
> We know what the risk for Elsevier would have been if we allowed a user to be remembered, and clearly we'd need to be able to manage mass download. I was more wondering whether allowing the user to be remembered for an extended period of time would in some way be inconvenient to the IdPs/institutions. Would we be breaking some unwritten FIM rules by remembering a user for 3 month (this is just an arbitrary lenght)?
>
>  From the IdP perspective that would mean that users that have signed in to IdP every day would then sign in every 3 month. It would also mean that a user that is disabled through IdP (because they leave the institution) can still access institutional subscriptions for another 3 month.
>
> Does anyone keep track of that? Does anyone care? Is a daily control of usage expected/desired by anyone? Is there some other reason that we should keep a user signed in for 3 month?
>
> Thanks,
> Meshna
>
>
> -----Original Message-----
> From: FIM4L <fim4l-bounces at lists.daasi.de> On Behalf Of Bernd Oberknapp
> Sent: Wednesday, February 26, 2020 01:26
> To: fim4l at lists.daasi.de
> Subject: Re: [Fim4l] Reasonable lenght of SP's session
>
> *** External email: use caution ***
>
>
>
> In my experience for more complex applications the SP session itself doesn't play a role because it is only used to setup an application session, so the SP session might be very short, maybe just 30 seconds.
>
> The application session usually has a relatively short timeout, maybe between 30 minutes and a few hours. Note that this session timeout is relevant for Unique_Item and Unique_Title metrics in COUNTER usage reports.
>
> And there might be something like a "remember me" feature which allows the user to come back later and setup a new application session without having to authenticate again. I assume your question is about how long this should be possible? My recommendation would be to not offer a "remember me" feature in comination with FIM because (a) the IdP usually supports single sign-on so authenticating again should be easy (at least when it is easy to select the institution) and (b) this might cause problems when there is an incident like a mass download - after some time the library might no longer be able to identify the user (in our
> case: after a week).
>
> So if Elsevier would offer a "remember me" feature and only authenticate users after longer periods like a month or six months, Elsevier would have to take responsibility for usage by users no longer affiliated with the institution and for incidents that might happen during this period.
> And of course this should align with the license agreements.
>
> Best regards,
> Bernd
>
>
> On 25.02.20 12:19, Koren, Meshna (ELS-AMS) wrote:
>> Dear all,
>>
>> I have another question which I posted on another thread earlier...
>>
>> >From the library's perspective, what is a reasonable time for an SP to maintain a session for a user?
>>
>> It would have been possible for Elsevier to maintain a session for any lenght of time - but is that desirable by the libraries? Should we confirm with the library that a user is still affiliated with it whenever a user wants to access the service (such as ScienceDirect)? Or every day? Every week? Every month? Every 6 months?
>>
>> Thanks,
>> Meshna
>>
>>
>>
>> Meshna Koren
>>
>> Associate Product Manager
>> Product Management - Identity and Access - Research Products
>>
>> Elsevier BV
>> Radarweg 29, Amsterdam 1043 NX, The Netherlands
>> m.koren at elsevier.com<mailto:m.koren at elsevier.com>
>>
>> Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens,
>> Institutional Login
>>
>>
>>
>>
>> ________________________________
>>
>> Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
>>
>>
>> _______________________________________________
>> FIM4L mailing list
>> FIM4L at lists.daasi.de
>> http://lists.daasi.de/listinfo/fim4l
>>
>
> --
> Bernd Oberknapp
> Gesamtleitung ReDI
>
> Albert-Ludwigs-Universität Freiburg
> Universitätsbibliothek
> Platz der Universität 2 | Postfach 1629
> D-79098 Freiburg        | D-79016 Freiburg
>
> Telefon:  +49 761 203-3852
> Telefax:  +49 761 203-3987
> E-Mail:   bo at ub.uni-freiburg.de
> Internet: www.ub.uni-freiburg.de
>
>
> ________________________________
>
> Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20200226/23a31055/attachment-0001.html>


More information about the FIM4L mailing list