Identity Management Integration with OLE
Identity Management Integration with OLE Tod Olson – University of Chicago Michelle Suranofsky – Lehigh University 12 November 2015
Identities: what do they do?
Authentication Authorization
Identity is about answering the questions: Who are you? What can you do?
2
Identities: within libraries
Traditionally 2 types:
Staff Patrons
Campus
Non-campus
3
Identities: OLE (KIM)
Traditionally 2 types:
Principals Staff members Can authenticate Entities Patrons
Exist within OLE but cannot authenticate 4
Identities: Interactions with OLE • Staff interactions with OLE
Direct access to OLE through the user interface Must be KIM Principal
• Patron interactions with OLE
No direct patron access Indirect access through discovery layer, external MyAccount features Only needs to be KIM Entity 5
Identity Management: Case Studies University of Chicago
Lehigh University
Loading Identities Keeping Identities in Sync Authentication November 11, 2015
Case Study: University of Chicago
7
University of Chicago • • • • • • • • •
Private research university Founded 1890 by John D. Rockefeller 5,724 undergraduate students 9,588 graduate, professional, and other students 2,205 full-time faculty Manager of Argonne and (in partnership) Fermilab 89 Nobel Prizes winners, including 6 current faculty "very high research activity” Library stats: • 6.6 million bibliographic records • 11 million items (9.6 mil. rows in item table) 8
UChicago: Goals
Leverage campus Identity Management (IdM) Campus CNetID for staff & patrons AuthN Accommodate non-campus patrons
9
UChicago: IdM Architechture
10
UChicago: Shibboleth AuthN Staff AuthN
Patron AuthN
HTTP Proxy IdP
VuFind
OLE Trust: Patron APIs
[Patron barcode] 11
UChicago: Staff AuthN
• LDAP KIM LDAP authN module • Shibboleth Proxy in front of OLE web application Shib-protect proxy Pass REMOTE_USER to OLE 12
UChicago: Patron AuthN
• Patron AuthN delegated to discovery layer • Discovery layer contacts OLE on behalf of patron Recall books, check account, etc. • Configure OLE APIs to trust from discovery layer host • APIs require patron ID (barcode) • Discovery layer responsible for AuthN Shibboleth, LDAP, etc. • Discovery layer uses IdM attributes for patron ID 1. Pull from IdM attributes, or 2. LookupUser by CNetID 13
UChicago: Campus Identities
• Feed from IdM system 180K persons total 27.8K after removing alumni • Custom loader Loads Staff and Patrons as Principals Staff privs will be assigned separately Patron borrower type derived from affiliation attributes • E.g. faculty, academic get indefinite loan • Reload daily: new, updates, deletes 14
UChicago: Maintaining Campus IDs
• Loader can insert, update and delete Principals • Each run handles onboarding, status changes, and termination • Nightly run, current w/in 24 hours Good enough for normal status updates Unusual situations handled manually • E.g. abrupt termination triggers manual removal of privs • AuthN denied at campus IdM level • Batch loader adequate for local needs 15
UChicago: Non-campus Patrons
• Loader can insert, update and delete Principals • Each run handles onboarding, status changes, and termination • Nightly run, current w/in 24 hours Good enough for normal status updates Unusual situations handled manually • E.g. abrupt termination triggers manual removal of privs • AuthN denied at campus IdM level • Batch loader adequate for local needs 16
UChicago: Non-campus Patrons
• Some outside of campus IdM Few special cases A few thousand legacy • Barcode and PIN in old system • High cost to convert • OLE barcode and PIN One-time batch load • VuFind: Choice Auth User chooses CNetID or barcode AuthN ILS driver checks barcode and surname match in OLE Credit to Anna Headley, Tri-Colleges 17
UChicago: Authorization
• Staff roles & perms entirely in OLE Grouper integration possible by overriding KIM services, but not currently using • Patron authorization Batch process concerns if dynamic Abrupt termination of privs are manual • Nightly IdM feed good enough
18
UChicago: Summary
• Use IdM directly for Authentication • AuthZ: rely on batch loads Staff entitlements are controlled in OLE Campus patrons controlled mainly by IdM attributes Nightly load good enough Abrupt removal of privs handled specially
19
Case Study: Lehigh University
20
Lehigh University •Private research university •Founded 1865 •About 70 miles north of Philadelphia •4,800 undergraduate •2,300 graduate students •500 full-time faculty •40 Library Staff members •Two libraries •1,000,000+ Bibliographic Records 21
Lehigh: Goals •Leverage our existing campus identity management infrastructure •Streamline our process of keeping patron information current •Authentication using existing Lehigh user id and password/LDAP •Accommodate Lehigh and non-campus patrons – Friends of Libraries
November 11, 2015
Lehigh: Preparation – Data Analysis • Circulation Manager worked with IdM team to define necessary patron data elements • Patron types were simplified to align more closely with IdM • Understand roles and permissions within OLE and decide which roles each staff member needs to perform their work November 11, 2015
Lehigh: Initial load of patron records into OLE Existing Library System Extract
Identity Management Extract
Custom Loader
OLE
Extract patron records from IdM Extract patron records from SIRSI Custom loader : Combines IdM export and information from our existing library system .
Lehigh University Which patrons are library staff? Library Staff and Roles in OLE
Custom Loader
OLE
25
Lehigh: Maintaining Patron Information
26
Lehigh: Maintaining Patron Information Staff AuthN
Patron AuthN
HTTP Proxy
LDAP
VuFind
OLE Trust: Patron APIs
[Patron barcode] 27
28
Identities: what do they do?
Authentication Authorization
Identity is about answering the questions: Who are you? What can you do?
2
Identities: within libraries
Traditionally 2 types:
Staff Patrons
Campus
Non-campus
3
Identities: OLE (KIM)
Traditionally 2 types:
Principals Staff members Can authenticate Entities Patrons
Exist within OLE but cannot authenticate 4
Identities: Interactions with OLE • Staff interactions with OLE
Direct access to OLE through the user interface Must be KIM Principal
• Patron interactions with OLE
No direct patron access Indirect access through discovery layer, external MyAccount features Only needs to be KIM Entity 5
Identity Management: Case Studies University of Chicago
Lehigh University
Loading Identities Keeping Identities in Sync Authentication November 11, 2015
Case Study: University of Chicago
7
University of Chicago • • • • • • • • •
Private research university Founded 1890 by John D. Rockefeller 5,724 undergraduate students 9,588 graduate, professional, and other students 2,205 full-time faculty Manager of Argonne and (in partnership) Fermilab 89 Nobel Prizes winners, including 6 current faculty "very high research activity” Library stats: • 6.6 million bibliographic records • 11 million items (9.6 mil. rows in item table) 8
UChicago: Goals
Leverage campus Identity Management (IdM) Campus CNetID for staff & patrons AuthN Accommodate non-campus patrons
9
UChicago: IdM Architechture
10
UChicago: Shibboleth AuthN Staff AuthN
Patron AuthN
HTTP Proxy IdP
VuFind
OLE Trust: Patron APIs
[Patron barcode] 11
UChicago: Staff AuthN
• LDAP KIM LDAP authN module • Shibboleth Proxy in front of OLE web application Shib-protect proxy Pass REMOTE_USER to OLE 12
UChicago: Patron AuthN
• Patron AuthN delegated to discovery layer • Discovery layer contacts OLE on behalf of patron Recall books, check account, etc. • Configure OLE APIs to trust from discovery layer host • APIs require patron ID (barcode) • Discovery layer responsible for AuthN Shibboleth, LDAP, etc. • Discovery layer uses IdM attributes for patron ID 1. Pull from IdM attributes, or 2. LookupUser by CNetID 13
UChicago: Campus Identities
• Feed from IdM system 180K persons total 27.8K after removing alumni • Custom loader Loads Staff and Patrons as Principals Staff privs will be assigned separately Patron borrower type derived from affiliation attributes • E.g. faculty, academic get indefinite loan • Reload daily: new, updates, deletes 14
UChicago: Maintaining Campus IDs
• Loader can insert, update and delete Principals • Each run handles onboarding, status changes, and termination • Nightly run, current w/in 24 hours Good enough for normal status updates Unusual situations handled manually • E.g. abrupt termination triggers manual removal of privs • AuthN denied at campus IdM level • Batch loader adequate for local needs 15
UChicago: Non-campus Patrons
• Loader can insert, update and delete Principals • Each run handles onboarding, status changes, and termination • Nightly run, current w/in 24 hours Good enough for normal status updates Unusual situations handled manually • E.g. abrupt termination triggers manual removal of privs • AuthN denied at campus IdM level • Batch loader adequate for local needs 16
UChicago: Non-campus Patrons
• Some outside of campus IdM Few special cases A few thousand legacy • Barcode and PIN in old system • High cost to convert • OLE barcode and PIN One-time batch load • VuFind: Choice Auth User chooses CNetID or barcode AuthN ILS driver checks barcode and surname match in OLE Credit to Anna Headley, Tri-Colleges 17
UChicago: Authorization
• Staff roles & perms entirely in OLE Grouper integration possible by overriding KIM services, but not currently using • Patron authorization Batch process concerns if dynamic Abrupt termination of privs are manual • Nightly IdM feed good enough
18
UChicago: Summary
• Use IdM directly for Authentication • AuthZ: rely on batch loads Staff entitlements are controlled in OLE Campus patrons controlled mainly by IdM attributes Nightly load good enough Abrupt removal of privs handled specially
19
Case Study: Lehigh University
20
Lehigh University •Private research university •Founded 1865 •About 70 miles north of Philadelphia •4,800 undergraduate •2,300 graduate students •500 full-time faculty •40 Library Staff members •Two libraries •1,000,000+ Bibliographic Records 21
Lehigh: Goals •Leverage our existing campus identity management infrastructure •Streamline our process of keeping patron information current •Authentication using existing Lehigh user id and password/LDAP •Accommodate Lehigh and non-campus patrons – Friends of Libraries
November 11, 2015
Lehigh: Preparation – Data Analysis • Circulation Manager worked with IdM team to define necessary patron data elements • Patron types were simplified to align more closely with IdM • Understand roles and permissions within OLE and decide which roles each staff member needs to perform their work November 11, 2015
Lehigh: Initial load of patron records into OLE Existing Library System Extract
Identity Management Extract
Custom Loader
OLE
Extract patron records from IdM Extract patron records from SIRSI Custom loader : Combines IdM export and information from our existing library system .
Lehigh University Which patrons are library staff? Library Staff and Roles in OLE
Custom Loader
OLE
25
Lehigh: Maintaining Patron Information
26
Lehigh: Maintaining Patron Information Staff AuthN
Patron AuthN
HTTP Proxy
LDAP
VuFind
OLE Trust: Patron APIs
[Patron barcode] 27
28
