JBoss.orgCommunity Documentation
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'":
Resource Attributes: [urlPattern="/developer/index.html"] Action Attributes: [parameter['action']="write"] Subject Attributes: [roles={"project_manager", "developer"}]
Resource Attributes: [Java Class="org.cms.CMS", Java Method="writeFile"] Environment Attributes: [parameter['fileName']="/developer/index.html"] Subject Attribute: [roles={"project_manager", "developer"}]
Resource Attributes: [Java Class="org.cms.domain.File"] Environment Attributes: [field['fileName']="/developer/index.html"] Subject Attributes: [roles={"project_manager", "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:
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:
This component is responsible for processing incoming Authorization requests. It routes these requests to the rules engine, which in turn responds with a 'Permit' or 'Deny' state for the request.
The rules engine used is standards-compliant and uses the industry supported XACML standard. In a nutshell, XACML is an XML based Security Rules Language, use to define Security Policies. It is also comprehensive in providing robust concepts and architecture recommendations, but its main focus is the XML-spec to define Security Policies. This system is designed in accordance with these architectural recommendations, and also uses the XACML XML-spec to represent the Security Policies.
It must be noted that the XACML spec is vast and the XML is extremely complex. However, the developers are completely insulated from any XACML XML via the Developer API. The Developer API is not the same thing as a JAXB model of the XACML spec. The Developer API consists of object oriented components from the Application domain. The Authorization runtime internally takes care of converting these components into XACML constructs, to be used by the Authorization Server.
The Authorization Server uses the JAXB model provided by the JBossXACML stack, and the XACML implementation provided by Sun Microsystems.
This component processes Provisioning requests from Applications. This results in runtime changes to Security policies, and immediate enforcement of these policies, without requiring any restarting of the infrastructure.
This SPI allows storage agnosticity for the Security Policies managed by the Server. By default, it uses relational database storage. However using the SPI you can store Policies inside JCR Repositories, LDAP repositories, or other storage locations.
The Authorization Server can be deployed and accessed by Enterprise Applications in 2 ways: Same VM Mode, Different VM mode,
In this mode the Authorization Server is deployed in the same VM as a JBoss Microcontainer Service. All service requests are local method invocations.