Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Version status: 0.0.1 beta, used in production


Depends on Apache Shiro 1.0.0-incubating
Documentation status: draft, to be reviewed


Creating security checks in your application code is labor-intensive and even a dangerous practice as you can very easily miss a check and leave a big security hole open. Standard container-managed authentication and authorization was create to address this issue, but as a role and URL-based security, it's typically too constricting for modern web applications. With Tapestry, it's relatively easy to get started with more generic security checks by creating custom filters and dispatchers, but really, every user of Tapestry shouldn't need to create their own security framework. Developing comprehensive, proven bullet-proof security framework is difficult and therefore, Tynamo's tapestry-security module provides tight integration with Apache Shiro, an established, high-performing and easy-to-use security framework, for Tapestry applications.

Using security

There are several aspects to providing security. Technically you can either hide functionality from user's view if he doesn't have permissions to it, visibly disable or lock certain functionality or display errors if user is trying to do something illegal. There are several possible integration points for making security checks: for example, you may restrict users' access to certain URLs, secure access to the data itself or make specific checks before executing certain functionality. Tapestry-security module supports all of the above types of authorization.

Shiro is modular and extensible, but to get started, you need to know three key Shiro concepts: realms, filters and security configuration. A realm is responsible for authenticating and authorizing users, so you at least need to configure a ready-made realm, or, if you are authenticating users against your own custom database, likely need to implement your own custom realm. Typically, in your AppModule you provide a realm configuration such as:

Obviously, if your Realm needs to use other Tapestry services, your Realm implementation could also be a Tapestry service, in which case you'd just inject it in and contribute it to the WebSecurityManager.

Shiro is based on multiple filter chains which is a natural fit with tapestry's (filter) pipeline. In the typical case, you don't have to implement new filters but merely configure them to process desired urls of your application. Refer to the Shiro configuration for more information, but tapestry-security makes the default Shiro filters available so you can refer to them by name.

Shiro supports url-based permission checking out of the box. Tapestry-security also comes with several security annotations and some security components that you can use in your page classes and templates to secure specific operations or access to the page.

Providing configuration

Shiro's default configuration model uses an INI file (a property file with sections). You can use a standard Shiro INI configuration file (see Shiro's documentation for more info) with tapestry-security or you can do it all in code and with annotations.

The simplest and most typical security models are based on role permissions. Here's a simple example of configuring url/role permissions with shiro.ini:

You can do the same in code, for example:


anon and authc above refer to the Shiro filter names.

To declaratively secure your pages, you can use the following annotations:

For example, to restrict access to users with roles "admin" only, you would add a following annotation to a page class:

You can also secure access to services and service operations, for example:

Permissions are another interesting aspect of Shiro. The syntax is purposefully left open so they could be flexibly used for implementing different dynamic permission models. Currently, tapestry-security does a string match to validate the current user has been granted the permission specified with @RequiresPermissions. For example:

In the future versions of tapestry-security, we'll use permissions to specify association/instance (as opposed to role/type) permissions (such as current user can only edit his own profile information). The syntax is yet to be defined.

Security components

  • No labels