Tweet

This is the final article in a three-part series on Web 2.0 access control.

In preceding articles we descibed how the principles of user-centric identity and organization-centric authorization support the "outsourcing" of access control
in Web application development. We recommended a set of access control "best practices."

In this article we look at an example of these practices in action using a dummy PHP application called FooApp. The examples make use of DACS – the Distributed Access Control System. DACS provides lightweight, high-performance distributed access control and single sign-on across a federation of Apache HTTP servers.

At the heart of DACS is a powerful “rules engine” which enforces organization access control policies expressed in a compact XML syntax. The DACS engine is the basis for an Apache module, mod_auth_dacs which implements access control on all “DACS-wrapped” Web content and services served by Apache. The same rules engine drives a standalone command,(dacscheck), which may be used by any application (Web or otherwise) to externalize access control logic. Another command, dacstransform, dynamically customizes the content of an HTTP response based on attributes of the request. The author’s demonstration site provides numerous examples of DACS lightweight access control.

An Example

Enough of the abstract discussion! Let’s see how to put these practices to work in our dummy PHP application FooApp. A working version is here: https://demo.fedroot.com/cookbook/fooapp.php.

Here are the FooApp requirements:

>Users must authenticate using an OpenID in order to access FooApp.
>Unauthenticated users are redirected to a login page where they may register, login or read instructions on how to obtain an OpenID.
>Authenticated users are presented with a page containing the FooMenu. Administrator functions are disabled in FooMenu for regular users, but are enabled for users who have been granted ADMIN role. (Hey, it’s only an example!)

FooApp consists of three files: fooapp.php, login.html and start.html. Access control is expressed externally in DACS rules files acl-fooapp.0 and acl-fooapp.1.

fooapp.php excerpted below, calls the DACS command dacscheck to determine if access to FooApp should be granted. If dacscheck exits 0, access is permitted and start.html is emitted, else login.html is emitted. This is an example of "outsourcing" access control. FooApp itself does no authentication or access control. Rather it reuses external services like OpenID for login and dacscheck for authorization.


$user = $_SERVER["REMOTE_USER"]; putenv("REMOTE_USER=$user"); system("/usr/local/dacs/bin/dacscheck -q –icgi rules /home/fooapp/rules /FooApp", $st); if ($st == 0) { // emit start page echo("<h3 align=\"center\">Welcome $user</h3>"); system("/usr/local/dacs/bin/dacstransform rules /home/fooapp/rules –i \"$user\" /home/fooapp/start.html");
} else { // emit login page system("/usr/local/dacs/bin/dacstransform –rules /home/fooapp/rules –i \"$user\" /home/fooapp/login.html");
}

The business logic for access control is localized in DACS ACL files like the following:


<acl_rule>
<services>
<service url_pattern="/FooApp"/>
</services>
<rule order="allow,deny">
<allow>
user("auth")
</allow>
</rule>
</acl_rule>


The rule above states that access should be granted to the resource named “/FooApp” if the user is authenticated, else denied. If the user is not authenticated, the dacscheck command exits 0 and fooapp.php calls the dacstransform command on the HTML fragment contained in login.html to emit a (possibly customized) login page. If the user is authenticated, dacstransform is called on start.html to emit the FooMenu.

Here an excerpt of start.html defining the FooMenu:


<select name="menu" size=1 onChange="visit()">
<option selected value="">Select</option>
<!--DACS begin="auth" -->
<option value="https://demo.fedroot.com//fooapp.php?op=something">
Do Something!
</option>
<!--DACS begin="admin" -->
<option value="https://demo.fedroot.com/fooapp.php?op=anything">
Do Anything!
</option>
<!--DACS end="admin" -->
<option value="https://demo.fedroot.com/fooapp.php?op=prefs">
Edit Preferences
</option>
<option value="https://demo.fedroot.com/dacs/dacs_signout">
Exit FooApp
</option>
<!--DACS end="auth" -->
</select>


Notice the special DACS comments in the source HTML:
<!--DACS begin="admin" --> ... <!--DACS end="admin" --> These comments control the behavior of the dacstransform as it parses the input file. If a DACS rule is found that matches the labeled region and evaluates to ALLOW, dacstransform includes the contents of the region in its output. Two regions are defined in start.html: “auth” which defines content to be emitted for any authenticated user and a nested region, “admin” which is to be emitted only for authenticated users with ADMIN role. The “Do Something!” and “Exit FooApp” menu options are included in the output of dacstransform for all authenticated users. The “Do Anything!” option will only be included in FooMenu for users with admin role.

Here is the data file acl-fooapp.1 defining the access control semantics for the “auth” and “admin” text regions used by dacstransform:

<acl_rule>
<services>
<service url_pattern="/login.html"/>
<service url_pattern="/start.html"/>
</services>
<rule order="allow,deny">
<precondition>
<predicate>
${Args::region} eq "admin"
</predicate>
</precondition>
<allow>
user("%admin")
</allow>
</rule>
<rule order="allow,deny">
<precondition>
<predicate>
${Args::region} eq "auth"
</predicate>
</precondition>
<allow>
user("auth")
</allow>
</rule>
</acl_rule>


FooApp is obviously a highly simplified example. In this simple rule there is a direct mapping from text regions to authentication status and role, but quite rich conditions on a request may be expressed if that is desired. Details are available in the DACS man pages: dacs.acls and dacs.exprs.

The important point to note is that the same rules that drive the dynamic customization of HTML output also may be used to control out-of-band access to related Web services or even unrelated applications to which the same roles apply. Thereis no back door. We have only scratched the surface of what can be expressed in the DACS access control language, but we hope we have demonstrated the benefits that can be achieved by separating the concerns of application logic from access control through a data driven approach.

To try the example yourself, first build and install DACS from the current release on SourceForgeSourceForge. For your convenience a Zip file has been created containing the files used in the example. Only fooapp.php must be accessible via a URL. The data files login.html and start.html
need only be readable by the Web server user.

Conclusion

In this series we have argued the merits of user-centric identity and organization-centric authorization as foundations for Web 2.0. We described a collection of lightweight “best practices” for developers and illustrated their application in a simple example. We believe that the best hope for progress toward the vision of Web 2.0 is through many small steps. We hope that you will be inspired to embrace lightweight approaches to access control and play an active part in the creation of the next generation Web.

References

DACS – the Distributed Access Control System: a lightweight distributed authentication and authorization framework for the federated Web.

Rule-based access control, Barry Brachman, Distributed Systems Software.


DACS Demonstration SiteMetalogi Software.

OpenID a decentralized identity based on “ownership” of a URL at an OpenID-enabled server.

Rick Morrison is President of Metalogic Software Corporation, a software development firm specializing in federated applications and services for Web 2.0. With DSS - Distributed Systems Software, Metalogic is co-developer of DACS - the Distributed Access Control System (http://dacs.dss.ca). Rick has over fifteen years experience developing innovative software for the Web in commercial, government and research settings. Contact Rick at: http://2idi.com/contact/@metalogicsoftware.

No comments yet. Be the first one to comment.