2015-11-04 Meeting notes

Has data that will be relevant to our group:

https://docs.google.com/spreadsheets/d/107Z_9kV4_bAuDqfM5Go6Eg4Ky_e3_e7guf4XArgjO4c/edit#gid=0

• Marcus Mizushima from the Chancellor's Office joined the meeting
• Shibboleth Overview:
  • Shibboleth leverages an existing authentication mechanism (Shibboleth itself doesn't store usernames and passwords)
  • Each campus decides the best source for their authentication system (e.g., Active Directory)
  • When an application is configured to use Shibboleth, Shibboleth allows the user to authenticate and pass along additional information to the application
    • e.g., Not only do I want the userID, but I need the user's email address to authenticate
    • What if campus authentication mechanism does not provide user attributes?
      • Shibboleth returns the user's UserID which then matches with existing user profile information
      • Shibboleth has the ability to perform authentication against a source and retrieve attributes from a source
        • e.g., authentication against AD, but then go to PeopleSoft and retrieve attributes from PeopleSoft
      • Campuses may have done this differently. Marcus can send a list of things that are required (name parts, email address, telephone numbers optional, affiliation (fac/staff/student), employeeID, unique identifiers in case users are not in PeopleSoft)
      • No requirement to include active / non active status for students; but employees must have element if they have separated from the institution
• There are two parts we need to figure out:  
  • first: Alma will need user information first from PeopleSoft / Student Information Systems (SIS) loaded in on a regular basis; 
  • second: Shibboleth configuration for logging into Primo
• We have an opportunity to test this out early with the Vanguard campuses (San Jose, Northridge, and Fresno)
• Question: How to get data from campuses / PeopleSoft into Alma
  • Fresno: manual process - data files are retrieved from campus information systems
    • Two staff members that process the files and load them into Sierra
    • Beginning the semester, once mid-semester, and then it repeats itself
    • Not a daily / automated process
    • Believe it's a CSV file delivered via email
    • LDAP authentication; also use secondary layer with patron API
      • Checks patron API to see patron type and expiration date
      • Talks for Identity Management Solution underway - potentially purchased Microsoft product?
    • Will involve a few different staff
  • Northridge: semi-manual process
    • student information semi-automated as a tab-delimited file that is delivered to an FTP directory and further processed by scripts
    • Authentication: Campus LDAP with Millennium patron API similar to Fresno
    • Barcode not stored in PeopleSoft
  • San Jose:
    • Believe files are delivered monthly
    • Authentication done through the Millennium patron API (ILLiad)
• First task: Set up Shibboleth authentication for at least one (if not all three) campuses in the Vanguard load
  • Each vanguard campus needs to reach out to campus IT to schedule a call to discuss this
  • Schedule two different meetings: one about Shibboleth with Renaldo, Micah, and Lauren and each campus' primary identity contact as well as Marcus (Suzanna and Brian will also join)
• Second Task: Try and get patron data from one or more of the campuses
• Marcus can get a list of primary identity contacts for all of the campuses