Universities of Glasgow and York
Right People, Right Stuff, Right Pain?
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.
- 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
Roles + rights = authorisation
- 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
- web pages, web applications
- Register of
- for authentication
- Register of
- to represent user roles
- Rule sets
associate resources and groups
- Access control
- software components to apply the rules
- 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
- Management and ownership
- determining the user registry
- determining institutional groups
- deriving groups from corporate data sources
- central or distributed management
- groups policy
- Critical systems
- Open standards
- linking with other institutions
- external initiatives - e.g. Shibboleth
- the unknown
- scale of operation - single/multi/national/international institution
- implications for searching
- Buy or build?
Experience to Date
- 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
- widely used
- likely to be component in future developments
YorkWeb hosting service
- 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
The Glasgow University Permissions Database utilises OpenLDAP
directory service to store details of:
Access to restricted web pages is based on Apache with custom
mod_perl extensions for:
- validate userid, password against people record
- page request
- get permissions for resource
- get user permissions
- grant or deny access permissions apply to:-
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,
- "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
LDAP Roadmap & FAQ
permissions database demo
source implementation of the Lightweight Directory Access Protocol, short
introduction in Admin Guide
- iPlanet directory server
the administrator's guide, deployment guide and schema reference
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.
- LDAP and Group Information
- 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
is the directories working group of Internet2
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
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).
of Directories for Higher Education, DoDHE, a project of MACE, is investigating
technology to support inter-institutional directory searching.
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.
for the Second-Generation Access Management System for UK Further and Higher
Education to replace Athens
full horror – a list of LDAP RFCs for those who have trouble getting to
sleep at night.
Web-based Access Control
- 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
- The authoritative sources of data need to be identified (or if they do not
- 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