It seems unlikely that the applications security *requirements* would change
from test to production. More likely the binding to the external security
infrastructure (authentication, authorization) would change.
Werner Keil wrote on 05/11/12 05:20:
> Bill/all,
>
> Aside from questions the other EGs shall be able to discuss (e.g. if the likes
> of 351 would pick up a Java EE SecurityManager or need to declare their own
> JSR-specific one) I strongly agree with the separate file location at least as
> an alternative to inside an application archive (WAR, EAR,...)
>
> This makes it much easier, for real life build and configuration management
> teams to adjust that e.g. from a stage like *"Test"* to *"PreProd"* or
> *"Prod"* without having to rebuild the entire application, if security is the
> only one that changes.
>
> Werner
>
> On Fri, May 11, 2012 at 7:15 AM, Markus Eisele <myfear_at_web.de
> <mailto:myfear_at_web.de>> wrote:
>
> Hi Bill,
> hi all,
>
> Thanks for the effort! It looks great. Here is my feedback:
>
> - I like (!) the short tag names! :) And I still like to have a
> <xs:element type="xs:string" name="description" minOccurs="0"/> in
> the schema. Some admin UI will display the permissions.xml in a
> beautified format and would be happy to have this tag.
>
> - I checked with some installations I know and the property expansion
> still is something I believe is of value here. Going further looking
> at EE.6-2 and the [1] comment I would propose to define a couple of
> default properties that should be available.
> a) application specific temp dir (the javax.servlet.context.tempdir)
> b) application working directory (expanded deployments)
> c) "user home" (to read additional, external configuration files)
> Any further ideas/thoughts here?
>
> - The permission declarations has to be a separate file. And I like
> the idea to expand this mechanism to library jars subsequently.
>
> - there is one thing that I would like to discuss further:
> EE.6.2.2.1 => 4th §:
> "If an application module does not contain a declaration of required
> security permissions and deployment otherwise succeeds, the Java EE product
> must grant the application components the permissions established by
> the security
> policy of the installation. "
>
> and 5th §
> Note that, on some installations of Java EE products, the security
> policy of the installation may be such that applications are granted
> fewer permissions than
> those defined in Table EE 6-2 and ...
>
> I strongly believe that the minimum rights for an application missing
> a permissions.xml should be the EE 7 platform default (Table EE.6-2).
> It doesn't make any sense to me to successfully deploy an application
> which isn't able to run because of the security policy of the
> installation. And yes, I have read the 2nd § in the same chapter and
> you are right. So I am with Adam here, that we
>
> > "force" the application server vendor to provide a prepared policy with
> the restrictions defined in the Java EE / EJB specs.
>
> And I would even go further and define one for each profile.
>
> #1 reason is to make it dead simple for developers to install a server
> with the appropriate (minimum Java EE 7) rights. Messing around with
> such a detailed security configuration is something that shouldn't
> hinder anybody writing a Java EE 7 application. Security isn't funny
> and never will be. Let's hide it as much as possible.
>
> - M
>
>
>
> On 10 May 2012 23:44, Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>> wrote:
> > Larry McCay, Ron Monzillo, and I have drafted updates to the platform
> > spec to describe the new security manager requirements we've previously
> > agreed on. It turned out to be surprisingly difficult to write these
> > requirements in a way that captures some of the subtlety involved.
> > Please review these updated spec sections carefully and ask questions
> > if you're not sure exactly what the requirements are.
> >
> > The proposed spec updates are here, and will be folded into the draft
> > spec soon (obviously the numbering and such will be fixed at that point):
> >
> >
> http://java.net/projects/javaee-spec/downloads/download/ee-sec-mgr-00-ljm.pdf
> >
> > Thanks.
>
>