Authorization

Overview

Authorization works hand-in-hand with authentication. Authentication provides the identity of a user, but no information about whether they can access a particular system or service. Authorization determines what level of access that user has, whether they can modify as well as retrieve data, and so forth. This document is closely related to the Authentication, Identity Management and Workgroups strategies.

IT Services' immediate authorization strategy is primarily guided by integration. IT Services has a wide and disparate range of authorization systems in use, and many of them are not connected with other systems. There is existing data about users that would be useful for authorization, but is not easily accessible to most applications, many identities other than users and guest accounts that are not handled by the central authorization system, and multiple roles for the same person that cannot be represented in the authorization system. Therefore, IT Services' main direction is towards integration of those authorization systems and better synchronization of service authorization data with central authorization systems.

There is also a growing need for federated and interservice authorization, which includes authorization of mobile devices and mobile device applications with other services. Federated and interservice authorization are, to an extent, related solutions to similar problems. Both allow selective disclosure of authentication and authorization information to specific services, applications, or institutions without establishing separate identities with each. The university would like to provide services to people whose identity and authentication information is maintained at other institutions, as well as allow Stanford users to access services and applications hosted elsewhere without disclosing more identity and authentication information than required. Frequently, this involves releasing data from one application to another, or granting limited access to personal data to a particular device, which involves interservice authorization and attribute release. Similar protocols can sometimes be used for both problems.

Finally, IT Services' current modeling of authorization attributes needs improvement. Currently, most of the central authentication outside of Active Directory is based on entitlements, which are simple statements of access stored with the person's other data. In the LDAP (Lightweight Directory Access Protocol) world, LDAP groups are more common and would provide additional useful query capabilities. Deploying LDAP groups will also allow IT Services to apply finer-grained ACLs (Access Control Lists), improving security and meeting community requests for additional access to group membership information that cannot be easily provided with entitlements.

Current State

The current core authorization services:

• Workgroup Manager workgroups, as expressed as entitlements in OpenLDAP.
• System-generated privgroups maintained by Administrative Systems and expressed as entitlements in OpenLDAP.
• Active Directory groups, some managed directly in Active Directory and some created by converting privgroups from OpenLDAP.
• AFS (Andrew File System) ACLs (Access Control List), and PTS (Protection) groups, with some (as yet underused) support for linking to privgroups.
• Zimbra distribution lists, with support for linking to privgroups.
• NetDB access groups, also used for some wallet authorization decisions.

There are some ad-hoc conversions between these systems due to deficiencies in Workgroup Manager and its supporting infrastructure, such as scripts to convert workgroup membership for an iPass subscriber into Active Directory membership for their iPass Kerberos instance.

Computing Services also uses:

• ACL files generated from OpenLDAP entitlements and used for remctl ACLs.
• Manually maintained ACLs for system-level access to servers.
• Manually maintained wallet ACLs for non-host-basedprincipals.
• Manually maintained lists of users in .htaccess files and Apache configurations.
• Manually maintained access control groups for OpenLDAP access.
• Access control configured manually for many different applications: AFS administrative access, Kerberos administrative access, Instant Messaging chatrooms, and many others.

This is only a partial list. One of IT Services' challenges is that there is not a comprehensive inventory of where and how authorization is being performed.

Web collaboration and publishing tools such as Drupal, Mediawiki, and WordPress have their own internal authorization systems, but the Stanford community has done some work on linking those authorization systems to entitlements in LDAP via WebAuth. Some also support use of Shibboleth assertions for mapping to internal groups.

Vision

Authorization systems are mandatory: They will be deployed, whether managed centrally by IT Services or not. If not planned and implemented as central services, the result will be disconnected, ad-hoc systems that lack lifecycle management and sufficient auditing. Investing time and resources into building generalized systems that can support many different applications is a good way to reduce overall complexity and therefore reduce costs. It also improves security by reducing the number of separate points to control authorization.

Systems distributed across the university frequently request data about people as part of their authorization process. This authorization data request is, for many systems, the practical front-end to the identity management and authentication systems. Improvements to identity management will often only become useful insofar as they can be exposed through useful authorization systems, and central authentication systems become much more attractive to clients if they come integrated with powerful authorization systems.

Authorization is also an area of frequent interest, confusion, and frustration for IT Services' clients. Simpler and better-integrated authorization systems would be seen by clients as a significant improvement to services and remove a major point of difficulty in deploying new applications.

