Slide 1

Transcript Slide 1

METALOGIC
s o f
t w a r e
Swift Auth Developer Overview
Swift Auth – Access Control for Web 2.0
© Metalogic Software Corporation 2004-2006
SwiftKit
a distributed access control toolkit
A replacement for ad hoc access control code,
SwiftKit allows any program to make powerful,
data-driven access control decisions.
Desktop Apps
Java Programs
CGI
?
command line
DACS
ACLs
Scripting Languages
dacscheck
© Metalogic Software Corporation, March 2006
?
dacs_javalib
C/C++ Programs
?
DACS C/C++ API
SwiftWeb
distributed access control for the Web
A universal authentication and authorization
system for Apache that can provide federated
identity (single sign-on) functionality.
Pluggable
Authentication
Web Browser
Apache Server
c
Cookies may be used as an
Configurable
envelope for DACS credentials
Event Handling
© Metalogic Software Corporation, March 2006
Content
&
Services
mod_auth_dacs
?
DACS
ACLs
DACS
Services
Why use Swift technologies?




leverage a robust, mature access
control framework
supports local and Web applications
centralize configuration of access
control, share user account and role
information between applications
simplify application software
development & maintenance
© Metalogic Software Corporation, March 2006
Programs that perform authorization tests
typically contain code like:
•
If the current user has provided a suitable
password, then execute the following code, or
•
If the current user is the administrator, do the
following, or
•
If the current user is allowed to perform an update
operation, then show these menu items
This makes applications prone to bugs and
security problems and harder to maintain
•
•
a change to a security policy may involve changes
throughout an application or suite of applications
password handling can involve significant
implementation effort and is difficult to do securely
© Metalogic Software Corporation, March 2006
Recipe 1: Basic Web Site
Problem: You want to add user and role-based access
controls to your Web site.
Solution: DACS-enable your Apache server and
configure your access control rules.
Build and install DACS on your server. Then load mod_auth_dacs in
the Apache config. Enable DACS access control for a
<Directory> or <Location> using Apache DACS directives.
Configure access control in DACS ACL files:
Service Specification: DACS matches the request against this
specification to determine if the rules should be applied
Rules: a list predicates that is evaluated to decide if access should be
allowed or denied
© Metalogic Software Corporation, March 2006
Example ACL
Description: a wildcard rule allowing access to
everything under the document root (more
specific rules will override)
fire this ACL for all requests
<acl_rule>
default is to allow access
<services>
<service url_pattern="/*“ />
</services>
<rule order=“deny,allow“/>
</acl_rule>
© Metalogic Software Corporation, March 2006
Example ACL
Description: allow access to the MapServer
application only for users belonging to BC’s
mapviewer group
Apply rule if url_pattern
matches request
<acl_rule>
default is to deny access
<services>
<service url_pattern="/cgi-bin/mapserv" />
</services>
<rule order="allow,deny">
<allow>
user("%BC:mapviewer")
</allow>
</rule>
Mapviewer group is defined by
</acl_rule>
the BC jurisdiction
© Metalogic Software Corporation, March 2006
Recipe 2: Authentication
Problem: You want to let users authenticate using their
existing corporate accounts.
Solution: Configure DACS authentication modules to
reference local authentication services.
DACS comes with modules for Microsoft ADS/LDAP, NTLM, Unix
/etc/passwd & NIS, flat file, native Apache, SSL/X.509 and PAM.
Crafting custom authentication modules (for example to reference
a database schema for users and roles) is simple.
Modules are configured in DACS Auth Clauses and are applied in a
controlled sequence to the parameters supplied by the user. If
successful, DACS credentials are returned to the user.
© Metalogic Software Corporation, March 2006
Example Configuration
Description: configure flat-file, NTLM & Unix
authentication modules.

<Auth id="passwd-local">
URL "https://fedroot.com/dacs/local_passwd_authenticate"
STYLE "pass"
CONTROL "sufficient"
</Auth>

<Auth id="passwd-ntlm">
URL "https://fedroot.com/dacs/local_ntlm_authenticate"
STYLE "pass"
CONTROL "sufficient"
OPTION 'SAMBA_SERVER="samba.fedroot.com"'
</Auth>

