Last active
June 29, 2016 09:04
-
-
Save klaalo/813ee7d1583168cf31ad4b95c51902cd to your computer and use it in GitHub Desktop.
My notes from Liber2016 AARC Workshop: Federate to win
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Liber2016 | |
| AARC Workshop: Federate to Win | |
| http://dy.fi/iio4 | |
| * How can I activate institutional login at a e-resource for my organisation? | |
| * On the application (e-resource) | |
| * Install software | |
| * Configure | |
| * Verify interoperability (test integration) | |
| * Join the local federation | |
| * Expose to interfederation if necessary | |
| * On the organisation | |
| * Order integration to federated authentication for the e-service | |
| * Check that the organisation is part of a federation | |
| * Similar steps as above on the application side | |
| * Check that the attribute release policy of the organisation is updated | |
| * How to manage logout at library terminals? | |
| * OS-provided temporary visitor accounts should be used on desktop OS | |
| * Use SAML Single logout (but don’t depend on it!) | |
| * Advice to close all browser windows and close visitor session | |
| * Invalidate OS visitor session after short inactivity period (warn first) | |
| * Short-lived application sessions | |
| * Persistent cookies absolutely forbidden | |
| * Use forced authentication on the application when kiosk user is identified | |
| * Does make any sense to maintain a proxy server along with IdP? | |
| * Depends on the requirements of the application | |
| * May be necessary for attribute release or to integrate authentication to the e-resource | |
| * Not necessary for federated authentication | |
| * Why should I join a federation when all my needs are solved by IP based authentication? | |
| * is not limited to geolocation or terminal | |
| * VPN not required | |
| * opens new opportunities, for example licensing (based on user attributes) | |
| * enables better end-user experience | |
| * single sign-on is advantageous when data is being scattered in several separate portals | |
| Notes (http://dy.fi/iick) | |
| * Federated access is an interesting development path for Libraries | |
| * Peter Gietz, https://daasi.de/en/ | |
| * Necessity of the Proxy server | |
| * Libraries use proxies to | |
| * allow one central point of access for users | |
| * help institutions to mitigate service disruptions on a single e-service | |
| * proxy is not a requirement to benefit from federated access | |
| * use of proxy server doesn’t prevent benefiting from federated access | |
| * the proxy server can define the demarcation point of authentication | |
| * will it be handled within the institution | |
| * will it be handled at the e-service | |
| * Necessity of VPN service | |
| * VPN service itself utilises the IdM service of the organisation | |
| * federated access (Identity Provider of the organisation) can provide the identity of the users which makes VPN redundant | |
| * VPN service doesn’t prevent benefiting from federated access | |
| * —> VPN servise is irrelevant for federated access | |
| * Identity Provider relays the identity information of the user directly to the service. Separate user management will not be needed. | |
| * Users’ Personal information is managed in their home organisations | |
| * E-services receive different sets of user information (attributes) based on the need | |
| * e-service might only get information that the user is authenticated at the organisation (e.g. university) and possibly the he is a member of a particular user group | |
| * if further information is relevant for the service, release of more extensive set of personal data may be agreed between organisation and e-service | |
| * in the best case automatically e.g. based on standard Code of Conduct | |
| * in some cases with separate agreement between organisation and the e-service | |
| * What about if the user changes organisations? | |
| * The information about the organisation where the user is authenticated will be relayed at the time of authentication | |
| * e-service can see from which organisation the user is coming from | |
| * User might retain access to the old organisation, but if his affiliation changes the new status of the user is reflected in the personal data that is relayed to the service at the time of authenticating to the service | |
| * Libraries have walk-in users that are not member of traditional HE organisations. This may be a government requirement for the library service. External users receive library card that will entitle them the services of the library | |
| * Library could have a seperate user directory and identity provider for external (so called UFO) users | |
| * there are many public services that can be used to identify external users | |
| * common IdP services in interfederation context of higher education (eduGAIN) | |
| * social media providers (Microsoft, Google. LinkedIn, Twitter etc) | |
| * How many attributes is there for the users | |
| * As many as the federation defines | |
| * We have few common attribute definitions in higher education federations | |
| * Common attributes | |
| * eduPersonAffiliation | |
| * eduPersonScopedAffiliation | |
| * eduPersonEntitlement | |
| * eduPersonTargetedId | |
| * privacy preserving pseudonymous and unique identifier for a user | |
| * Traditionally federated access based on SAML has been limited only to web context. There are some solutions to non-web access also, but they are not yet widely used. Daasi has implemented an SAML-Oauth2 proxy that makes it possible to use traditional SAML-based federated identity in OAuth2 consept? | |
| * Will it work also in non-web context? | |
| * Peter, could you provide a link to further information here? | |
| * Code of Conduct to enforce data protection and appropriate use of personal data | |
| * https://wiki.edugain.org/Data_Protection_Code_of_Conduct_Cookbook | |
| Federated authentication role play | |
| https://www.icloud.com/sharedalbum/fi-fi/#B0PG4TcsmGUoKSk | |
| Demo, Questions & Answers | |
| * Library doesn’t necessarily need a separate agreement with each publisher. If a publisher already has a connection to a federation, a simple agreement can be made between the library and the publisher that the users of the library may benefit from the federated authentication to the service | |
| * Preconditions | |
| * Service Providers need to be a member in the federation | |
| * Authentication may be also provided on the proxy server and relayed to the publisher via custom methods suitable for the particular service | |
| * Parallel use is also possible. Legacy authentication can be used in addition to federated authentication at the same time (may be limited by the service implementation) | |
| * Also IP-based access can be used in paraller with previous | |
| * Moravian Library has implemented a identity connection service to link identities in a service that is based on Finnish Nelliportaali. In future the linking will be provided by a federation operator with a service based on Perun | |
| * https://perun.cesnet.cz/web/ | |
| * User chooses the authentication method, but the organisation provides the information about user affiliation or authorisation | |
| * Is it possible to form a federation of federations? To connect current authentication and access infrastructures together? Is it possible to make access to data collections easy so that researcher are able to find collections? | |
| * Federated access talked here is more about identity management | |
| * Interoperability of tools to access data is another level | |
| * eduGAIN and Kalmar interfederations have already implemented connections between European organisaions and even world wide. Similar connections between data management may be formed and have formed already. | |
| * FIM4R is already implementing solutions to data access and connecting different implementations together | |
| * Single logout has problems | |
| * SPs can force authentication which effectively disables SSO | |
| Wrap-up | |
| * Federated authentication is actually needed in libraries | |
| * Libraries have also other priorities | |
| * Benefit to better privacy protection is apparent |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment