Title: CGDI Development Network
1National Forest Information System
Distributed Access Control System
- CGDI Development Network
- Meeting
- January 2002, Ottawa
2Overview
- National Forest Information System
- Requirements of access control system
- Distributed Access Control System
- DACS demo
DACS Credits Funded through GeoConnections
PAC, Canadian Council of Forest Ministers, and
CFS DACS Design and Prototyping Distributed
Systems Software (http//dss.bc.ca) and CFS
3NFIS in three slides
- CGDI Development Network
- Meeting
- January 2002, Ottawa
4NFIS - delivering seamless national forest
resources information from source
5Seamless Web Access
Distributed sources
6NFIS services architecture
complexity barrier
7Goal of DACS
- To facilitate secure sharing of information over
the Web within a federation of autonomous
organizations
8Access Control System Requirements
- CGDI Development Network
- Meeting
- January 2002, Ottawa
9Requirements (1)
- Distributed jurisdictional control of access to
arbitrary Web resources - delivery of content, execution of programs via
HHTP requests to member servers - Jurisdictions control access to their own assets,
define and authenticate their own users - no central authority - easy to pull the plug
and leverages existing IM infrastructure
10Requirements (2)
- Jurisdictional authentication - network access
- authenticate user once per NFIS session
- user has a network identity derived from his
local identity - plugin to existing authentication technologies
(e.g., Microsoft NT Domain Controller, Radius,
LDAP, PKI, etc.) - Support vanilla Web browsers and custom client
applications
11Requirements (3)
- Low cost of entry
- use commonly available software components
- minimize required changes to business practices
- extensible without retooling existing NFIS
infrastructure
12DACS Approach
- CGDI Development Network
- Meeting
- January 2002, Ottawa
13Access control Who, what, how
- Who is making the request ?
- Users, groups roles
- What is being accessed ?
- Web services described by a URI
- Example ftp//bc01.nfis.org/download/fc
http//nfis.org/cubestor/cubeserv.cgi? - How is it being accessed ?
- Extensible access rules
14Who DACS Users
- Have a home jurisdiction
- Jurisdictions have a well-known, unique, name
officially assigned within the NFIS network - Examples BC-MOF, BC-ENV, CA-CFS, CA-ENV
15User network login
- User may be challenged to authenticate at any
NFIS portal (member server) - User provides username/password relative to their
home jurisdiction - Portal channels authentication request to DACS
server at home jurisdiction - On success, user obtains NFIS network-wide
credentials
16User credentials
- Based on Netscape cookie specification
- requires participating Web servers to be known by
a common domain name suffix (e.g., nfis.org,
cfs.nfis.org, bc.nfis.org, nf.nfis.org ) - May include roles (assigned by jurisdiction at
authentication time) - Expire or may be revoked by the authenticating
jurisdiction
17Who DACS User Groups
- native DACS group membership mechanism
- group membership explicitly defined within the
jurisdiction - membership lists distributed to all DACS servers
- membership comprised of any NFIS network user or
group
18Who DACS User Roles
- used to capture existing jurisdiction access
categories (e.g., LDAP, ad hoc) - organizational structure NRCan/CFS/PFC,
NRCan/CFS/PPIAB - functional structure accounting, informatics
- assigned to user at authentication time
- avoids duplication of existing group systems
- jurisdictions may reference external groups/roles
in their own group definitions and access rules
19DACS Group Definition
- ONFire
- ltgroup_definition jurisdiction"ON" nameFire"
mod_date"Fri, 30-Nov-2001 131700 GMT
type"public"gt - ltgroup_member jurisdiction"NF"
name"alice_at_gov.nf.ca" type"username"/gt
ltgroup_member jurisdiction"ON"
name"bob_at_gov.on.ca" type"username"/gt
ltgroup_member jurisdiction"NFIS"
name"carol_at_nfis.org" type"username"/gt - lt/group_definitiongt
- NFISAdmin
- ltgroup_definition jurisdiction"NFIS"
name"admin" mod_date"Fri, 30-Nov-2001 91700
GMT" type"public"gt ltgroup_member
jurisdiction"NF" name"admin" type"dacs"/gt - ltgroup_member jurisdiction"ON" name"admin"
type"dacs"/gt - ltgroup_member jurisdiction"PFC" name"admin"
type"dacs"/gt - ltgroup_member jurisdiction"NFIS"
namecarol_at_nfis.org" type"username"/gt - lt/group_definitiongt
20How 3 types of access
- Access control on a service
- Access control on a service with optional
constraints on its arguments - /cubestor/cubeserv.cgi? scale1M
- Access control on a service with optional
constraints on its arguments and, optionally,
depending on information being accessed - invocation of an external, user-specified,
service-dependent program.
21Access Control Procedure
- A Web server is configured to enable DACS
security for selected directory tree(s) - Web server receives a request for a resource
living in the directory tree - Web server activates DACS authentication module
- If credentials not present request is
redirected to DACS authentication screen (Web
browser) or fails (custom application)
22- If credentials present, DACS invokes ACS to
determine whether request should be carried out - ACS uses a language to express rules that
describe the kinds of access users have to
services. - ACS is provided with the service request, its
parameters (present only if the service request
is not for static content), the validated
credentials of the requestor, and certain
environment-dependent variables.
23- ACS searches for an applicable ACL rule for the
given request and requestor - If match is found the rule is applied (approve or
deny) - If no match is found access is denied
- DACS can return credentials in an XML reply or
can directly set a cookie in a Web browser
24DACS Access Rules Type 1
- lt!-- This is a comment --gt
- ltacl_rulegt
- ltservicesgt
- ltservice url_pattern"/dss-private/hello.htm
l"/gt - ltservice url_pattern"/dss-private/printenv.
cgi"/gt - lt/servicesgt
- ltpredicatesgt
- ltuser_condgt
- ltuser_listgt
- ltuser name"DSSrick"/gt
- lt/user_listgt
- lt/user_condgt
- lt/predicatesgt
- lt/acl_rulegt
25DACS Access Rules Type 2
- lt!-- This is a comment --gt
- ltacl_rulegt
- ltservicesgt
- ltservice url_pattern"/dss-private/scaletest
.cgi"/gt - lt/servicesgt
- ltpredicatesgt
- ltuser_condgt
- ltuser_list cond"SCALE gt 1000"gt
- ltuser name"DSSbrachman"/gt
- lt/user_listgt
- ltuser_list cond"SCALE gt 100"gt
- ltuser name"DSSrick"/gt
- lt/user_listgt
- lt/user_condgt
- lt/predicatesgt
- lt/acl_rulegt
26DACS Access Rules Type 3
- A matching rule can specify a string (constraint)
that will be passed to an invoked program, if
DACS satisfied - needed when insufficient information is available
to ACS to decide access - constraint can be used by the invoked program to
modify its behaviour - environment of an invoked program automatically
includes the identity of the user who made the
service request.
27?? Possible CGDI Development Network pilot
project to DACS some services under
geoconnections.org
28DACS Demo
- CGDI Development Network
- Meeting
- January 2002, Ottawa