As discussed at the 6/21/2010 UCTrust Conference Call, UC Trust principal contacts are . Refer to UC Trust - UC Libraries ad hoc working group -- Request for Info from UCTrust for context.
Background Info
1. What is your campus' single sign on solution?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:We use Shibboleth natively as our SSO solution.
UCSF:
UCSB:Currently, the WAM is Netpoint. It will become OpenSSO this fall. There is no current plan to use intra-campus Shibb technology.
UCSC:We are using Shibboleth natively as our SSO solution.
2. At your campus, should the library use the contact listed in http://www.ucop.edu/irc/itlc/uctrust/contacts.html for IdP questions?
a. Is there a campus mailing list for service issues and questions?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Yes. a) we use shibsupport@ucsd.edu.
UCSF:
UCSB:Yes.Identity problems are directed to directoryhelp@isc.ucsb.edu. This is not a list.
UCSC:Yes (there are alternates if necessary). We generally intake questions through help@ucsc.edu, which populates a trouble ticket that should be escalated to our group.
3. What attributes does your campus commonly release via Shibboleth?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:targetedID, affiliation and scopedAffiliation, mail, name attributes. We have a lot of ucsd specific attributes we release internally as well, which can sometimes be mapped to standard attributes.
UCSF:
UCSB:None yet. The design is for what I believe are the minimums mandated: ucnetid, uctrustcampusidshort, uctrustassurance, ucemployeeid, edupersonscopedaffiliation, edupersonprincipalname, sn, givenname, displayname, mail.
UCSC:We have on occasion released ePAffiliation (unscoped), ePPN, sn, givenname, mail, uctrustcampusidshort. We have other attributes available, but notable ones we do NOT have are: targetedID, entitlement management.
4. At your campus, how do we add new vendors to the Shibboleth list?
a. Is there a formal process to request a new SP be registered as the recipient of ID information via shibboleth?
i. Is there a form, and if so what is its location/URL?
ii. Does the process accommodate both campus service providers and external service providers (e.g. that the library sponsors or brokers)?
iii. How does the process accommodate requests for attributes not otherwise/previously released (e.g. the InCommon-Lib recommended use of eduPersonEntitlement, see below)
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:An email to shibsupport@ucsd.edu will get things started. Local SPs can use a form at https://a4.ucsd.edu/shibreg/docs
. If we decide that we can and should release a new attribute we take the time to implement it.
UCSF:
UCSB:There is no plan for local SPs. Special attribute requests will be handled by a committee.
UCSC:There is a form, but a request though our trouble ticket system is sufficient to initiate the process (help@ucsc.edu). Yes, we can accommodate external SPs; requires approval. Release of otherwise unreleased attributes is the same as release of existing, request is made, approval granted or not granted. Complexity of approval depends on sensitivity of the data and how it will be used.
b. How much lead time is needed to add a new SP - if only currently available attributes are needed? if new attributes are needed?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Generally less than 24 hours if no special attribute requirements. Otherwise it could take weeks to implement a new attribute.
UCSF:
UCSB:N/A. We assume all SPs will come to us from a UC system wide perspective rather than a local one.
UCSC:Generally a week or two to load a new SP with currently released attributes. Developing new attributes (not just unreleased ones, but ones we don't currently populate) depends entirely upon the requirements and prioritization.
Content vendors and InCommon*-Library Best Practices*
(assumes that the campus library or the CDL is the sponsoring agent for content vendors as 3rd party Service Providers)
5. Can you currently support an Attribute Release Policy that includes eduPersonScopedAffiliation?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Yes, although we don't currently assign anyone student@ucsd.edu. member, staff, and employee work.
UCSF:
UCSB:Yes when it goes live.
UCSC:Yes, though we do not currently populate the "member" value.
6. If your library provides a list of IP addresses for terminals/workstations available for "walk-in" use, can you implement the IPAddress authentication "handler" and assign a time-limited affiliation of "library-walk-in" for any authentication request from that terminal (see https://spaces.internet2.edu/display/SHIB2/IdPAuthIP)?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Yes, we could probably implement this.
UCSF:
UCSB:We currently use IP address verification through a proxy server. It is assumed that the proxy server will remain active until all Library vendors have converted to federating processes.
UCSC:We are planning to implement this in support of a local library application, so this should be fine.
7. Can you currently support an Attribute Release Policy that includes eduPersonEntitlement with a value of urn:mace:dir:entitlement:common-lib-terms for all faculty, staff, students, and library-walk-ins?
a. If not, please note the timing and conditions necessary in order to support eduPersonEntitlement.
b. Are you able to assert eduPersonEntitlement selectively for individuals or groups of individuals?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:We could for everyone except library walk ins at the moment. If we implement the previously mentioned IP address authentication, then walk ins would be okay.
UCSF:
UCSB:We do not have edupersonentitlement implemented. It would imply large scale deployment of custom processes for the delegated implementation that is appropriate to such a set of values. We have no funding for inventing those.
UCSC:We do not have such a value. We could probably implement the catch-all circumstance (all faculty, staff, students and library-walk-ins) using shib filters or some other process. We plan to support selective entitlement management in the future, but nothing is likely before the end of the year.
8. What information would you need about a content vendor or other 3rd party SP beyond what would be available in their InCommon certification?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:It depends on what attributes they want. If they want attributes we don't feel giving out to verdors, I'm not sure what sort of information or contract we would expect of them. If they want basic stuff, we might not ask for much at all, especially if the company is well known.
UCSF:
UCSB:Unknown.
UCSC:As UCSD. We would expect a campus (or UC) sponsor to make the request. We would probably be happier if the vendor had signed Appendix DS.
HathiTrust* as a test case (refer to* http://www.hathitrust.org/shibboleth*)*
9. Can you currently support HathiTrust's Attribute Release Policy that includes eduPersonScopedAffiliation, eduPersonTargetedID, and optionally, DisplayName?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Yes.
UCSF:
UCSB:No plan to at the moment. I would like to see the technical specs for a targetedid implementation and that every UC campus used the same spec. If not, we will probably avoid it.
UCSC:eduPersonTargetedID is not currently implemented at UCSC. Assuming release of ePPN was approved (would take some time to get the okay to do this) I believe we would be able to support the service.
10. As a specific case of question #6 above, what would you need from your campus library or the CDL to register HathiTrust as a SP?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Probably just need to know that they want it. An email would probably suffice.
UCSF:
UCSB:Again. I see SPs as a UC issue, not a UCSB issue.
UCSC:A request from a UCSC/UC sponsor would be best.
11. Is there anything about the implementation of HathiTrust as a SP that you would find useful to track in order to inform future requests from library-sponsored SPs?
UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:Probably not.
UCSF:
UCSB:No. I want other than UCSB to take responsibility for SPs.
UCSC:Not immediately.