[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?
by dimitris@jboss.org
The full trace:
| Caused by: java.io.FileNotFoundException: X:\cvs\jboss-public\jboss-head\build\o
| utput\jboss-5.0.0.CR1\bin\META-INF\noop.xml
| at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnecti
| on.java:95)
| at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLC
| onnection.java:104)
| at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown So
| urce)
| at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
| at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityRefer
| ence(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
| Dispatcher.dispatch(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
| known Source)
| at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
| at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
| at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
| at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:98)
| at org.jboss.deployers.vfs.spi.deployer.JAXPDeployer.doParse(JAXPDeploye
| r.java:179)
| at org.jboss.deployers.vfs.spi.deployer.JAXPDeployer.parse(JAXPDeployer.
| java:150)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse
| (AbstractVFSParsingDeployer.java:184)
| at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO
| utput.createMetaData(AbstractParsingDeployerWithOutput.java:330)
| ... 26 more
| 20:44:38,625 WARN [HDScanner] Failed to process changes
| org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incompl
| ete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| vfsfile:/X:/cvs/jboss-public/jboss-head/build/output/jboss-5.0.0.CR1/server/defa
| ult/deploy/x.sar/ -> java.io.FileNotFoundException: X:\cvs\jboss-public\jboss-he
| ad\build\output\jboss-5.0.0.CR1\bin\META-INF\noop.xml
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154411#4154411
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154411
16 years, 8 months
[Design of Management Features on JBoss] - Re: Common context root for management web apps, web invoker
by lhoriman
To anticipate the response "just secure the invokers ala the SecureTheInvokers wiki page", this still leaves the services vulnerable to:
* Dictionary attacks and brute force attacks
* Leaked passwords
* Ex-employees who still know the password(s)
In every major enterprise environment I've worked in (or been responsible for), there has been an explicit policy forbidding public access to administrative login interfaces, even if they are password protected. Remote access to internal company resources must first be authenticated through a VPN (usually, with two-factor authentication ala RSA SecureID). When an employee leaves, their VPN account is disabled so even if a developer or administrator has jboss passwords, they cannot use them.
To anticipate the response "enable SecureTheInvokers with a LoginModule that authenticates against the VPN/two-factor source", I respond:
* This is not always possible. Network designs (ie, firewalls) sometimes prevent public appsevers from accessing the authentication servers via LDAP (or whatever protocol).
* As someone who has actually done this for some services, it's not easy, and doing group-based role setting requires a custom LoginModule. Most administrators will not bother.
* It's painfully easy for a junior admin to deploy a new appserver and get the login config wrong, exposing critical vulnerable services.
Thus:
One critical part of securing web services is denying public access to administrative login interfaces. Currently this must be done by several explicit denial rules on the loadbalancer, one for each administrative web context root. When JBoss changes a context root or adds a new service with a new context, the loadbalancer rules can become stale and thus leave critical services unprotected. This would be resolved easily if all administrative services were shared under a single web context root such as "/jboss".
Jeff
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154407#4154407
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154407
16 years, 8 months