DACS

1
DACS
10-Nov-09 1001 PM

• Distributed Access Control System

2
WHAT IS DACS?

• An authentication and access control framework
  that facilitates secure sharing of 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

3
WHAT IS DACS?

• Single Sign-On
• User doesnt 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 NFIS Project
  Office and the PFC/IRMS group

4
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

5
Two Federations alpha.org and beta.org
ant.alpha.org
bat.beta.org/arrow.alpha.org
Authentication
Authentication
SSL/ TCP/IP
Services
Services
Services
boron.beta.org
air.alpha.org
Services
Services
6
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

7
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)

8
USER AUTHENTICATION
Users Jurisdiction
Authentication info
DACS Authentication Service
User
Credentials
HTTP/XML
HTTP/XML
9
AUTHENTICATION

• DACS does not manage user accounts on behalf of
  jurisdictions
• Jurisdictions are isolated from implementation
  details DACS provides the glue
• Credentials can also be obtained offline
  (non-interactively)
• DACS can support cascading requests
  (server-server service requests)

10
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)

11
ACCESS CONTROL

• An access control rule can
• refer to elements of the credentials (e.g.,
  users name and jurisdiction) or environment
  (e.g., the users 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

12
SERVICE REQUEST PROCESSING

• Incoming service request passed to DACS by the
  web server
• DACS validates the users 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
  requests 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

13
GROUPS

• During authentication, a jurisdiction can
  associate the user with roles, defining
  roll-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

14
ARCHITECTURE

• A federation has a central administrative
  authority
• Operation is decentralized, highly available
• Supports least common denominator user agents
  -- browsers with no client-side certificates,
  applets, JavaScript, etc. -- but is not
  restricted to them
• A jurisdiction continues to be autonomous it
  owns its resources and administers access to
  them DACS does not copy passwords or web site
  content
• Design is simple yet functional, flexible,
  versatile

15
IMPLEMENTATION

• Prototype runs on Linux/Solaris/FreeBSD with
  Apache 1.3 (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
• 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.
• E-commerce/E-business solutions -- How suitable?

17
ENHANCEMENTS?

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

18
CONTACT INFORMATION

• DSS Distributed Systems Software, Inc.
• Dr. Barry Brachman, DACS System Architect
• brachman_at_dss.bc.ca
• http//www.dss.bc.ca
• Pacific Forestry Centre, Integrated Resource
  Management Systems
• Rick Morrison, NFIS technical lead
• Tel [phone]
• rmorriso_at_pfc.forestry.ca