I'm not sure if those paths have changed, ever.

Adding a jboss/ prefix in the context could make sense for newly added applications, but changing it for the legacy ones is probably a bad idea.

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

I don't see this as a problem for jbossas 5.

For the EAP we could also work on an extended port mapping function that allows for any managed metadata to be overwritten such that there is a secured-metdata configuration override that does the typical security changes.