Note: The POP is deprecated and replaced by Baseline Expectations for Trust in Federation
InCommon Federation Participant Operational Practices
...
University of California, Davis as of 27 23 January 20172018
(based on the POP submitted to InCommon on 19 July 2007; wording updated to the 8 Feburary 2008 InCommon POP template.)
...
Additional information about the Participant's identity management practices and/or privacy policy regarding personal information can be found on-line at the following location(s):
1.3 Contact information
The following person or office can answer questions about the Participant's identity management system or resource access management policy or practice.
...
More information can be found at the under UCD Computing Account Services FAQ.
2.2 "Member of Community" [#4] is an assertion that might be offered to enable access to resources made available to individuals who participate in the primary mission of the university or organization. For example, this assertion might apply to anyone whose affiliation is "current student, faculty, or staff."
...
2.4 What technologies are used for your electronic identity credentials (e.g., Kerberos, userID/password, PKI, ...) that are relevant to Federation activities? If more than one type of electronic credential is issued, how is it determined who receives which type? If multiple credentials are linked, how is this managed (e.g., anyone with a Kerberos credential also can acquire a PKI credential) and recorded?
Kerberos LDAP is the principal store of credential information. Secondarily, login IDs and password hashes are maintained in NIS maps (deprecated), LDAPKerberos, and Active Directory. The central accounts management system synchronizes password changes as necessary.
...
2.6 If you support a "single sign-on" (SSO) or similar campus-wide system to allow a single user authentication action to serve multiple applications, and you will make use of this to authenticate people for InCommon Service Providers, please describe the key security aspects of your SSO system including whether session timeouts are enforced by the system, whether user-initiated session termination is supported, and how use with "public access sites" is protected.
The campus employs both a home-grown legacy SSO ("DistAuth") and JA-SIG CAS. Both authenticate against the campus Kerberos service. Both employ configurable session timeouts in addition to a twenty-four hour Kerberos TGT timeout. Although both SSO services offer a limited form of Apereo CAS for single sign-on. It authenticates against the campus LDAP service, with failover to Kerberos. CAS session timeout is currently twelve hours. Though CAS supports user-initiated logout, clients are nonetheless strongly cautioned to close browser sessions when finished. InCommon Identity Providers will authenticate via JA-SIG The UC Davis SAML Identity Provider delegates SSO to CAS.
2.7 Are your primary electronic identifiers for people, such as "net ID," eduPersonPrincipalName, or eduPersonTargetedID considered to be unique for all time to the individual to whom they are assigned? If not, what is your policy for re-assignment and is there a hiatus between such reuse?
The UC Davis institutionally-unique identifier ("MothraID") is permanent, never reassigned, and is not reused.
A campus NetID ("Kerberos" login ID) is considered permanent as long as the client remains affiliated with the University, and the client does not rename the NetID. NetIDs no longer in use remain "locked" for a minimum of one year following removal, after which they may be reused.
Certain affiliates (faculty, staff, alumni), after separating from the University, are eligible to participate in an email-forwarding service. As long as they recommit once every two years using their campus NetID, they may maintain email forwarding indefinitely.The eduPersonTargetedID attribute is not currently available in production systems. Projects on the horizon will shortly mandate the use of one or both of these attributes. may maintain email forwarding indefinitely.
The eduPersonPrincipalName attribute, being composed from the campus NetID, may change if someone chooses to rename their NetID ("Kerberos" login ID). The eduPersonTargetedID attribute will be permanent, very likely algorithmically composed, and so not changable by the end user.
Electronic Identity Database
...
A sampling of applications which may employ electronic credentials can be found at in the UC Davis Computing Resources siteIT Service Catalog.
Attribute Assertions
Attributes are the information data elements in an attribute assertion you might make to another Federation participant concerning the identity of a person in your identity management system.
...
- Sympa Email List Server
- REDCap (Research Electronic Data Capture)
- Health System - Research Informatics Portal
4. Other Information
4.1 Technical Standards, Versions and Interoperability
...
[1
| Anchor | ||||
|---|---|---|---|---|
|
[2
| Anchor | ||||
|---|---|---|---|---|
|
[3
| Anchor | ||||
|---|---|---|---|---|
|
[4
| Anchor | ||||
|---|---|---|---|---|
|
eduPersonAffiliation as defined in the eduPerson schema. It is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., library privileges). "Member of Community" could be derived from other values in {{ eduPersonAffiliation "} or assigned explicitly as "Member" in the electronic identity database. See httphttps://www.educauseinternet2.edu/products-services/trust-identity/eduperson-eduorg/