Universities of Glasgow and York

Right People, Right Stuff, Right Pain?

John Byrne, James Currall, Colin Farrow

Version 1.0

June 2002

Introduction

In common with many others, we have identified authentication and authorisation as crucial to the delivery of a viable intranet and see directory services as important to those processes, possibly the key component. Directories can provide the 'glue' which links other components together.

There is a clear need to separate identifying who people are from what those people are allowed to see. In addition what people are allowed to see is often as a result of the role that they occupy rather than as a result of who they are. Directory services can easily deal with these three categories of information: people, roles and groups, but only if careful work is carried out to design a suitable schema for the directory.

Needs

To Link People Up with Relevant Information

         People <==> Information

people require information
institutions make information available to people
may be desirable to restrict information to specified people

which leads to:-

    authentication -> People     Information
 
                        |             |

                        |             |
      
                        V             V

                      Roles   +    rights  = authorisation

                        |
                 
                        |

                     Groups

Flexible access control to web resources
- determined by content-providers
- applied to groups within the institution
- extensible to groups beyond the institution
Infrastructure to support future web-based intranet/extranet services

Role-based access control

Components - a simple model

Resources: web pages, web applications
Register of users: for authentication
Register of Groups: to represent user roles
Rule sets: to associate resources and groups
Access control agents: software components to apply the rules

Difficulties

who are the people and how to identify them?
how does one assign roles?
how does one deal with a distributed computing environment?
limitations of current access control systems

Issues

Management and ownership
- determining the user registry
- determining institutional groups
- deriving groups from corporate data sources
- central or distributed management
- groups policy
Critical systems
- loadsharing/failover
Open standards
- linking with other institutions
- external initiatives - e.g. Shibboleth
- the unknown
scale of operation - single/multi/national/international institution working
metadirectories
implications for searching
Buy or build?

Experience to Date

1) York

LDAP

Stores user authentication data
- currently usernames and passwords
- web interface to password management
Stores user groups
- system-defined (overnight feeds)
- custom (web interface for authorised users)
- stored in hierarchies for efficient processing
Why LDAP?
- fast read/search access
- standards-based
- scalable
- widely used
- likely to be component in future developments

YorkWeb hosting service

Solaris/Apache/ColdFusion
- locally-written Apache module (access control agent)
- Access control rules stored in Apache .htaccess files (rule sets)

Specifying access control

web interface for content-providers
URL of node to be protected
rules based on LDAP groups

Processing end-user requests for protected resources

authenticate user against LDAP
- request user’s group(s) from LDAP
- process group information in relation to .htaccess rules
- allow or deny access

2) Glasgow

The Glasgow University Permissions Database utilises OpenLDAP directory service to store details of:

people
groups/roles
resources

Access to restricted web pages is based on Apache with custom mod_perl extensions for:

authentication
- validate userid, password against people record
authorisation
- page request
- get permissions for resource
- get user permissions
- grant or deny access permissions apply to:-
  individual documents
  sub trees
  leaf to the root lookup
  subdirectories inherit permissions of parent
  subdirectory permissions override those of parent
  incorporates, host, user, group, role and time based controls

A web based management tool provides document providers with:

editing functions for people, groups, resources according to role, realm, permissions

Resources

Books

"Implementing LDAP": Mark Cox; WROX pressFairly good introduction to the subject. A search of Amazon will reveal others.

Introductory LDAP Resources

An Introduction to LDAP: http://www.ldapman.org/articles/intro_to_ldap.html
An LDAP Roadmap & FAQ: http://www.kingsmountain.com/ldapRoadmap.shtml
LDAP Resources: http://iii.gla.ac.uk/scotmid/publications/ldap.shtml
Glasgow permissions database demo: http://iii.gla.ac.uk/demo/auth/

Directory Services

OpenLDAP: http://www.openldap.org/Open source implementation of the Lightweight Directory Access Protocol, short introduction in Admin Guide
iPlanet directory server: http://docs.iplanet.com/docs/manuals/directory.htmlParticularly the administrator's guide, deployment guide and schema reference
LDAP Recipe: http://www.georgetown.edu/giia/internet2/ldap-recipe/A Recipe for Configuring and Operating LDAP Directories. Recommendations and discussions which will hopefully lead us all in the direction of common directory schema and deployments.

Groups

LDAP and Group Information: http://www.doit.wisc.edu/services/middleware/directoryservices/ldapgroups.htm
Groups: http://middleware.internet2.edu/dir/groups/ The groups subgroup of MACE-Dir will establish best practices in the use of core middleware to meet the authorization and messaging needs of applications. The group's initial foci are 1) the conduct of a survey of several organizations' practices in this area and 2) investigations into meaningful definitions of, and productive ways of representing and operating on, "groups", "affiliations", "roles", and "correlations".
Middleware Architecture Committee for Education (MACE): http://middleware.internet2.edu/MACE/MACE-Dir is the directories working group of Internet2

Inter-institutional working

eduPerson: http://www.educause.edu/eduperson/The eduperson object class draws on the existing standards work in higher education to select items that are of broad utility, and define a common LDAP representation for each of them, to assist in building general-purpose institutional directories.
Shibboleth: http://middleware.internet2.edu/shibboleth/Shibboleth, a joint project of Internet2/MACE, is developing architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls. In addition, Shibboleth will develop a policy framework that will allow inter-operation within the higher education community. Key concepts within Shibboleth include: DoDHE (see below).
DoDHE: http://middleware.internet2.edu/dodhe/Directory of Directories for Higher Education, DoDHE, a project of MACE, is investigating technology to support inter-institutional directory searching.
PAPI: http://www.rediris.es/app/papi/index.en.htmlPAPI is a system for providing access control to restricted information resources across the Internet. It intends to keep authentication as an issue local to the organisation the user belongs to, while leaving the information providers full control over the resources they offer. The authentication mechanisms are designed to be as flexible as possible, allowing each organisation to use its own authentication schema, keeping user privacy, and offering information providers data enough for statistics. Moreover, access control mechanisms are transparent to the user and compatible with the most commonly employed Web browsers, i.e., Netscape/MSIE/Lynx, and any operating system.
Sparta: http://www.jisc.ac.uk/pub00/sparta_disc.htmlProposal for the Second-Generation Access Management System for UK Further and Higher Education to replace Athens (http://www.athensams.net/)

LDAP RFCs

LDAP RFCs: http://www.internet-standard.com/LDAPrfc.htmlThe full horror – a list of LDAP RFCs for those who have trouble getting to sleep at night.

Web-based Access Control

Netegrity: http://www.netegrity.com/ One of several developers of web-based access-control systems. Their SiteMinder product is a good example of a general system which can be plugged into existing infrastructure.

Conclusions

The authoritative sources of data need to be identified (or if they do not exist, created)
The people who are responsible for the maintenance of specific parts of the authoritative sources need to be identified and they have to ensure that changes in roles and membership of groups are updated in a timely fashion, so that these data may be relied upon in institutional processes.
A complete database of people who are entitled to access information resources is essential. This information must be fed expeditiously from such sources as the Registry and Human Resources Systems, so that people are added to appropriate roles and groups when they join the institution and their privileges are withdrawn as soon as they leave. The security of an institution's information resources depends on this.
The design of the LDAP directory needs careful thought so that it will meet all reasonable foreseeable needs, including the fact that the institution will undergo periodic reorganisation.

Then you can start to think about getting to grips with the technology!