Finally, sophisticated authorization systems are vital to the secure and efficient use of smart devices, mobile client platforms, and cloud services (both Software as a Service and lower-level cloud computing models). IT Services' clients need to selectively authorize services and applications to retrieve their information without revealing more information than they wish and without putting at risk the credentials they use to access secure Stanford systems.

Technology trends that IT Services is taking into consideration as it proceeds with its strategy for centralized authorization.

• Authorization methods: Authorization support in applications is going down two tracks. On one side, there is LDAP (Lightweight Directory Access Protocol) and Microsoft Windows native authorization (LDAP data exposed via a Kerberos PAC), OAuth or SAML for federated authorization and Software as a Service. On the other side, there is the continued use of increasingly sophisticated internal authorization models built into the application. While external authorization through LDAP, Microsoft Windows PACs, or SAML is easier to integrate with, there is enough momentum behind internal authorization models that any central authorization system must have the mechanisms to push authorization data into such systems, or allow those systems to synchronize application authorization data with central data.
• Web applications: One partial exception are web applications, particularly lightweight web applications (as opposed to large-vendor applications with a web interface). There has been some progress towards making those applications use a pluggable authorization model or trust the authorization decisions of the underlying web server, allowing effective use of authorization mechanisms built into the web server. Both Shibboleth and WebAuth can take advantage of this.
• Federated authorization: The goal of federated authorization is selective data release to authenticated federation partners, providing only the minimal data required, and using dedicated authorization codes for federated relationships. Attribute release as part of a Shibboleth authentication is the most comprehensive and robust, but it requires an extensive architecture and is built on top of somewhat complex protocols. OAuth is the simpler alternative that services are converging on. It seems safe at this point to build solutions on top of SAML and OAuth and assume that those protocols or similar successors will be widely supported.
• Claims-based authorization and the cloud: There is a general industry trend towards cloud services, where one's data and services may be provided by a wide variety of loosely-coupled organizations and companies. This will pose new challenges for authentication and authorization, since users' data should be protected with strong authorization systems and used to avoid releasing too much identity information to potentially untrusted external providers. Significant work on this problem is happening in the federated authorization world, particularly within the Shibboleth and SAML (Security Assertion Markup Language) community and the OAuth community, and SAML and OAuth seem to be emerging as the standard way to exchange authentication, authorization, and attribute data with third parties. Microsoft supports SAML through Active Directory Federation Gateway and all Microsoft cloud services are expected to use this framework.
• Authentication-method-aware authorization: With the trend in authentication systems towards multi-factor authentication and support for multiple authentication methods for the same identity, authorization systems will increasingly need to take into account not only the authenticated identity of a user but the means by which they were authenticated. For example, Microsoft will be adding additional data about the method of authentication to Kerberos tickets issued by Active Direcotry 2008 R2, and UNIX Kerberos KDCs will mark Kerberos tickets obtained via hardware tokens rather than passwords. Some services will require, as an authorization rule, that users authenticate in particular ways, or in ways that are by policy considered sufficiently strong.

The most effective strategy for maximizing use of central authorization systems is therefore to strengthen support for LDAP and Active Directory authorization, continue improving support for SAML and add support for OAuth, and build interfaces to synchronize authorization data in applications that don't support directly querying an external source.

Currently, maintenance of workgroups is not well-automated, despite some progress on an API for workgroup management. This is one of the things that needs to be improved to make workgroups more useful as a central authorization system. Additional APIs that allow applications to push and pull data from workgroups are needed, as is better automated lifecycle management of the membership. The current workgroup system does not support the following features, which are necessary for a comprehensive central authorization system.

• Support for multiple roles for a given person in the workgroup system, allowing use of separate privileged roles in authorization restrictions. This will be important for requiring stronger authentication for privileged access but not for routine access. Currently, more-privileged Kerberos root and admin instances and less-privileged iPass and SUNet instances have to be managed outside of the workgroup system.
• Support for service, system, and network identities within the workgroup system. Without this support, workgroups cannot be fully leveraged for AFS, Wallet, and service-to-service authorization decisions. IT Services supplements these with separate authorization systems.
• Support for federated identities (such as through the InCommon Shibboleth federation) within workgroups so that they can easily be granted access to services using the central authorization system.
• Support for low-security authentication methods such as OpenID for access to low-value data.
• Lifecycle management of authorization membership, so that people can be automatically dropped (or added) to authorization groups when their roles in the university change.

