[PicketBox Development] - JBoss AS7: securing subsystem web applications
by Tristan Tarrant
Tristan Tarrant [https://community.jboss.org/people/NadirX] modified the document:
"JBoss AS7: securing subsystem web applications"
To view the document, visit: https://community.jboss.org/docs/DOC-18274
--------------------------------------------------------------
In JBoss AS7 it is possible for extension subsystems to publish web applications programmatically (i.e. without going through the deployer). This, for example, is how the default "welcome" web app in AS7 works (look at web/src/main/java/org/jboss/as/web/WelcomeContextService.java and web/src/main/java/org/jboss/as/web/WelcomeContextConsoleServlet.java in the AS7 source to see how it is done).
Using the org.apache.catalina.core.StandardContext API it is possible to configure all the aspects that are accessible via the usual web.xml declarative configuration, including security constraints and roles. The class that wires all that configuration into the container is org.apache.catalina.startup.ContextConfig which needs to be added to the context as a lifecycle listener. Unfortunately, in JBossWeb, that class has been changed not to hook up the authenticators. Instead, a specialized org.jboss.as.web.deployment.JBossContextConfig has to be used. JBossContextConfig however requires a DeploymentUnit, a container for metadata collected from web.xml, jboss-web.xml and annotations, and setting it up is non-trivial (look at the webservices subsystem for an example of a dynamically generated DeploymentUnit based on JAXWS annotations).
An alternative solution is to use the following subclass of the default ContextConfig:
import org.apache.catalina.startup.ContextConfig;
import org.jboss.as.web.WebLogger;
public class SecureContextConfig extends ContextConfig {
@Override
protected void completeConfig() {
if (ok) {
resolveServletSecurity();
}
if (ok) {
validateSecurityRoles();
}
// Configure an authenticator if we need one
if (ok) {
authenticatorConfig();
}
// Make our application unavailable if problems were encountered
if (!ok) {
WebLogger.WEB_LOGGER.unavailable(context.getName());
context.setConfigured(false);
}
}
}
Together with the attached SecurityContext custom valve you can then setup your context's security as follows (I'm skipping all context configuration related to docbase, servlets, etc and focusing only on the security bits):
StandardContext context = new StandardContext();
context.addLifecycleListener(new SecureContextConfig());
SecurityConstraint constraint = new SecurityConstraint();
SecurityCollection webCollection = new SecurityCollection();
webCollection.addPattern("/*");
webCollection.addMethod("GET");
constraint.addCollection(webCollection);
constraint.setAuthConstraint(true);
constraint.addAuthRole("MyRole");
context.addConstraint(constraint);
LoginConfig login = new LoginConfig();
login.setAuthMethod("BASIC");
login.setRealmName("ApplicationRealm");
context.setLoginConfig(login);
JBossWebRealm realm = new JBossWebRealm();
SecurityDomainContext securityDomainContext = securityDomainContextInjector.getValue();
realm.setAuthenticationManager(securityDomainContext.getAuthenticationManager());
realm.setAuthorizationManager(securityDomainContext.getAuthorizationManager());
realm.setMappingManager(securityDomainContext.getMappingManager());
realm.setAuditManager(securityDomainContext.getAuditManager());
context.setRealm(realm);
context.addValve(new SecurityContext("/contextPath", securityDomain));
Don't forget to add the required security domain as a dependency to your service when constructing your ServiceBuilder
builder.addDependency(
SecurityDomainService.SERVICE_NAME.append(securityDomain),
SecurityDomainContext.class,
service.getSecurityDomainContextInjector()
);
Out of the box, the authenticator will automatically support BASIC, FORM, DIGEST and CLIENT-CERT. If you need SPNEGO, add the following valve
if("SPNEGO".equals(authMethod)) {
context.addValve(new NegotiationAuthenticator());
}
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18274]
Create a new document in PicketBox Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 7 months
[JBoss AS 7 Development] - Error during (re) adding connection factory using CLI
by Ramesh Reddy
Ramesh Reddy [https://community.jboss.org/people/rareddy] created the discussion
"Error during (re) adding connection factory using CLI"
To view the discussion, visit: https://community.jboss.org/message/734622#734622
--------------------------------------------------------------
Hi,
In Teiid, we make use of CLI to create connection factories for tooling purposes. When I run the following CLI commands
/subsystem=resource-adapters/resource-adapter=wsDS:add(archive=teiid-connector-ws.rar, transaction-support=NoTransaction)
/subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS:add(jndi-name=java:/wsDS, class-name=org.teiid.resource.adapter.ws.WSManagedConnectionFactory, enabled=true, use-java-context=true)
/subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS/config-properties=EndPoint:add(value={end_point})
/subsystem=resource-adapters/resource-adapter=wsDS:activate
It creates a resource adapter and then creates connection factory, all is good. Now execute
/subsystem=resource-adapters/resource-adapter=wsDS:remove
the connection factory along with the resource adapter removed. Now re-execute same code above to re-create the resource adapter and connection factory, it fails with following message on the AS7 console window
20:48:02,169 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.msc.service.StartException in service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:127)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
Caused by: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
at org.jboss.jca.core.mdr.SimpleMetadataRepository.getResourceAdapter(SimpleMetadataRepository.java:150)
at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:87)
... 5 more
Can somebody please tell me what I may be doing wrong or is this a bug in code?
Thank you
Ramesh..
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/734622#734622]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 7 months
[JBoss Transactions Development] - XTSTestingCurrentStatus
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] modified the document:
"XTSTestingCurrentStatus"
To view the document, visit: https://community.jboss.org/docs/DOC-17242
--------------------------------------------------------------
h1. XTS Testing
h1. Current Status and Roadmap
h1.
This Document describes the current status of the XTS tests and what technology they use. There are currently three sets of tests, Unit, Interop and recovery. Each of these is described in turn, and a list of required improvements is presented.
All improvements are targeted at Narayana 5.x unless specified otherwise.
h2. Unit tests
Each XTS component has a set of unit tests. These tests need to be ran within an instance of JBoss AS. These tests are fully automated by an Ant script ran by Hudson.
h3. Improvements
*High Priority (EAP 6.0)*
1. *Ensure AS 7 compatibility.* See issue JBTM-900 (https://issues.jboss.org/browse/JBTM-900).
2. *CI with JBossAS*. This will ensure that changes to components, we depend upon (like JbossWS), that break XTS are spotted at QE time rather than after release. (EAP 6 requirement). JBQA-5191 (https://issues.jboss.org/browse/JBQA-5191)
3. *Additional Testing*. XTS Demo tests JBQA-5194 (https://issues.jboss.org/browse/JBQA-5194)https://issues.jboss.org/browse...
*Medium Priority (Narayana 5, EAP 7)*
1. *Automate Emma and collate results*. Emma should be used to obtain coverage stats on the test run. Emma, produces individual reports per test, by default. It would be better to have these reports combined as we are concerned with the overall test coverage, rather than the coverage of each test. Ideally we would combine coverage stats over all sets of tests (unit, interop and recovery). Next step would be to improve the coverage where necessary. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority* *(**Narayana 5, EAP 7**)*
1. *Migrate to Maven*. For consistency with rest of the Narayna project. https://issues.jboss.org/browse/JBTM-945 JBTM-945
2. *Update to use Arquillian*. This would mean that that they can be ran from anywhere that can run JUnit tests, such as an IDE or maven. It would also automate the app server lifecycle and test deployment. JBTM-954 (https://issues.jboss.org/browse/JBTM-954)
3. *Remove home-brew SOAP stack*. In the past these tests used a mock/simple SOAP stack developed specifically for the tests. This stack is no longer used as the tests run within JBoss AS. This code is redundant and should be removed. https://issues.jboss.org/browse/JBTM-953 JBTM-953
h2. Interop Tests
We have two sets of interop tests that live in "XTS/interop". These are built with ant. They are each ran by deploying them as a war to a single JBoss instance which deploys the services needed by the test. This war also exposes a web interface that on request runs the tests and relays the results in the http response.
This process is automated by using ant to deploy the war and then making the http request and validating the response. See here in code for scripts: “XTS/localjunit/run-interop-tests.xml” and “XTS/localjunit/run-tests.xml”
h3. Improvements
*High Priority (EAP 6.0)*
1. *Ensure AS 7 compatibility.* See issue JBTM-905 (https://issues.jboss.org/browse/JBTM-905).
2. *Move into the AS test suite*. JBQA-5192 (https://issues.jboss.org/browse/JBQA-5192)
*Medium Priority (**Narayana 5, EAP 7**)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (**Narayana 5, EAP 7**)*
1. *Update to use Arquillian*. JBTM-955 (https://issues.jboss.org/browse/JBTM-955) JBTM-956 (https://issues.jboss.org/browse/JBTM-956)
2. *Migrate to Maven*. https://issues.jboss.org/browse/JBTM-943 JBTM-943
h2. Recovery Tests
The recovery tests are the tricky ones. At the moment we have a set of test scenarios that run in a single JBoss server invoked by a remote client. There are also a set of Byteman scripts that trigger failure at certain points in a scenario. There are many different permutations of scenario and Byteman scripts that each create a particular test.
The test scenarios log their progress through the protocol and recovery. On completion of a test run, a human needs to look over the trace and check that it looks right. This process is hard to automate as the trace produced can have many valid interleavings. This is due to the asynchronous nature of the application.
These tests are automated with a bash script, but the output traces must be verified manually by a human. The other problem is that they currently run in a single JBoss server which simulates the situation where every party in the protocol is located in the same app server and crashes & recovers at the same time (not that realistic!). In order to test with multiple servers. we would need a way of combining the traces from each server when verifying the outcome of the test. This could be done by implementing a Byteman helper class, but it would not be trivial.
h3. Improvements
*High Priority (EAP 6.0)*
1. *Move into AS test suite*. The tests are unlikely to be accepted in their current form, due to the level of manual intervention required. This improvement can not be made until we have sufficiently automated the process.
2. *Ensure AS 7 compatibility.* JBTM-923 (https://issues.jboss.org/browse/JBTM-923)
3. *Automate running*. Use Arquillian to automate the tests and generate trace output for human verification. JBQA-3926 (https://issues.jboss.org/browse/JBQA-3926) JBTM-817 (https://issues.jboss.org/browse/JBTM-817)
4. *Run as part of CI.* JBTM-1029 (https://issues.jboss.org/browse/JBTM-1029)
*Medium priority (**Narayana 5, EAP 7**)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (**Narayana 5, EAP 7**)
*
1. *Migrate to Maven.* JBTM-944 (https://issues.jboss.org/browse/JBTM-944)*
*
2. *Automate verification*. Remove the human verification steps. JBTM-949 (https://issues.jboss.org/browse/JBTM-949)
3. *Multiple Server Tests*. If step 2) is successful, we could be able to build the more complex scenarios where each party runs in its own JBoss server. https://issues.jboss.org/browse/JBTM-950 JBTM-950
4. *Additional Tests*. Andrew Dinn has provided a set of additional tests for us to consider implementing. These should be considered alongside the Emma coverage data for future work. https://issues.jboss.org/browse/JBTM-951 JBTM-951
h2.
h2. Notes
* Arquillian supports multiple JBoss servers:* https://docs.jboss.org/author/display/ARQ/Multiple+Containers https://docs.jboss.org/author/display/ARQ/Multiple+Containers
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17242]
Create a new document in JBoss Transactions Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 7 months
