IT Services will migrate spaces.ais.ucla.edu content to the Atlassian Confluence Cloud. Spaces will be in read-only mode after June 22nd.
UCTrust Workgroup
Child pages
  • Survey of ID mgrs - library issues

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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:
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:

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:
UCSF:
UCSB:Yes.Identity problems are directed to directoryhelp@isc.ucsb.edu. This is not a list.
UCSC:

3. What attributes does your campus commonly release via Shibboleth?

UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:
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:

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:
UCSF:
UCSB:There is no plan for local SPs. Special attribute requests will be handled by a committee.
UCSC:

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:
UCSF:
UCSB:N/A. We assume all SPs will come to us from a UC system wide perspective rather than a local one.
UCSC:



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:
UCSF:
UCSB:Yes when it goes live.
UCSC:

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:
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:

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 individuls or groups of individuals?

UCB:
UCD:
UCI:
UCM:
UCR:
UCLA:
UCSD:
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:

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:
UCSF:
UCSB:Unknown.
UCSC:



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:
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:

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:
UCSF:
UCSB:Again. I see SPs as a UC issue, not a UCSB issue.
UCSC:

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:
UCSF:
UCSB:No. I want other than UCSB to take responsibility for SPs.
UCSC:

  • No labels