xweld-security provides a pluggable architecture for defining user credentials based on a metadata-driven runtime context. xweld-security implements a generic API with a default implementation that can be swapped out or plugged in at application startup. This means that applications written to this API can migrate to another implementation later via configuration.

The xweld-security API was designed with the following criteria in mind:
  • Expressiveness
  • Robustness
  • Security
  • Ease of implementation


Application security may be as coarse- or fine-grained as needed in constraining the entitlements of users. By way of industry parallels, this is comparable in design and intent to the well-established Output Content Protection model that accompanies Windows DRM. It should also be noted that the xweld-security API is not, of itself, predicated on any specific implementation for determining user-level access rights, though a role-based permissions model based on JAAS is provided as a foundational construct by <xweld/>. This affords applications flexibility with respect to integration with their own authentication and authorization architectures, as well as a default implementation based on industry standards.


By default, xweld-security assumes that a user is granted no access rights of any sort, and relaxes that constraint only to the extent prescribed by the governing application.


Revocation is a key concept for enterprise security, and xweld-security ensures that it is applied rigorously and without exception. xweld-security stringently enforces real-time revocation of access rights at runtime. Should a user’s permissions change, the governing application notifies a security provider that a change has occurred for that user.

xweld-security’s revocation model is intended to provide maximum flexibility for the application. Specifically, enterprise DRM can involve advanced features such as expiry, revocation lists, and policy-based rights amendment with and without administrator intervention. The application can implement such features as appropriate, with xweld-security being agnostic as to the details of those implementations. xweld-security is only involved in the enforcement of revocation, not the administration of policies that lead to revocation.

The xweld-security module has support for non-repudiation. Specifically, the user is authenticated by a pluggable provider mechanism and a default implementation using JAAS authentication is provided out of the box.

Ease of Implementation

xweld-security attempts to anticipate the security requirements common to most enterprise applications, and provide out-of-the-box abstractions and implementations that greatly simplify the programming effort for a given application.

To accomplish this, xweld-security provides several reusable components:
  • Abstract classes that implement the behaviors common to most applications, with abstract methods that are overridden by applications to complete the pluggable logic; and
  • A concrete instance of pluggable logic that also extends the abstract noted above, and that implements security using a RBAC model and industry standard JAAS for authentication.

Primary Features and Benefits

Features that make xweld-security an attractive mechanism for implementing security in your financial application include:

  • A runtime-configurable Security API that can support multiple implementations in multiple runtime environments
  • It provides default implementation that supports users, roles and permissions (RBAC)
  • It is independent of any application server or runtime container
  • It supports centralized authentication using the industry-standard JAAS framework
  • It supports role-based partitioning of data based on configurable value sets
  • It supports arbitrary number and type of user defaults and preference settings

Key Concepts

Contexts for Implementing xweld-security

There are three possible contexts in which xweld-security can be implemented:

  • Providing security for a web application; for example, using it in a Vaadin front end
  • Providing data access control on the server side, such as a domain model
  • Providing user identification to an audit trail, by identifying the user who is updating the database and feeding that information to the audit trail

Your application may define any number of authorization and authentication providers and configure their use at runtime. The API is general enough to support any implementation, such as Spring Security or of course, the default implementation of <xweld/>. Using this API ensures that a specific implementation in any application is completely pluggable.

Packages and Classes

xweld-security includes the following packages:

  • - defines the security API and the default implementation-based classes
  • com.xweld.authentication - authentication implementation for the default JAAS provider
  • com.xweld.authorization - authorization implementation for the default RBAC provider

IAuthorizationProvider, IRevocationProvider and IRevocationListener

The IRevocationListener interface accepts notifications that permissions have changed for a given user and context. The pattern adopted by xweld-security is that the governing application is expected to provide an IRevocationProvider to which the application associates itself as an IRevocationListener.

The IRevocationProvider interface provides a mechanism by which an application can listen for revocation notifications generated from within the governing application.

The governing application provides user-based permissions to a secure component by providing an implementation of the ISecurityProvider interface. This interface gives a securable module and the application a common means for applying security restrictions. This interface also provides the mechanism by which an application can listen for revocations to user-based security permissions. The security system reserves the names of two users: "System" and "Administrator".

