ARPs

Attribute Release Control

  • Each Application has exactly one responsible party. A responsible party may have many applications
  • An Attribute Release Policy (ARP) may be assigned to many applications. An application may have more than one ARP
  • An ARP may release multiple attributes. An attribute may be released via many different policies
  • Many attributes may come from a particular attribute source. Each attribute comes from exactly one source

Attribute Release Policy Control

  • Request ARP for an application through Application Security role
  • Approved Application is assigned a URN and binding of Responsible party, application and URN is recorded.
  • XML is generated by Shibboleth IDP
  • XML is installed by Shibboleth SP
  • Test and refine as needed

ARP Goals

  • Simple policies
  • Small set with large coverage
  • Reduce the need for other access to enterprise systems, LDAP piercing, UF DIR API
  • Reduce the need for local storage of attributes
  • Facilitate simple applications

ARP Notes

  • Each attribute is vended from a known, single source regardless of ARP. The source for each attribute is described in a separate document
  • ARP-LOA and ARP-GLID can be used to provide current GLAUTH capability
  • Attribute values obtained through Shibboleth are for the purposes of authorization and facilitation of the end user’s session. They are not to be stored locally or shared in any way
  • If additional attributes or attribute release policies are needed, please contact the IAM office IAM staff will work with you to make sure you have the information you need for your application
  • Many applications will need more than one ARP. This does not add complexity to the service provider, all attributes returned by Shibboleth come in a single set regardless of the number of ARPs involved
  • If a group of ARPs are commonly requested together, IAM staff may choose to provide “combo” ARPs to simplify administration
  • If an attribute is listed as multivalued, the separator will be a dollar-sign($). The only exception to this is UFAD Groups (UFADGroupsDN), which uses a semi-colon as a separator

Back to top

Shibboleth Attributes Released with Each ARP

