Legend:
Status | ||
---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Page Properties | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
|
Recommendation
[Vanguard/test] Scenario 7: Shib ‘proxy’ service (managed by UCOP ITS): Use UCOP ITS “Shib proxy” (connects all UC shib directories (recommended by CDL IT liaison)
Is there extra work for campuses to do this? (Greg F. can check with his great! NetOps person )
Background
Alma (including network zone) requires a 3rd party authentication to login to the system. In order to login to the Alma network zone, the site (campus or CDL) 's authentication will need to integrate with the NZ. All sites that should have access into the NZ environment will need to have their authentication integrated with the NZ.
Dependencies
UCOP (CDL) and UCSD (SCP) staff manage UC-wide services; both sites need authentication within the NZ. (may depend on SCP, SFX, and related resource records handling for eResource records in NZ - VANGUARD )
Single UC-wide patron record database or separate institutional patron databases? (PDCG) : if there is a shared patron database in NZ, this may require more sites (besides CDL & UCSD) to have access to the NZ
how many authentication integrations can NZ have? (posed to ExL May 8 ; answer May 14 ): “technically feasible, but has not been attempted; will double config & maintenance for campus IdP; will double config time for ExL”; ExL answer May 14: “Staff members who perform "Central office" tasks from the UCSD site or anywhere else can have internal accounts that use Alma authentication or social authentication whichever method you prefer to use.”
Any conflicts arising from same authentication integrated at both IZ & NZ (for non-UCOP sites) ExL answer May 14: will double config & maintenance required for campus IdP; (question to pose to campus IdP for those wanting access to NZ): limitations / conflicts within campus IdP depends on campus system.
Answer needed for “3rd party integrations” due to ExL May 29th.
Questions to consider
Who (aside from those staff directly managing UC-wide services), if any, should have direct access to network zone instance?
Does the Ex Libris Identity Service suffice for NZ accounts? (Is SAML at either UCOP or UCSD needed for CDL staff?)
Consider if any required tasks could be accomplished in IZ (not requiring direct access to NZ, eg. updating shared NZ bibliographic records can be done in IZ)
What kind of financial information are we putting in the NZ; where is that info coming from / managed (UCOP / CDL / UCSD - who needs access to it)?
Adrianna (CDL @UCSD)
??
Assumptions
CDL staff in Oakland (D2D and CollDev) and staff at UCSD (SCP, Shared Acq, etc) will need access to the NZ (100% sure)
Tier-2 champions at UC campuses will need access to part of the NZ (90% sure)
Occasional UC contractors will need access (50% sure) - very rare
Other campus acq staff will need access (Not sure at all)
Not very many people in total will need access in any of these scenario (20-50?)
We know all the people, they will be “known entities” named people. No surprises.
Internal accounts would require some extra management;
Any of these accounts require some amount of management - is the internal account option that much more?
Scenarios
UCOP shib (for existing UCOP accounts) + internal accounts (for anyone else) = Depends on level of security needed - need to ask Kurt (5/22 - current best guess)
UCOP shib only, make new UCOP accounts = We don’t know - need to ask Kurt (5/22 - next easiest thing?)
No authentication, internal accounts only = Depends on level of security needed - need to ask Kurt
This becomes a layer of management - manually monitoring / managing these accounts
UCOP shib + UCSD auth (two types of authentication) = ATTEMPT? we could try
UCOP auth + UCSD auth+ any other campus auth who needs it = See above “technically feasible, but not attempted” (ExL)
UCOP shib only staff, no new accounts= NOT a thingShib ‘proxy’ service (managed by UCOP ITS): connects all UC shib directories (recommended by CDL IT liaison)
What is the best scenario for the Vanguard? Do we want to confirm that the “easiest” thing is doable, vs. do we want to take this opportunity to test a more complicated thing? into one interface) for NZ authentication.
Background
Authentication for accounts to NZ could use either Shibboleth or Ex Libris Identity Service authentication method. Since CDL’s main office is split between those with Shibboleth accounts at UCOP and Shibboleth accounts at UCSD, authentication into the NZ needs to support both types of users. Shibboleth login is more secure and would support SSO for staff logging into the NZ. The UCOP ITS’s Shibboleth proxy service would enable a single integration point with Alma for all UC Shibboleth sites, negating the need for campus Shibboleth services to integrate with both their campus IZ and the NZ.
Dependencies
Questions to consider
Assumptions
Scenarios
Action Log
Action/Point Person | Expected Completion Date | Notes | Status |
---|---|---|---|
Ask Kurt E. about the scenarios above Alison Ray (CDL) | 5/26/2020 | AMR met with Kurt E about scenarios; Kurt recommended UCOP’s shib proxy service | done |
Ask CDL ERT about who needs access to financial info Alison Ray (CDL) | assumption: those needing access to financial information will need secure (eg. Shibboleth) Alma authentication.|||