On 08/04/2019, 15:37, "FIM4L on behalf of Gragert, Gerrit" <fim4l-bounces@lists.daasi.demailto:fim4l-bounces@lists.daasi.de on behalf of gerrit.gragert@sbb.spk-berlin.demailto:gerrit.gragert@sbb.spk-berlin.de> wrote:
Hi Folks,
Welcome Gerrit!
… But our library's view might be slightly different from other libraries i.e. at universities: although we have a lot of patrons, we do not have "associated scientist" at our institution. Most of our patrons already have an (federated) identity at their home organization, so it would break up single-sign-on if we supply them with a second identity in the federation. Therefore, I'm interested in secure and privacy-preserving ways to provide entitlements and other attributes to our services as well as third-party service-providers / end-services for those of our patrons who have an identity somewhere else.
I wonder whether the Attribute Aggregation feature of the Dutch SURFconext identity hub is basically addressing that kind of problem (not sure how easy that is to arrange for in non-hub-and-spoke federations). Any identity and attribute set can be augmented with more attributes via attribute providers that get looked up at the moment an authentication happens… We have some documentation at https://wiki.surfnet.nl/display/surfconextdev/Attribute+Aggregation and a case where it is used described at https://blog.surf.nl/en/ordering-and-reading-with-estudybooks-is-easy-and-sa....
Kindest regards,
Raoul.
Dear Gerrit,
let me welcome you at FIM4L as well as Raoul.
Is it correct that State Library Berlin registered patrons can use federated authentication at JSTOR, Project MUSE, Web Of Science, ... ? - http://rzblx10.uni-regensburg.de/dbinfo/dbliste.php?bib_id=sbb&colors=51...
Kind regards
Jiri Pavlik, Moravian Library
On Mon, Apr 8, 2019 at 4:52 PM Raoul Teeuwen raoul.teeuwen@surfnet.nl wrote:
On 08/04/2019, 15:37, "FIM4L on behalf of Gragert, Gerrit" <fim4l-bounces@lists.daasi.de on behalf of gerrit.gragert@sbb.spk-berlin.de> wrote:
Hi Folks,
Welcome Gerrit!
… But our library's view might be slightly different from other libraries i.e. at universities: although we have a lot of patrons, we do not have "associated scientist" at our institution. Most of our patrons already have an (federated) identity at their home organization, so it would break up single-sign-on if we supply them with a second identity in the federation. Therefore, I'm interested in secure and privacy-preserving ways to provide entitlements and other attributes to our services as well as third-party service-providers / end-services for those of our patrons who have an identity somewhere else.
I wonder whether the Attribute Aggregation feature of the Dutch SURFconext identity hub is basically addressing that kind of problem (not sure how easy that is to arrange for in non-hub-and-spoke federations). Any identity and attribute set can be augmented with more attributes via attribute providers that get looked up at the moment an authentication happens… We have some documentation at https://wiki.surfnet.nl/display/surfconextdev/Attribute+Aggregation and a case where it is used described at https://blog.surf.nl/en/ordering-and-reading-with-estudybooks-is-easy-and-sa....
Kindest regards,
Raoul.
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Dear Jiri,
Is it correct that State Library Berlin registered patrons can use federated authentication at JSTOR, Project MUSE, Web Of Science, ... ?
Well... No. It's complicated...
We have differents groups of users/patrons. The largest group are our "local" patrons at the SBB - you have to get here to our house, fill out and sign a registration form and then you get a library card. Then you may use our ejournals and databases and so on (including JSTOR, MUSE etc.)
But these patrons have to use a proxy-server with local authentication (OpenLDAP). As I wrote, we cannot provide federated authentication for them because a lot of these patrons already have an federated identity at their university or other home instiution.
Another group of users are the users of our special information services (in german it says Fachinformationsdienste). These are scientist from all over germany who are registered for the service. They may connect their home identity with the account at the special information service via eduPersonUniqueId. Here, we are using federated authentication based on SAML at our proxy server, but not towards the providers (also because the providers are mostly chinese and they never heard about something like Shibboleth).
But my goal is to offer federated authentication for all of our users. So out patrons may use our services and the serivces at third-party providers we have licensed with their home identity.
Best,
Gerrit
-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
Hi,
most content provider platforms work with fixed customer accounts, and a user is always mapped to a single customer account, either based on IP ranges or information provided by FIM. So while FIM could provide the information which resources from multiple customer accounts should be available to a specific user, most content provider won't be able to give the user access to that set of resources.
For example University of Freiburg and a special information service have two different customer accounts for a content provider, and a user is always mapped to one of them. In order to provide access to both the resources licensed by University of Freiburg and the special information service to a user entitled to access both, a separate customer account with the combined resources and a specific mapping to that customer account would be nessecary. There are lots of special information services and even more combinations of licensed resources - this obviously doesn't scale.
There are some exceptions like SpringerLink, but the way this is handled today is quite confusing - it is possible to login multiple times with accounts from differnt institutions (or even the same institution) and the status message at the bottom of the page still shows "Not logged in". This only changes when a registered SpringerLink account is used to login.
Best regards, Bernd
On 09.04.2019 15:10, Gragert, Gerrit wrote:
Dear Jiri,
Is it correct that State Library Berlin registered patrons can use federated authentication at JSTOR, Project MUSE, Web Of Science, ... ?
Well... No. It's complicated...
We have differents groups of users/patrons. The largest group are our "local" patrons at the SBB - you have to get here to our house, fill out and sign a registration form and then you get a library card. Then you may use our ejournals and databases and so on (including JSTOR, MUSE etc.)
But these patrons have to use a proxy-server with local authentication (OpenLDAP). As I wrote, we cannot provide federated authentication for them because a lot of these patrons already have an federated identity at their university or other home instiution.
Another group of users are the users of our special information services (in german it says Fachinformationsdienste). These are scientist from all over germany who are registered for the service. They may connect their home identity with the account at the special information service via eduPersonUniqueId. Here, we are using federated authentication based on SAML at our proxy server, but not towards the providers (also because the providers are mostly chinese and they never heard about something like Shibboleth).
But my goal is to offer federated authentication for all of our users. So out patrons may use our services and the serivces at third-party providers we have licensed with their home identity.
Best,
Gerrit-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Dear Bernd,
I'm aware of this. This is one of the reasons why we use a proxy to provide access to the content and why we are our own service provider. But imho FIM has always to come with federated access management to address such problems. And as I understood, this is already part of the AARC Blueprint. So maybe with RA21, content provider will also change their technical settings here. Or we have to switch to an person-centric eduId like the suisse and others do. But this may bring up other problems in the access management.
Best, Gerrit
-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
-----Ursprüngliche Nachricht----- Von: FIM4L fim4l-bounces@lists.daasi.de Im Auftrag von Bernd Oberknapp Gesendet: Dienstag, 9. April 2019 16:27 An: fim4l@lists.daasi.de Betreff: Re: [Fim4l] Short introduction
Hi,
most content provider platforms work with fixed customer accounts, and a user is always mapped to a single customer account, either based on IP ranges or information provided by FIM. So while FIM could provide the information which resources from multiple customer accounts should be available to a specific user, most content provider won't be able to give the user access to that set of resources.
For example University of Freiburg and a special information service have two different customer accounts for a content provider, and a user is always mapped to one of them. In order to provide access to both the resources licensed by University of Freiburg and the special information service to a user entitled to access both, a separate customer account with the combined resources and a specific mapping to that customer account would be nessecary. There are lots of special information services and even more combinations of licensed resources - this obviously doesn't scale.
There are some exceptions like SpringerLink, but the way this is handled today is quite confusing - it is possible to login multiple times with accounts from differnt institutions (or even the same institution) and the status message at the bottom of the page still shows "Not logged in". This only changes when a registered SpringerLink account is used to login.
Best regards, Bernd
On 09.04.2019 15:10, Gragert, Gerrit wrote:
Dear Jiri,
Is it correct that State Library Berlin registered patrons can use federated authentication at JSTOR, Project MUSE, Web Of Science, ... ?
Well... No. It's complicated...
We have differents groups of users/patrons. The largest group are our "local" patrons at the SBB - you have to get here to our house, fill out and sign a registration form and then you get a library card. Then you may use our ejournals and databases and so on (including JSTOR, MUSE etc.)
But these patrons have to use a proxy-server with local authentication
(OpenLDAP). As I wrote, we cannot provide federated authentication for them because a lot of these patrons already have an federated identity at their university or other home instiution.
Another group of users are the users of our special information services
(in german it says Fachinformationsdienste). These are scientist from all over germany who are registered for the service. They may connect their home identity with the account at the special information service via eduPersonUniqueId. Here, we are using federated authentication based on SAML at our proxy server, but not towards the providers (also because the providers are mostly chinese and they never heard about something like Shibboleth).
But my goal is to offer federated authentication for all of our users.
So out patrons may use our services and the serivces at third-party providers we have licensed with their home identity.
Best,
Gerrit-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
FIM4L mailing list FIM4L@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@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de
Dear Gerrit, Bernd, Raoul,
thanks a lot for sharing informations regarding accounts linking and attribute aggregation. When there is more organisations who adopted SWITCH edu-ID [1] I believe SpringerLink or Karger could be the first content providers supporting life long educational identity and multiple user affiliations across several organisations provided via attribute aggregation.
Best regards
Jiri
1. https://www.switch.ch/edu-id/about/participants/
On Wed, Apr 10, 2019 at 5:32 PM Gragert, Gerrit gerrit.gragert@sbb.spk-berlin.de wrote:
Dear Bernd,
I'm aware of this. This is one of the reasons why we use a proxy to provide access to the content and why we are our own service provider. But imho FIM has always to come with federated access management to address such problems. And as I understood, this is already part of the AARC Blueprint. So maybe with RA21, content provider will also change their technical settings here. Or we have to switch to an person-centric eduId like the suisse and others do. But this may bring up other problems in the access management.
Best, Gerrit
-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
-----Ursprüngliche Nachricht----- Von: FIM4L fim4l-bounces@lists.daasi.de Im Auftrag von Bernd Oberknapp Gesendet: Dienstag, 9. April 2019 16:27 An: fim4l@lists.daasi.de Betreff: Re: [Fim4l] Short introduction
Hi,
most content provider platforms work with fixed customer accounts, and a user is always mapped to a single customer account, either based on IP ranges or information provided by FIM. So while FIM could provide the information which resources from multiple customer accounts should be available to a specific user, most content provider won't be able to give the user access to that set of resources.
For example University of Freiburg and a special information service have two different customer accounts for a content provider, and a user is always mapped to one of them. In order to provide access to both the resources licensed by University of Freiburg and the special information service to a user entitled to access both, a separate customer account with the combined resources and a specific mapping to that customer account would be nessecary. There are lots of special information services and even more combinations of licensed resources - this obviously doesn't scale.
There are some exceptions like SpringerLink, but the way this is handled today is quite confusing - it is possible to login multiple times with accounts from differnt institutions (or even the same institution) and the status message at the bottom of the page still shows "Not logged in". This only changes when a registered SpringerLink account is used to login.
Best regards, Bernd
On 09.04.2019 15:10, Gragert, Gerrit wrote:
Dear Jiri,
Is it correct that State Library Berlin registered patrons can use federated authentication at JSTOR, Project MUSE, Web Of Science, ... ?
Well... No. It's complicated...
We have differents groups of users/patrons. The largest group are our "local" patrons at the SBB - you have to get here to our house, fill out and sign a registration form and then you get a library card. Then you may use our ejournals and databases and so on (including JSTOR, MUSE etc.)
But these patrons have to use a proxy-server with local authentication
(OpenLDAP). As I wrote, we cannot provide federated authentication for them because a lot of these patrons already have an federated identity at their university or other home instiution.
Another group of users are the users of our special information services
(in german it says Fachinformationsdienste). These are scientist from all over germany who are registered for the service. They may connect their home identity with the account at the special information service via eduPersonUniqueId. Here, we are using federated authentication based on SAML at our proxy server, but not towards the providers (also because the providers are mostly chinese and they never heard about something like Shibboleth).
But my goal is to offer federated authentication for all of our users.
So out patrons may use our services and the serivces at third-party providers we have licensed with their home identity.
Best,
Gerrit-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
FIM4L mailing list FIM4L@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@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Raoul,
I wonder whether the Attribute Aggregation feature of the Dutch SURFconext identity hub is basically addressing that kind of problem (not sure how easy that is to arrange for in non-hub-and-spoke federations). Any identity and attribute set can be augmented with more attributes via attribute providers that get looked up at the moment an authentication happens…
Thanks for the links - I didn't know this solution yet. We came to a solution using the SimpleAttributeAggregation-Feature of the Service-Provider and a stand-alone Attribute Provider. We connect the users using the eduPersonUniqueId. But the workflow is quite similar: the user have to register themself for one of our special information services (i.e. the CrossAsia-Protal https://crossasia.org/). Than they can connect their login at their home institution with the account for CrossAsia via ePUId. But the users don't go directly to the third-party providers - here we are using a proxy which authenticates toward the users via SAML and towards to the provider via IP. My fear is with RA21 the use of proxies will end and so we will need a SAML-only solution.
If you are interested in further details of our solution, there's a video-presentation https://doi.org/10.5446/18808 (I'm sorry it is only in german).
What kind of software is SURFconext?
Regards,
Gerrit
-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 mailto:gerrit.gragert@sbb.spk-berlin.de http://www.staatsbibliothek-berlin.de
Teilnehmer (4)
-
Bernd Oberknapp -
Gragert, Gerrit -
Jiri Pavlik -
Raoul Teeuwen