Search Stanford:

Strategic Vision

• Overview
• Technology Principles

Documents by Service Area

• Authentication
• Authorization
• Backups
• Calendar
• Desktop Management
• Directory
• Email
• Identity Management
• Integration
• Networking
• Storage
• Voice
• WWW Services
• Windows Infrastructure

Related Pages

• Planning Documents
• IT Services Projects
• Project Management Office

• IT Services
• Strategic Vision
• Authorization

Authorization Vision

Lynn McRae, updated 10/30/05

This document covers the strategic vision for managing authorization to services and resources across Stanford. At the heart of the vision is a centralized privilege management system and related services that will allow the integration, over time, of security and authorization technologies in diverse applications and technologies. It addresses the need for solutions that allow for both direct interactions with centrally managed authorization services as well as the provisioning of application-specific security. Centralized authority management is about managing authority decisions together and applying it through other technologies. It does not replace all local security systems, but will allow the gradual but deliberate integration of distributed authorization needs both for central and departmental systems.

There are many potential consumers of centrally managed privilege information. Those relating to IT Services/AS-run or infrastructure services are identified in the technologies section, but the desire is to converge on one or a few basic technologies that can integrate with anything from specific applications and services we have to future enterprise security software we might acquire.

Principles

A shared, centralized approach to authorization should address the following goals:

• Simplification of authority policy, management and interpretation. We should be able to summarize the rights and privileges of an individual or let departmental administrators view and manage together all authority in their department or division. This includes historical views of authorization data relevant to answer questions about who had authority.
  
  
• Consistent application of authority rules via infrastructure services and synchronization of administrative authority data across systems. An access rule should be stated once and programmatically applied to all applicable situations.
  
  
• Integration of authority data with enterprise reference data to provide extended life-cycle services such as delegation and automatic revocation of authority based on status and affiliation changes.
  
  
• Role-based authority, that is, management of privileges based on criteria like job function rather than attached to individuals.
  
  
• Support for standards and mechanisms that work across institutions (Federations, Virtual Organizations, inter-campus sharing, etc.) and extend to commercialservices providers (online publishers, etc.).
  
  
• Treat authorization for applications and accounts with the same facilities that apply to persons.
  
  
• Support auditing and history not only of privileges, but who grants privileges and with what authority through the complete chain of delegation.
  
  
• Privileges are about actions and resources, not about technologies. For example, access rights to shared course materials should be the same whether data is delivered via the web, AFS files, directory, etc. In this scenario, a portion of AFS ACLs may be programmatically managed from central data as part of course-related services, but overall AFS security itself is not.
  
  

Technologies

Stable core technologies:

• Authority Manager for granting/revoking privileges to major administrative systems.
  
  
• Workgroup Manager to express membership groups for use in a variety (but currently limited) authorization scenarios.
  • Workgroup-based authorization, expressed as an LDAP accessible privgroup attribute associated with a Person, e.g. Active Directory, Net-Access
  • WebAuth support for privgroup references through the group directive in .htaccess.
  • System maintained course membership groups, use by Coursework, Leland course services, and GSB to dynamically manage Student and instructor access rights.
    
    
• Registry managed high-level role privgroups for Faculty, Staff, Student, administrative and academic communities (stanford:stanford, staford:faculty, stanford:administrative, etc.).
  
  
• .klogin and .k5login files for access control to Unix accounts.
  
  
• AFS PTS groups for groups-based AFS file access control.
  
  
• IMAP ACLs for email authorization. Personal access is maintained automatically, but access/maintenance privileges for group acocunts are a manual process.
  
  
• NetDB roles and groups.
  
  
• Active Directory groups.
  
  
• Leland Course support use of Course Registry information to manage course member ACLs.
  
  
• ID Card settings (magstripe encoded) for various forms of authorization, e.g., Library access. Settings are determined through interpretation of Registry affiliations and privgroups.
  
  
• Many administrative systems with their own internal security systems. This is just a partial list:
  • PeopleSoft (mostly integrated with Auth Manager)
  • Oracle Financials roles and responsibilities (mostly integrated with Auth Manager)
  • ReportMart
  • Sundial Calendar
  • Axess Portal
  • Remedy and HelpSU
  • Pinnacle
  • ID Card
  • Amcom phone operator system
  • Resource25
  • Kronos Time and Leave system
  • RegAdmin (workgroup/privgroup protected)
  • Internal admin privs for Workgroup and Organization Manager
    
    

