1 / 14

Directory Policy, Privacy, etc.

Directory Policy, Privacy, etc. David Millman – Columbia Keith Hazelton – Wisconsin et al. Agenda. context—2 slides what is our job? applications discussion current (1-4) planning (5-7). Context 1 What part is the job of central IT ?.

donoma
Download Presentation

Directory Policy, Privacy, etc.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Directory Policy, Privacy, etc. David Millman – Columbia Keith Hazelton – Wisconsin et al

  2. Agenda • context—2 slides • what is our job? • applications • discussion • current (1-4) • planning (5-7)

  3. Context 1What part is the job of central IT ? • Relationships with other univ “data-managing” efforts (ID cards, HR, Registrar, Admissions, Facilities, etc) • Relationships with other campus “security” efforts (secure desktops, univ-wide encryption standards, publicity/awareness, etc) • Relationships with third-parties (licensed library db's, purchasing, government, distance ed, etc) • Requirements for underlying directory services. Management tools for administrators and end-users. Process around / desirability of data feeds.

  4. Context 2Applications that use directory data • How transparent policy? (e.g., only for emergencies, only for academic reasons, methods for communication of policy) • How consistent? (e.g., common group/attribute definitions vs shadow systems) • How granular? (e.g., use of most specific attributes, blanket yes/no vs degrees of service) • How are attrib release policies determined?

  5. Discussion questions 1Current Situation • Define and explore the roles of data custodians, service providers, and technologists. Example coordination strategies? Who on campus is responsible for setting directory policy? The IT org, or some broader group? Is the directory still viewed as an IT toy, or as an institutional asset? • UW-Madison CIO Office channels issues and recommendations as appropriate; may go to number of campus bodies • AuthNZ Coordinating Team (ACT) recognizes, clarifies and offers recommendations on identity management (IdM) policy/process issues to CIO Office and others; ACT has both DoIT & campus members.

  6. Discussion questions 1aCurrent Situation • (cont) Define and explore the roles of data custodians, service providers, and technologists. Example coordination strategies • Per Provost & VP for Admin, Identity Management Leadership Group (IMLG) is to be the new standing body (replacing a few others, includes DoIT & campus reps) • Took 2.5 years to get stakeholders in sync wrt policy leadership by data custodians; technical leadership by DoIT (e.g., Populations, Affiliations and Service Entitlements, PASE). • Role of service providers? A work in progress… • But other issues may need to go to formal shared-governance body, Information Technology Council (ITC) • With increasing input from MTAG (IT reps from local units) -- individuals who increasingly contribute to our working committees

  7. Discussion questions 2Current Situation • What data (attributes) goes into the directory? What process is used to collect requests to add data, and make decisions? • UW-Madison Access to Data (A2D) group pays attention to the stream of requests; forwards issues, recommendations to ACT • A2D includes DoIT & campus reps • ACT follows established workflow to get resolution (see previous slide)

  8. Discussion questions 2aCurrent Situation • (cont) What data (attributes) goes into the directory? What process is used to collect requests to add data, and make decisions? • Guiding principles: • If request is approved, data is added to University Directory Service (UDS); accessible via LDAP, SQL, web services (XML) with appropriate access control • If request is turned down, recommend using a convention on shared persistent unique person identifier, publicly visible identifier (PVI). If the requested data element can be stored elsewhere, it can be made “reachable” via PVI as a foreign key • At UW System level, less fully worked out, but there is an Identification, Authentication and Authorization (IAA) Governance Group with responsibility for System directory issues

  9. Discussion questions 3Current Situation • What strategies to communicate policy? Does the campus publish definitions of the various attributes and values? Does it recommend their use for access control purposes? • application developers • Public • UW-Madison A2D has taken on task of creating and maintaining an incrementally developed institutional data and metadata dictionary.

  10. Discussion questions 4Current Situation • Who is in the directory? Increasingly, campuses are providing credentials to groups that they didn't previously care about—student and employee applicants, alums, etc. Do the answers to the privacy questions vary by constituency group? If yes, who decides the "default" privacy values for each group? • UW Default privacy values are determined by source system feeds • UW-Madison supports standard processes for addition of new populations • Automated feeds (e.g., importing of an external person registry), require some coding to incorporate into the set of “Special Population” feeds into the enterprise directory. • If population are entered ad hoc, one-by-one, use a “Special Population” user interface; Involves no reprogramming, just system admin and configuration to add another designated Special Population administrator.

  11. Discussion questions 5Planning • What are the external drivers/constraints on directory policy? Ferpa (obviously), but new ones include federal e-authn, shibboleth, others? • Federations for federated identity management (InCommon) • UW System-wide Learning Mgmt System; HR System • The usual: fed E-Authn; licensed resource vendors, etc.

  12. Discussion questions 6Planning • What are the internal drivers? Existing campus policy on security of some values? User expectations? How are the expectations of incoming frosh (who have used AIM for years) affecting expectations? • Growing reliance on enterprise directory by number of applications (in-house, purchased) • Roll-out of shared Web Initial Sign-on (WebISO) solution to app developers and integrators leads to follow-on demand for authorization information • WebISO has also heightened app developer/integrator awareness of security issues around handling user credentials • Growing concerns of data custodians as the data gets more widely used leads to a demand for finer-grained controls

  13. Discussion questions 7Planning • How to accommodate changing directory & privacy requirements over time? • technologies (e.g., mobile phones, IM) • legal context • Our technologies need to be able to support • Fine grained access control (attribute-level, even attribute value-level; Shib attribute release policies?) • Changes in policy handled by configuration changes, not reprogramming • Shib? UW-Madison Populations, Affiliations and Service Entitlements (PASE) system) • We need standing policy/process resolution bodies • UW-Madison Identity Management Leadership Group (IMLG)

More Related