Following the migration of account provisioning services from Administrative Systems into IT Services, IT Services will work with Administrative Systems to augment the existing workgroup system with support for multiple roles, building on the existing support for guest accounts and adding support for roles within the account services system. The remaining features will be considered at that time, and more concrete plans made for how they can be incorporated into the workgroup system. Until those plans are complete, these needs will require additional authorization logic that will live alongside the workgroups rather than being integrated into it.

In parallel, IT Services will work on other improvements to central authorization:

• Move the campus Shibboleth architecture to 2.x and SAML (Security Assertion Markup Language) 2.0 and continue improving Stanford University's federated links to other institutions so that Shibboleth will become increasingly useful for federated authorization.
• Implement the next generation of Active Directory Federation Services (ADFSv2). This would extend the existing Active Directory infrastructure to be able to generate and consume SAML 2.0 claims (sometimes called assertions) and enable authorization interoperability between Shibboleth and Microsoft Windows applications in the university's Windows infrastructure.
• Complete work for provisioning LDAP groups as well as entitlements and applying ACLs to individual groups in the LDAP servers, including support in WebAuth for doing LDAP group queries instead of entitlement checks. This will enable more powerful membership queries and allow IT Services to make additional authorization data available to clients.
• Add support for workgroups via LDAP queries to additional systems, most notably Wallet (for secure data management) and remctl (for the network-exposed service interfaces for UNIX Systems services). Make additional use of workgroup integration to push authorization membership changes into other systems that cannot easily query LDAP directly.
• Increase visibility and use of workgroup integration for client selection of which workgroups to express in Active Directory. Workgroup information must be translated into Active Directory security groups before it can be used in access control lists (ACLs) in a Windows environment. However, Active Directory presently has an upper bound of 1014 security group memberships for each user because they are expressed in Kerberos tickets. Currently, almost all entitlements are expressed into security groups by an automated process, but this may not be sustainable as more entitlements are created for role-based application access.

IT Services will continue push as many applications as possible towards use of workgroups and central authorization systems rather than adding separate authorization systems. This includes physical security applications such as door access.

Roadmap

For those goals that depend on Administrative Systems (AS) development, a combined strategy between AS, IT Services, and SUL (Stanford University Libraries) will be pursued following the transition of account service provisioning from Administrative Systems to IT Services. Once that strategy is complete, it will be turned into a roadmap for the necessary development to implement it.

For the remaining goals:

• Upgrade the campus Shibboleth environment to 2.x.
• Deploy the Active Directory Federation Gateway and use it to leverage the campus Shibboleth environment for authentication and authorization to Windows services.
• Modify WebAuth to support LDAP group membership queries in addition to checking entitlements.
• Test the new WebAuth against the new dynamic group tree present in the OpenLDAP directories and push all clients to upgrade to the new version of WebAuth.
• Move the current ACLs on entitlements to per-group ACLs for the new group tree and add new ACLs so that groups can get convenient access to membership information for workgroups that they control.
• Remove general access to entitlements and require that group information be accessed through the new group tree except for special cases.
• Populate the rest of the workgroups in the directory that have been held back due to data privacy requirements, such as course membership workgroups.
• Add direct support for LDAP group queries in ACLs to wallet.
• Add direct support for LDAP group queries to remctl.
• Take an inventory of where IT Services is configuring authorization internally and use this as a basis for planning additional improvements to the centralization and management of authorization decisions.
• Build internal understanding and experience with OAuth and begin using it for federated and interservice authorization where appropriate.

Measures of success

Success in this area will be measured by cooperation with Administrative Systems to see significant enhancements of the workgroup system deployed, or finding another way to provide a central authorization system that supports the features needed.

In addition:

• The number of clients registered with the Shibboleth servers will show increasing use of Shibboleth and support for federated authorization.
• The number of WebAuth servers that query the LDAP group tree can be monitored instead of looking for entitlements found in the LDAP logs, once converting LDAP accesses begins. In the broader picture, there should be greater use of workgroups and finger-grained access control in use after that transition is complete.
• Counting the number of ACLs in wallet and remctl that continue to use lists of principals instead of ACLs based on workgroup data in LDAP will demonstrate how much work is left to do to centralize authorization for those services.