The RBACAuthorizationProvider and JAASAuthenticationProvider Implementation

The default implementation of the security provider framework is a simple authentication and access-control framework based on JAAS and It is the de-facto standard for securing <xweld/>-based applications. It is optimized for service layer, domain and DAO authorization, and uses the externalized authentication of any JAAS provider. The basic model externalizes authentication of the user via JAAS configuration while authorization is configured as part of the application domain.

The default security model is based on Users (a, Roles (a, and Permissions ( each User has a collection of Roles; each Role has a collection of Permissions. A permission has a list of associated Actions.

The default implementation is optimized for the common use case in many applications, that is, centralized authentication and application-managed role definitions as part of the JPA-based domain model.

DefaultAuthorizationProvider and DefualtAuthenticationProvider Tiers

The default providers offer three tiers of security:

  • Authentication – Externalized authentication using JAAS.
  • Entitlement to access functions (class and methods), for example, access to view a particular application page.
  • Context-based access to data – Access security may be applied to a universe of data, and this access restriction may be customized to a specific user sharing a role with another user. For example, two users may be assigned the ‘Trader’ role, while one user is restricted to US Equities and the other is restricted to Commodities trading. Access restrictions can be applied to determine what data the user is able to operate on, and which CRUD operations (Create Read Update Delete) are available. This means that two users in the same role can have two different views (that is, two different contexts) on the universe of data.

Users and Roles

The default security providers implements a Role-Based Access Control (RBAC) model. Roles are collections of entitlements or permissions. Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user; this simplifies common operations, such as adding a user, or changing a user's department.

RBAC differs from access control lists (ACLs) used in traditional discretionary access control systems, in that it assigns permissions to specific operations with meaning in the organization, rather than to low-level data objects. For example, an access control list could be used to grant or deny write access to a particular system file, but it would not dictate how that file could be changed. In an RBAC system, an operation might be to create a 'credit account' transaction in a financial application for example. The assignment of permission to perform a particular operation is meaningful, because the operations are granular with meaning within the application.

An RBAC model provides the following features:

  • Authentication – This is the first level of security, which confirms the application user’s identity. This is a two-step process: first identification, which consists of the user stating who they are; then authentication, which consists of the user proving who they are. Authentication is usually done through user accounts and passwords.
  • Authorization – Authorizations define what a user can see, do, and modify in an application. By default, all permissions are forbidden. Specific permissions are then granted to open possibilities.
  • Audit – Auditing in xweld-security is managed using the xweld audit mechanism.

User Properties

The IUser interface and the default implementation by the com.xweld.authentication.User class supports the addition of custom or application specific property types so that meta-data may be associated with users. This is particularly useful when defining context sensitive permissions based on that meta-data. For example, an application could associate a list of currencies with each user and define permissions that inspect that list at run time to enforce permissions based on the meta-data values. Each custom property must be Serializable.

Permissions are typicaly defined for an application based on the functionality supported by that application. Hence, a setup tool (see <xweld/>-runtime) is typicaly used to install the various permissions for that application. Once defined, roles may be created from collections of permissions and then associated with Users.

Using the @Permissioned Annotation

The default security providers supports the @Permissioned annotation on class member functions. For example supposed we have the following class:

public class Sample implements Serializable
  Double one = Double.valueOf(1.0);

  @Permissioned(name = "A", actions = "one, two")
  public void doA()
    System.out.println("I am authorized to call method A");
  @Permissioned(name = "B", type = ContextPermission.class)
  public void doB()
    System.out.println("I am authorized to call method B");

Then, if permissions A and B are defined in the system (typically done by the setup tool for an application), and assigned to a role associated with the current user, then the check:

// get the currect security provider from the runtime context
IAuthorizationProvider provider;

provider.hasPermission(new Sample(), "A");

will return true.

Contact Us

For more information, please contact us at


Copyright © 1999-2012 Free North Alliance Inc. All Rights Reserved.

The contents of this web site, including all images, text, graphics and software, are the sole property of Free North Alliance Inc. and its agents. Unauthorized use or transmission is strictly forbidden by international copyright law. View (91.3 KB) John Free, 05 March 2014 04:59 PM View (116 KB) John Free, 05 March 2014 05:06 PM