Each attribute is declared as a CGI variable. The name of the CGI variable is shown below in parentheses following the attribute name. Some web servers will prepend “HTTP_” to the variable names.

  • ARP-CID

    Used by applications which need to track user preferences and data between sessions

    Attributes

    • Computed ID (persistent-id)

    Notes

    • Computed ID(CID) is an opaque identifier which cannot be reverse engineered by the recipient. The IDP can identify an individual from a CID for law enforcement purposes
    • The CID is vended for supporting end user settings at the application level. It should be stored and used as a primary key for applications that need to “remember” preferences for end users. Information provided by end users to the application can be stored and keyed using CID
    • CID does not change for a particular individual using an application

    Back to top

  • ARP-LOA

    Used by applications that want to know the level of assurance of the individual credentials requesting service. This ARP attribute set provides an internal University of Florida value and a value that represents InCommon EduPerson attribute for use with credential federations.

    Attributes

    Level of Assurance (ufLoa) values:

    • Invalid
    • Self-Aasserted
    • Guest
    • Basic
    • Bronze
    • Silver
    • UFM

    This is a local University of Florida assurance variable, to be used for services as a basic attribute of strength on university-based applications. Invalid indicates that the minimal information for the identity record is not populated, this generally means that the business email or the DOB are missing from the IdM registry.The university is thus unable to provide any defined level of assurance related to the account. SP should assume the account is not a strong credential.Use with this known risk.

    Federated Level of Assurance (eduPersonAssurance) values:

    • http://id.incommon.org/assurance/silver
    • http://id.incommon.org/assurance/bronze
    • urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

    eduPersonAssurance definition:
    OID: 1.3.6.1.4.1.5923.1.1.1.11

    RFC 2252 definition:
    ( 1.3.6.1.4.1.5923.1.1.1.11

    NAME ‘eduPersonAssurance’

    DESC ‘eduPerson per Internet2 and EDUCAUSE’

    EQUALITY caseIgnoreMatch

    SYNTAX ‘1.3.6.1.4.1.1466.115.121.1.15’ )

    Application utility class: extended; # of values: multi

    Definition

    Set of URIs that assert compliance with specific standards for identity assurance for a federated access.

    Notes

    This multi-valued attribute represents an identity assurance profile (IAP), which is the set of standards that are met by an identity assertion, based on the Identity Provider’s identity management processes, the type of authentication credential used, the strength of its binding, etc. Such standards may be based on national standards, state standards, regional standards, federation standards, or even organizational standards. Examples of such standards are the NIST SP 800-63 levels of assurance, the InCommon Federation’s bronze and silver IAPs, etc.

    The URI will be clearly documented at the broadest possible level (nation, federation, state, university system, etc). Relying parties can use the asserted value(s) to access official on-line documentation for the IAP(s). For example, if the asserted value is a URL, then accessing the http/https URL will give a complete description of the IAP. Likewise, if the asserted value is a URN, then accessing the naming registry for that URN namespace will yield a full description of the IAP. For example, the IANA URN registry (http://www.iana.org/assignments/urn-namespaces) lists all registered URN namespaces, with the urn:mace namespace being one of those listed. Unfortunately, the IANA page does not link to on-line registries for the list, but most have such on-line registries and are easily found by search engines. The urn:mace namespace registry is available on-line (http://middleware.internet2.edu/urn-mace/urn-mace.html) and also has links to on-line documentation for the delegated registrations it manages within that namespace.

    Resource providers only need to parse the asserted attribute values and look for one that is trusted by the resource provider to determine the Identity Provider’s asserted compliance with the standard. In addition, the Resource Provider may need a mechanism to determine a given Identity Provider’s qualification to assert specific values for eduPersonAssurance.

    The driving force behind the definition of this attribute has been the need for applications to understand the various strengths of different identity management systems and authentication events and the process and procedures governing their operation and to be able to assess whether or not a given transaction meets the requirements for access.

    Examples:
    eduPersonAssurance: urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
    eduPersonAssurance: urn:mace:nih.gov:basic:sample
    eduPersonAssurance: http://idm.example.org/LOA#sample coming soon.

    Example applications for which this attribute would be useful:
    Determining strength of asserted identity for on-line transactions, especially those involving more than minimal institutional risk resulting from errors in authentication.

    Example (LDIF Fragment):
    eduPersonAssurance: urn:mace:incommon:IAQ:silver

    Syntax: directoryString;

    Notes

    Level of Assurance (LOA) indicates the certainty of the association of an individual and an identity credential. UF changed this ARP on March 4 2012. The former was a simple internal attribute that used a value of 1 or 2. This is now replaced with an internal UF attribute and the standard EduPerson value for use in federation. Currently the only federated values supported are those for InCommon federation. The InCommon Silver Certification should be available during the 2nd quarter of 2012.

    Back to top

  • ARP-Affiliations

    Affiliations are the relationship between a member of the UF community and an organizational unit of the University represented by an eight-character department code. There are roughly forty different university affiliations maintained within the Identitry Registry directory. These aggregate into the eduPerson Affiliation. Both of these are multi valued so that a person can have multiple affiliations. The Primary affiliation is algorithmically determined within the Identitry Registry directory application. See note below regarding anomalies that can occur in using the primary affiliation. Information related to the affiliations is maintained at UF Identity Registry Affiliations UF Identity Registry Affiliations.

    Attributes
    • Primary Affiliation (primary-affiliation)
    • EduPerson Affiliation (eduperson_affiliations)
    • UF Affiliations (uf_affiliations)

    Notes

    • EduPerson and UF Affiliations are potentially multi-valued. All values for the individual are returned. See the UF Identity Registry Affiliations UF Identity Registry Affiliations reference for mappings and additional info on affiliations
    • Use of affiliations for controlling access to resources is sufficient for many applications. Applications that need to restrict access to “faculty, staff, and students” should use the EduPerson Affiliations and obtain a consistent result with other applications across campus. This consistency is important to the end-user
    • Use of affiliations as surrogate for roles can be problematic. Roles provide fine-grained control of access and can be added and removed based on need. Affiliations cannot be added and removed affiliations are “facts” about a person. They cannot be manipulated for access control purposes. For example, if an application authorizes “students,” but an honor court or other restriction must be put in place for a particular student, the student affiliation cannot be removed to satisfy the access requirements. Roles can be removed in such cases. Managing access by roles is preferred when exceptions are common. Managing by exception (all students other than those on an application exception list) is preferred when exceptions are rare
    • Use of Primary affiliation can produce unsatisfactory results since it is not multi-valued. Consider an employee who is a student. Only one value can be returned. Consider using the eduPerson value since it is multi-valued.

    Back to top

  • ARP-GLID

    Provides the “named list of users” functionality of GLAUTH allow=(x, y, ..,z). Units are encouraged to move to alternate methods of authorization. Maintaining named lists of users requires significant effort. GatorLink Usernames can change leading to unauthorized access. Many other groupings of users are available which may be preferable.

    Attributes

    • GatorLink username (glid)
    • UF Business Email Address (mail)
    • EduPerson Principle Name (eppn)

    Notes

    • The GatorLink username is 1-16 characters. It does not contain “@ufl.edu”. It is not an email address. To contact the user via email, always use the business email address. Never construct an email address from the GatorLink username.
    • The UF Business Email Address value is provided for all users. It may be blank for some users.

    Back to top

  • ARP-UFID

    Some processes require UFID for authorization, identification and matching to other university processes.

    Attributes

    • UFID (ufid)

    Notes

    • The UFID is protected information and is not displayed outside the transaction in which it occurs. FERPA protection applies to UFID
    • The UFID is not required for many transactions. Requests for UFID will be reviewed regarding intended purpose
    • The UFID does not change and is never reused
    • Keying data systems on UFID is strongly preferred over keying systems on GLID. Applications that do not need to share data about individuals should use CID to preserve privacy and avoid contact with unnecessary protected information

    Back to top

  • ARP-Roles

    Provides information needed to authorize Staff and Members. For more info related to specific roles see the Security Roles reference page. A complete listing of roles is available and maintained on the End & Core User Roles pages. For additional information regarding roles and how to use this attribute contact the IAM group at Enterprise systems.

    Attributes

    • PeopleSoft Roles (UFAD_PSRoles)
    • Dept ID (departmentNumber)
    • Network Managed By (netmanaged_by)

    Notes

    • PeopleSoft roles are multi-valued. Many people have over 50 such roles each.
    • The primary department ID is the “derived within the Identity Registry? Affiliations also contain a department id for the specific relationship. You should consider closely which is most appropriate for your Service.
    • Network Managed By indicates the unit managing the UF Active Directory OU and workstation access . This doesn’t necessarily indicate the person is a member of that department.

    Back to top

  • ARP-Groups

    Attributes

    • UFAD Groups (UFADGroupsDN)

    Notes

    • Departments can create and manage groups in Active Directory. This can be used for a wide variety of applications
    • These groups are not to be redundant with other groupings such as membership in roles, affiliations, and course sections
    • The UFAD Groups (UFADGroupsDN) attribute only contains groups in which the user is directly a member. It does not contain any nested group memberships

    Back to top

  • ARP-Contact Information

    Attributes

    • EduPerson Principal Name (eppn)
    • Directory Name (cn)
    • Business Name (businessName)
    • Given Name (givenName)
    • Surname (sn)
    • Middle Name (middleName)
    • Postal Address (postalAddress)

    Notes

    • The university maintains many kinds of contact information for individuals. A separate document describes the various kinds of contact information and when each is appropriate

    Back to top

  • ARP-Enrollment

    Provides information required to authorize student access related to enrollment in a specific course or section. This data is FERPA sensitive and should not be stored by your service. This ARP should be used to confirm membership in a course section and to allow access via the shibboleth assertion in the SAML document to resources reserved for members of the course section. It also provides knowledge to the membership status for a course section such as Lerner or Instructor.

    Attributes

    The following is a list of the course enrollment academic information available through Shibboleth from the University of Florida identity provider service.

    Full Name Default Header (2.x) Datatype Multi
    urn:oid:1.3.6.1.4.1.5923.1.6.1.1 (eduCourseOffering) HTTP_EDUCOURSEOFFERING URI Y
    urn:oid:1.3.6.1.4.1.5923.1.6.1.2 (eduCourseMember) HTTP_EDUCOURSEMEMBER Role@URI Y

    eduCourseOffering attribute

    Formal Definition
    http://middleware.internet2.edu/courseid/docs/internet2-mace-dir-courseid-educourse-ldap-200507.html

    Description
    Multiple values, each a URI, representing active enrollment in a university course and/or section offered in a specific academic term.

    Notice: This document describes format beginning 2018 Fall Term.  A view of this documentation prior to Fall 2018 may be found at the Internet Archive.

    UF-Specific Information
    This attribute carries distinct values that map to the course and section level, so either level of granularity can be used. The format of UF’s eduCourseOffering values is as follows:

    Section Enrollment:
    urn:mace:ufl.edu:section:TERM:COURSE:SECTION:BEGINDATE:ENDDATE:CLASSNBR
    TERM
    Described as YYYYT.CO.# – indicating academic term of enrollment (e.g. Traditional Fall 2018 = 20188.UF.0)
    YYYY – Year
    T – Term
    CO – College Indicator (UF = Registrar)
    # – Sequence number
    NOTE: Intra-term codes for traditional summer terms are always published as Summer YYYY C/A/B Terms = “YYYY8.UF.0”, “YYYY8.UF.1”, “YYYY8.UF.2” respectively
    COURSE
    Course name as designated in Course Catalog (e.g. ENC1101).  Please use as a string of arbitrary length.
    SECTION
    The section number (character string as listed in the Schedule of Courses).  Please use as a string of arbitrary length.
     BEGINDATE
    The first day of class for the TERM.
    ENDDATE
    The last day of class for the TERM.
    CLASSNBR
    The class number (character string as listed in the Schedule of Courses).  Please use as a string of arbitrary length.

    Currently, student enrollment for a window of roughly three terms (previous, current, next) is reflected in the values asserted for this attribute. Previous or future enrollment outside of this window will not be available.
    Example data:
    –example data
    –“20188.UF.0:ADV3920C:3H21:2018-08-22:2018-12-05:22080”
    –“20188.UF.0:EDE6948:3H57:2018-08-22:2018-12-05:22120”
    old format prior to Fall 2018:
    –“201201.UF.0:ANT4930:079A:2012-01-09:2012-04-25”

    Usage Notes
    These values are encoded as shown above so that you can determine what value to associate with course-specific application rules. They should not in general be parsed or interpreted based on the structure or content of the values, but simply compared as strings. For example, do NOT use pattern matching to identify “all the Physics courses”, because the encoding rules may change in the future.

    eduCourseMember

    Formal Definition
    http://middleware.internet2.edu/courseid/docs/internet2-mace-dir-courseid-educourse-ldap-200507.html

  • Excerpt from Internet2 MACE:The set of role types that a Person can have for their Memberships. The core vocabulary is: (those in BOLD will be supported at UF after this pending upgrade)
    · Learner
    · Instructor
    · ContentDeveloper
    · Member
    · Manager
    · Mentor
    · Administrator
    · TeachingAssistant
    · Officer
    Rule B.1-01: Learner – the role of someone undergoing some form of formal learning;
    Rule B.1-02: Instructor – the role as teaching instructor for learning material presented through the Membership;
    Rule B.1-03: ContentDeveloper – the role as an author of content for learning material presented through the Membership;
    Rule B.1-04: Member – the role as a Member of the associated Membership;
    Rule B.1-05: Manager – the role as manager of the Group for which Membership is being defined;
    Rule B.1-06: Mentor – the role as a personal mentor of other individuals in the Membership;
    Rule B.1-07: Administrator – the role as formal administrator in the Membership;
    Rule B.1-08: TeachingAssistant – the role as teaching assistant to an Instructor in the Membership;
    Rule B.1-09: Officer – the role as an officer of organization e.g. Chair, Secretary, etc in the Membership.Description
    Multiple values, each containing a role, ‘@’, and a URI, representing a role-based relationship with a university section offered in a specific academic term.
    UF-Specific Information
    The URI portion of the attributes values is defined as with the eduCourseOffering attribute above.
    The role portion currently consists of only the following role values:
    “Learner” for students
    “Instructor” for all instructional roles
    “TeachingAssistant” for all TA roles
    –Example data
    “Learner@20188.UF.0:PHA6637:3G65:2018-08-22:2018-12-05:22035”
    “Instructor@20188.UF.0:IND5466:046E:2018-08-22:2018-12-05:18344″
    “TeachingAssistant@20188.UF.0:IND5466:046E:2018-08-22:2018-12-05:18344″
    –Old format prior to Fall 2018:
    “Learner@201201.UF.0:LIN3201:005E:2012-01-09:2012-04-25”
    “Learner@201201.UF.0:AST1022L:0432:2012-01-09:2012-04-25”
    “Instructor@201201.UF.0:AST1022L:0432:2012-01-09:2012-04-25″
    “TeachingAssistant@201201.UF.0:ANT4930:079A:2012-01-09:2012-04-25″

    Usage Notes
    The difference between this attribute and eduCourseOffering is that the URI values there are implicitly treated as being associated with the logged-in user as a student. This attribute adds a “Role@” prefix to each URI that allows each relationship to be identified as student or instructor. An instructor that is also taking classes (as many graduate students do) will often contain both kinds of roles in his/her set of values.

    Back to top

Proposed and Future Attributes

  • ARP-Certifications (proposed)

    Attributes
    • Certifications
    Notes
    • The certifications are expected to be one field, multi-valued, containing all certifications
    • This ARP may not be needed if all certifications are implemented as roles or arbitrary groups

  • ARP-Academic Structure (future)

    Attributes

    • College
    • Major(s)
    • Minor(s)
    • Classification

    Notes

    • All academic structure information is current as of the login of the user. Academic structure is empty for non-students
    • College is the college offering the degree the student is seeking
    • Classification is of the form “3LS,” where the digit represents program level and the characters represent program

Back to top