Emerging technologies:

• Signet Privilege Management System -- Internet2/MACE sponsored middleware and UI for centrally managed privileges.
  
  

Deprecated technologies:

A couple of deprecated practices, if not technologes per se:

• Instances of IP-based authorization that serve in stead of personal authentication or group/role recognition.
  
  
• Uses of any form of "anyAuth" privilege when one intends to restrict access to the active Stanford community. AnyAuth includes recent students up to 5 years, and lots of base-sponsored people who obtain sunetids for reasons local to the sponsor.
  
  
• Manual coordination and replication of rights Authority Manager and PeopleSoft/SA.
  
  

Other technologies in use:

• Instances of IP-based authorization where it makes sense for intra-service/server authorization, e.g., protecting log volumes, or is inherently IP-based, e.g., software licenses, firewalls.
  
  
• Authorization changes via a HelpSU or email requests.
  
  
• Manually maintained ACL files used for remctl, for .klogin and .k5login files, and for privileged access to infrastructure services.
  
  
• ssh authorized_keys files.
  
  
• The srvtab authorization database, currently maintained by Kerberos administrators based largely on NetDB roles and groups.
  
  
• Manually maintained ACL files used for remctl, for .klogin and .k5login files, and for privileged access to infrastructure services.
  
  

Projects

First:

• Provide a reporting user interface to Authority Manager.
  
  
• Provide a standard mechanism for reconciling authorization data in Authority Manager and target systems. Significant progress has been made in this recently, but work continues.
  
  
• Enable the suite of course and organizational privgroups. We are doing more and more of the latter as a service offering though nightly scripts; a better way is anticipated using system-maintained workgroups based on an individual's departmental affiliation.
  
  

Next:

• Develop a user interface for defining the privileges (things that can be granted) in Authority Manager.
  
  
• Deliver authorization related information via directory (cf eduPersonEntitlement).
  
  
• Deliver authorization assertion information via Webauth (perhaps simply as additional require directives referencing authority-related directory attributes).
  
  
• Provide user self-service management of group IMAP access and administrative privileges.
  
  
• Replace the current srvtab authorization system with a system based on Kerberos v5 that takes authorization information for system credentials from NetDB roles and groups and that can manage other types of secure information besides srvtabs and keytabs (replacing legacy access control via shared passwords).
  
  
• Integrate workgroups and PTS groups.
  
  
• Integrate of Cyrus IMAP ACLs with for basic ownership information for group accounts with the Account Registry.
  
  
• Automated generation of .klogin and .k5login files based on central authorization information.
  
  
• Set up a system to prompt staff to do periodic audits of authorization data across all of ITSS, recording confirmation when each individual audit has been completed.
  
  

Later:

• Further integration of OpenLDAP and ActiveDirectory groups information to better integrate Windows services like Exchange and CIFS access controls.
  
  
• Develop/extend tools for personal management of how/when personal data is released to specific service providers (self-service control over an attribute release policy) beyond the static visibility categories available in StanfordYou.
  
  
• Develop a Authorization Policy respository and tools to manage policy, i.e., a policy access point.
  
  
• Develop an authorization engine, i.e., a policy decision point.
  
  

Research

• An XACML-based policy decision point so systems don't have to implement their own authorization engine.
  
  
• Evaluate commercial offerings in authorization policy management and interpretaion, e.g., CA/Netegrity SiteMinder, Tivoli SecureWay Policy Director, Conclave by Internet Dynamics, Securant ClearTrust SecureControl.
  
  
• Participate in growth of related Internet2 efforts in authorization policy management and interpretation, in particular as related to Grid and VO support, e.g., Globus Alliance, Permis (UK), PAPI (Spain) and SPOCP (Uninett).
  
  
• Digital Rights Management, Open Digital Rights Language (ODRL).