Fabric3 includes an extensible security framework that implements authentication and authorization. Authentication is typically specified as a policy intent on a binding part of binding (remote communications) configuration to perform client, server, or mutual authentication. When a client is authenticated, a security subject is associated with messages sent by the client. This security subject can then be used to authorize access to service operations based on roles.
Info |
---|
The bindings chapters contain examples of how to configure authentication since specifics vary by binding type. |
The security provider varies by runtime. The Standalone, Maven, and Ant runtimes are configured by default to use a basic security provider. The Tomcat runtime is configured with a provider that delegates to Tomcat security realms. There . Similarly, the WebLogic runtime delegates to WebLogic's security infrastructure.
Note there is also a Fabric3 security provider extension that uses Spring Security, which . This provider can be installed used in any of the Fabric3 runtimes.
Configuring The Basic Security Provider
The Standalone runtime includes a basic security provider that allows users and roles to be statically defined in a configuration file, security.xml, located in the runtime /config directory. An example file is shown below:
...
<users>
<user>
<username>foo</username>
<password>bar</password>
<roles>
<role>role1</role>
<role>role2</role>
</roles>
</user>
</users>
In the Maven runtime, the same security information is configured using a systemConfig entry:
...
<systemConfig>
<\!\[CDATA\[
<config>
<users>
<user>
<username>foo</username>
<password>bar</password>
</user>
</users>
</config>
\]\]>
</systemConfig>
Using Authentication
Authentication is typically enabled on a binding configuration. Please refer to the binding chapters for specific examples.
Using Authorization
The Fabric3 API includes the org.fabric3.api.annotation.security.RolesAllowed annotation, which is used to specify roles required to execute a portion of code. The RolesAllowed annotation can be placed on a method or class (in which case it will be applied to all methods contained in the class) to restrict access to security subjects with certain roles as follows:
...
public class SecureRolesServiceImpl implements SecureService {
@RolesAllowed({"role1", "role2"})
public void call() \{
// ...
}
}
Note that the current security subject can be injected using the SCA @Context annotation on a field or setter method that takes the SCA _RequestContext_ type. Alternatively, additional Fabric3 APIs can be accessed by using the _org.fabric3.api.Fabric3RequestContext_ type in place of the SCA _RequestContext_ type.
h2. Simulating Authentication in Integration Tests
In integration test environments, it is often required to simulate authentication credentials. For example, a test client may need to supply credentials to authenticate with the secure service it tests. Fabric3 JUnit test components can be configured with authentication credentials, and those credentials propagated over a remote transport such as Web Services. The following shows how to simulate username/password credentials:
{code:xml}
<component name="SecurityTest">
<f3:junit class="...">
<configuration>
<username>scott</username>
<password>wombat</password>
</configuration>
</f3:junit>
<reference name="service" target="SCASecureService"/>
</component>
Custom Security Providers
The basic provider can be replaced by a more capability (and dynamic) alternative by substituting the fabric3-security-impl.jar in the extensions repository. For details on implementing an alternative provider, see the Javadoc for the org.fabric3.spi.security package in fabric3-spi.The following sections detail how to enable security in application code and create custom security providers:
Page Tree | ||
---|---|---|
|