JBoss.orgCommunity Documentation

JBoss Authorization Server

Reference Guide

Preview Release


1. Introduction
1.1. Authorization
1.1.1. Clean Separation between Security Logic and Application Logic
1.1.2. Flexibility to apply Security Logic to arbitrary Runtime information
1.1.3. Runtime Management of Security Policy
1.1.4. A user friendly Developer API
2. Concepts
2.1. Resource
2.2. Action
2.3. Subject
2.4. Environment
2.5. Attribute
2.6. Policy
2.7. Target
2.8. Rule
3. Architecture
3.1. Overall Architecture
3.1.1. Application Framework
3.1.2. Authorization Server
4. Developer API
4.1. Developer API
5. Profiles
5.1. Http Profile
5.2. Portal Profile
5.3. Seam Profile
6. Policy Store SPI
6.1. Policy Store SPI
7. Examples

JBoss Authorization Server architecture consists of two components:

Application Framework consists of a Developer API that is used to integrate an Authorization layer for your application. This allows your Application components to be free from any embedded Security Logic. The Framework consists of entities that can be used to create custom Authorization layers within the context of your application, and with Profiles for infrastructure tiers that allows you to integrate Authorization layers as a simple drop in, without requiring any coding (Declarative Security Policy).

Profiles are complete implementations of an Authorization layer within the context of the infrastructure tier in question. Examples of such profiles are the HTTP Profile for the HTTP tier, Portal Profile for a Portal/Portlet Container, Seam Profile for a Web Tier, EJB Profile for the Service Tier, Hibernate/JPA Profile for the Data Tier, etc

Each Profile will produce an Authorization Context with Attribute Values that make sense within the Context of that tier. Here is a simple snapshot of what a "Permit" Authorization Context would look like for a simple Policy Rule in each infrastructure tier:

"Allow Writing to a File '/developer/index.html', if User is in Role 'Developer'":

Note: Which infrastructure profiles you decide to activate within a single Enterprise application is dependent upon the Security requirements of the application, and the corresponding Policy makeup.

Profile Implementations are expected to be complete with the following features:

A Developer API is provided by the Framework to develop custom Authorization functionality or for developing Authorization Profiles discussed above. The Developer API is split into two types. The very low-level API which presents components for the Authorization Concepts discussed in the Concepts Chapter. It also provides a higher-level API consisting of Application level components that are built on top of the low-level API. The Authorization Server comes packaged with a set of core components which will be discussed in more detail in the Developer API Chapter

Developers can easily create their own custom components using these low-level and/or higher-level components and have these components easily processed by the Authorization Server.

The Developer API is used to create the following Authorization functionality:

  • Custom Authorization Layer
  • Custom Provisioning Functionality such as Security GUI, Command Line tools, etc
  • Custom Components
  • More Profiles

This component provides the runtime, the rules engine, and policy store which performs evaluation of Authorization requests against the Authorization Policies for the applications. It is used by the Application/Profile-level Authorization layer to route requests and correspondingly receive "Permit" or "Deny" responses. The functionality of the Server is split into the following concerns: