1. Distributed Access Control System
Brian McLeod
Canada Centre for Remote Sensing
Salutations …..

2. GeoInnovations (technology development program)
The M3GO project is a small project funded by GeoConnections program. It is rather a “proof of concept”
Of Ontology/Semantic work that is needed while developing an NSDI such as the Canadian Geospatial
Data Infrastructure (CGDI), helping in data discovery through Portal such GeoConnections Discovery Portal.
GeoInnovations (technology development program)

3. WHAT IS DACS?
An authentication and access control framework that facilitates secure sharing of http-based web services
Web service: any static or computational resource available through a web server using HTTP (HTTPS):
E.g., a web page, document, CGI/ASP program, servlet, database query, file upload/download, generated image, gazetteer request, DACS operation

4. WHAT IS DACS? “Single Sign-On”
User doesn’t need an account on every system, is authenticated just once
Implemented by a customized web server and a set of CGI programs
Designed and implemented by DSS as a component of NFIS with participation of the National Forest Information System (NFIS) Project Office and the PFC/IRMS group, with support from GeoConnections

5. FEDERATIONS/JURISDICTIONS
Deployed as a federation of jurisdictions
Jurisdiction:
An administrative entity providing authentication services for its users, web services, or both
All interaction is through a web server that provides DACS services for the jurisdiction
An organization, department, lab, or workstation can be a jurisdiction
The set of jurisdictions and their users is open (not static)
Federation: a set of cooperating jurisdictions (NFIS has 7 jurisdictions in the federation)

6. Two Federations: “alpha.org” and “beta.org”
ant.alpha.org
bat.beta.org/arrow.alpha.org
Authentication
Authentication
Authentication
Authentication
Web server/
DACS
Web server/
DACS
SSL/
TCP/IP
Services
Services
Services
boron.beta.org
air.alpha.org
Authentication
Web server/
DACS
Web server/
DACS
Services
Services

7. AUTHENTICATION
A jurisdiction authenticates its users using its existing mechanisms (e.g., login name and password)
If successful, DACS creates encrypted credentials that identify the user and accompany subsequent service requests
User presents credentials when making a service request; only DACS can decrypt them

8. AUTHENTICATION
Authentication is a DACS service; any authentication method that can be encapsulated by a service request can be supported
DACS defines the service protocol by which it requests a jurisdiction to authenticate its users
Goal is to minimize jurisdictions’ implementation effort (common methods have already been implemented)

9. User’s Jurisdiction SSL/ User TCP/IP USER AUTHENTICATION
Authentication info
Web server/
DACS
SSL/
TCP/IP
DACS Config
DACS
Authentication
Service
User
Credentials
HTTP/XML
HTTP/XML
Local Authentication Service
Local Roles Service

10. AUTHENTICATION
DACS does not manage user accounts on behalf of jurisdictions
Jurisdictions are isolated from implementation details; DACS provides the “glue”
DACS can support “cascading” requests (server-server service requests)

11. ACCESS CONTROL
A jurisdiction is totally responsible for specifying access control for its web services
Access control is performed on a service request (a URL)
An access control rule specifies:
What services the rule applies to (URLs)
How the service can be accessed (a predicate)
Who the rule applies to (which users)

12. ACCESS CONTROL An access control rule can:
refer to elements of the credentials (e.g., user’s name and jurisdiction) or environment (e.g., the user’s IP address)
refer to service request parameters (e.g., “SCALE must be greater than 1000”)
specify additional parameters to pass to an invoked program (“constraints”)
apply to any member of a defined group of users
apply to a DACS service

13. SERVICE REQUEST PROCESSING
Incoming service request passed to DACS by the web server
DACS validates the user’s credentials
DACS looks for the most specific access control rule that applies to the service request (URL matching)
DACS checks if the rule grants permission to this particular user, possibly testing the service request’s parameters
If permission is granted, the service request is processed normally (DACS exports the identity of the user, etc.)
If permission is denied (“403 Forbidden”), an error handler is invoked

14. GROUPS
During authentication, a jurisdiction can associate the user with roles, defining role-based groups
A jurisdiction can also define named groups; members are users, role-based groups, or other named groups
Group definitions are distributed among the jurisdictions and can be referenced in access control rules throughout the federation

15. IMPLEMENTATION
Prototype runs on Linux/Solaris/FreeBSD with Apache (i386 and Sparc architectures)
Open source, standards-based, proven technologies
Portable – largely platform independent (ANSI C, POSIX)
Unix and NT authentication components
Design and implementation can be examined for security weaknesses; specifications are available

16. WHY DACS? Special requirements: Standardization still in progress
Architectural model (independent/cooperating jurisdictions, heterogeneous, distributed, available)
No client-side code, special installation, etc.
Support for a wide variety of services
Open set of jurisdictions and users, including “guests”
Needs/requirements not yet well understood
Standardization still in progress
(e.g., SAML, XACML, …)
Existing solutions? Probably not yet.

17. ENHANCEMENTS? Port to Microsoft/IIS/ASP Support for user certificates
Support for additional authentication components (e.g., PAM, RADIUS, LDAP)
Integration with Java?
Invocation by applications?
Many other possibilities…

18. ADDITIONAL INFORMATION
National Foresty Information System (overview)
DSS – Distributed Systems Software, Inc.
Dr. Barry Brachman, DACS System Architect
Pacific Forestry Centre, Integrated Resource Management Systems
Rick Morrison, NFIS technical lead
Tel: (250)