<Auth id="passwd-unix">
URL "https://fedroot.com/dacs/local_unix_authenticate"
STYLE "pass"
CONTROL "sufficient"
</Auth>
© Metalogic Software Corporation, March 2006
Recipe 3: Basic User Accounts
Problem: You want a simple, off-the-shelf user accounts
framework.
Solution: Use native DACS user accounts and roles.
In addition to the modules DACS includes for industrystandard authentication technologies, DACS implements
its own basic user account and roles framework.
Web services are provided to add and delete user accounts,
assign roles, and manage passwords. DACS ACLs provide
for fine-grained control of access to user account
management functions.
© Metalogic Software Corporation, March 2006
Recipe 4: DACS-enabled App
Problem: You want to use or re-use DACS access
control in your custom application.
Solution: Use SwiftKit’s dacscheck.
dacscheck is a program that can be called from a scripting language
like Python, Perl, PHP or Ruby to provide simplified, generalpurpose access to the DACS access control rule evaluation engine
and lends itself to fine-grained access control decisions.
dacscheck looks at access control rules to test if a given user is
authorized to do something or access something. The command's
exit status gives the result of the test.
© Metalogic Software Corporation, March 2006
Example MyApp (1)
Description: control access to application MyApp from a
Shell script (user identity derived from Unix login)
where to find the ACL rules
#! /bin/sh
dacscheck -q -ieuid -rules /usr/local/myapp/rules /myapp
st="$?"
if test "${st}" != 0
identifier for MyApp
then
echo "Access is denied"
exit "${st}"
fi
echo "Access is granted"
# Do some stuff
exit 0
© Metalogic Software Corporation, March 2006
Example MyApp (2)
Description: control access to application MyApp from a
CGI script (user identity derived from REMOTE_USER
environment variable)
...
check access to MyApp
<?php
$user = $_SERVER["REMOTE_USER"];
putenv("REMOTE_USER=$user");
system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi
-rules /usr/local/myapp/rules /myapp", $st);
if ($st != 0) { // Access is denied, bail out
is user a MyApp admin?
exit($st);
} else { // Access granted; test for admin priviledges
system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi
-rules /usr/local/myapp/rules /myapp/admin", $stapp);
system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi
-rules /usr/local/site/rules /admin", $stsite);
$is_admin = ($stapp >> 8) || ($stsite >> 8);
...
is user a site admin?
© Metalogic Software Corporation, March 2006
Recipe 5: Notice Presentation
Problem: You require users to acknowledge a notice
before accessing selected Web content or services.
Solution: Use the dacs_notices Web service.
An ACL rule may be defined to associate a notice or notices with a
given service URI. DACS enforces a work flow using the
dacs_notices service to present required notices to the user and,
on acceptance, set a Notice Acknowledgement Token (NAT cookie)
in the response. The NAT will accompany subsequent requests
allowing the rule to be satisfied.
© Metalogic Software Corporation, March 2006
Example License Agreement
Step 1 – User attempts access to a DACS-wrapped
resource (eg, Web Mapserver, file download area, etc ...)
Step 2 – DACS matches resource uri with configured ACLs
<acl_rule>
<services>
Stepurl_pattern="/mapserver/umn.phtml"/>
3 – If a license acknowledgement is required,
<service
Apache/DACS sends a browser redirect to the configured
</services>
<rule order="allow,deny"/>
notice presentation handler
<allow>
ack("http://demo.fedroot.com/notices/geobase-license-agreement.html")
</allow>
</rule>
</acl_rule>
Web Browser
GET/POST .../mapserver/umn.phtml
HTTPS
browser redirect to dacs_notices
DACS wrapped
resources
ACLs
match .../umn.phtml against
DACS ACLs
© Metalogic Software Corporation, March 2006
Step 4 – Browser follows redirect to notice presentation
handler
Step 5 – Notice presentation handler obtains text of required
license(s) and presents license(s) text in a license acceptance
form
Step 6 – User reads license text and clicks “Accept;” form
SUBMIT calls notice acceptance service to obtain a Notice
Acknowledgement Token (“license cookie”); possibly
including optional security parameters
Step 7 – This time the ACL is satisfied; Apache/DACS
permits the request
Redirect
to to
Redirect
notice
originally
presentation
requested
handler
URL
Web Browser
(IE, Netscape, …)
redirecting
to
noticewith
presentation
handler
original request
Accept
the
license
License Cookie
HTTPS
License Cookie
(NAT) Created
license
access
present
cookie,
granted
the
browser
license
for subsequent
redirect
acceptance
to requests
original
form URL
GET
http://demo.fedroot.com/notices/g
eobase-license-agreement.html
© Metalogic Software Corporation, March 2006
Recipe 6: Non-Apache Servers
Problem: You want to use SwiftWeb to secure content
or services on another Web server.
Solution: Use Apache + DACS to proxy the other server.
While Apache remains the work-horse of the Web at almost
70% of server deployments, content and services
deployed on other servers like Microsoft IIS, WebSphere,
Tomcat, JBoss may be “DACS-wrapped” without touching
either the proxied server or the application.
© Metalogic Software Corporation, March 2006
Example DACS-wrapped Proxy
Description: control access to a Java servlet in a
Tomcat container by configuring an Apache proxy
# Proxy the FedAdmin Application in a Tomcat container
ProxyRequests on
configure DACS access
ProxyPreserveHost on
control on this location
<Location /fedadmin/app>
AuthType DACS
Require valid-user
AuthDACS dacs-acs
ProxyPass http://localhost:8080/fedadmin
ProxyPassReverse http://localhost:8080/fedadmin
</Location>
© Metalogic Software Corporation, March 2006
Recipe 7: Client & Middleware
Problem: You need to implement Java client code or
middleware to access DACS-wrapped Web services.
Solution: Use the DACS Java Library.
The DACS Java Library (DJL) supports the use of DACS in
Java client applications in several key areas:
•
•
•
establishing the necessary preconditions for access
hiding implementation details of DACS Web services (HTTP
request signatures, marshalling/unmarshalling of XML)
specialization of the Jakarta Commons HttpClient library for
DACS request processing and event handling
DJL is available from SourceForge:
http://sourceforge.net/projects/dacs-contrib
© Metalogic Software Corporation, March 2006
Recipe 8: Federated Web
Problem: You want a secure way to federate Web
information and service delivery amongst partners.
Solution: Use SwiftWeb federated identity and
distributed access control.
By configuring a network of DACS-enabled Apache servers within a
common domain, it is easy and practical to implement a fullfledged single sign-on, multi-server identity management and
access control system for business collaboration on the Web.
DACS imposes few technology constraints on member organizations
and its decentralized design makes it a robust solution resilient in
the face of network and server failures.
© Metalogic Software Corporation, March 2006
Business Requirements

members control access to own Web
services, manage own users, set own policies

nominal central authority - easy for members
to “pull the plug,” low administrative overhead

leverage existing authentication technologies
of members (e.g., Microsoft ADS & NTLM,
Radius, LDAP, PKI, /etc/passwd, etc.)

shallow learning curve
© Metalogic Software Corporation, March 2006
SwiftWeb approach
DACS federation implemented by
a common domain name
DACS federation consists of one
or more jurisdictions
NXIS network
nxis.org
• single sign-on,
federated identity
• leverages existing bc.nxis.org
authentication technologies
© Metalogic Software Corporation, March 2006
nl.nxis.org
ns.nxis.org
on.nxis.org
DACS Jurisdiction
An autonomous administrative entity
•
•
provides authentication services for its users (if
applicable)
assigns access to its Web services
Jurisdictions have a well-known, unique,
name assigned within the federation:
•
NXIS::BC, NXIS::ON, NXIS::PUBLIC etc
Jurisdictions participate in a circle-of-trust
through a shared DACS secret key
© Metalogic Software Corporation, March 2006
DACS User identity
Each user has a home jurisdiction
•
users are authenticated by a server in their home
jurisdiction
username = Federation + Jurisdiction +
Username
•
NXIS::METALOGIC:rmorriso
•
NXIS::PUBLIC:[email protected]
Role information may be assigned to user
at authentication time, tested for at
access time
© Metalogic Software Corporation, March 2006
Swift Auth Single Sign-on
User may be challenged to authenticate at
any DACS jurisdiction:
•
•
•
user provides username/password, X.509 certificate,
etc relative to home jurisdiction
authentication request is channeled to appropriate
DACS server at home jurisdiction; native
authentication is applied
DACS itself does not do authentication
Single-signon
•
on success, user assumes a federation-wide identity
© Metalogic Software Corporation, March 2006
DACS User Credentials
Secure, tamper-proof, kept private via SSL
Expire or may be revoked immediately by
the authenticating (home) jurisdiction
A user may invoke a DACS signout service
to invalidate credentials
Web browser implementation based on
Netscape cookie specification
Exportable to affiliated federations
© Metalogic Software Corporation, March 2006
Stop reinventing access control!
We don’t re-implement database
management with each new application
we write – why do we continue to
custom code access control?
DACS can do for access control what
persistence frameworks like Hibernate
have done for data access.
© Metalogic Software Corporation, March 2006
METALOGIC
s o f
t w a r e
Barry Brachman
[email protected]
Rick Morrison
[email protected]
Further information on the
Swift Auth Product Family
Swift Auth Product Page:
http://metalogicsoftware.ca/products
© Metalogic Software Corporation 2004-2006