Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Legend:
Status
titlenot started
Status
colourYellow
titleIN PROGRESS
Status
colourRed
titleSTALLED
Status
colourGreen
titledecided
Page Properties
label

IC Alison Ray + Caitlin Nelson will research and create a recommendation or several recommendations; Greg F. at UCSD needs to be consulted; UCOP IT needs to be consulted; UCSD SCP/Shared Acq need to be consulted.

ICs will discuss the recommendations and make a decision.

Status

Status
colourYellow
titlein progress

Description

Access into Network Zone environment (Vanguard)

Decision

Owning group

Implementation Coordinators (SILS-IC-L@listserv.ucop.edu)

Approver

Stakeholders

R = ICs
A = ICs
C =
I =

Decision-making process

Priority

Due date

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

  1. Who (aside from those staff directly managing UC-wide services), if any, should have direct access to network zone instance?

  2. Does the Ex Libris Identity Service suffice for NZ accounts? (Is SAML at either UCOP or UCSD needed for CDL staff?)

  3. ExL’s list of tasks requiring access to NZ environment

  4. 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)

  5. 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)?

    1. Adrianna (CDL @UCSD)

    2. ??

Assumptions

  1. CDL staff in Oakland (D2D and CollDev) and staff at UCSD (SCP, Shared Acq, etc) will need access to the NZ (100% sure)

  2. Tier-2 champions at UC campuses will need access to part of the NZ (90% sure)

  3. Occasional UC contractors will need access (50% sure) - very rare

  4. Other campus acq staff will need access (Not sure at all)

  5. Not very many people in total will need access in any of these scenario (20-50?)

  6. We know all the people, they will be “known entities” named people. No surprises.

  7. Internal accounts would require some extra management;

    1. Any of these accounts require some amount of management - is the internal account option that much more?

Scenarios

  1. 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)

  2. UCOP shib only, make new UCOP accounts = We don’t know - need to ask Kurt (5/22 - next easiest thing?)

  3. No authentication, internal accounts only = Depends on level of security needed - need to ask Kurt

    1. This becomes a layer of management - manually monitoring / managing these accounts

  4. UCOP shib + UCSD auth (two types of authentication) = ATTEMPT? we could try

  5. UCOP auth + UCSD auth+ any other campus auth who needs it = See above “technically feasible, but not attempted” (ExL)

  6. UCOP shib only staff, no new accounts = NOT a thing

  7. Shib ‘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

Ask ERT about who needs access to financial info Alison Ray (CDL)

Action/Point Person

Expected Completion Date

Notes

Status

Ask Kurt E. about the scenarios above Alison Ray (CDL)