Jason T. Greene wrote on 03/09/12 12:05:
>> Developers already complain that portability of their application suffers
>> greatly once they have to deal with security. Every product provides a
>> different mechanism for configuring securing, setting passwords, etc.
>> It's impossible to write a tutorial that tells people how to write
>> portable and secure *Java EE* applications because you quickly have to
>> delve into the intricacies of configuring security for GlassFish or
>> WebLogic or JBoss or WebSphere or ... Because of that, too many people
>> just ignore security, or suffer from poor and inconsistent advice for how
>> to secure their applications. We should be making it easier for people
>> to write secure applications for the Java EE *platform*.
>>
>> Also, remember that we're targeting PaaS with Java EE 7. In a PaaS
>> environment it's much less likely that you'll have direct control over
>> the admin capabilities of the underlying app server. And there's
>> probably not a system administrator that you can appeal to to set this
>> up for you.
>
> I am not sure this really improves usability. Let's say I am a developer and I
> need to change a password to a database (recurring schedule, reaction to a
> breach etc). Now I have to rebuild (including using a burdensome toolchain) and
> redeploy my entire application?
>
> Now contrast that to the PAAS provider doing a typical security management web
> page, where you just edit the password to a known alias/reference in the
> deployment, quickly generate a certificate (perhaps even automate the process
> with a Root CA),
This is certainly not the solution to all problems. I agree that there
will be scenarios where you won't want to include this information in
the application.
Note that I don't think we currently have any requirements around your
ability to change such security information and have a running application
see the changes. The only portable way to update an application is to
redeploy it. Assuming everyone already allows you to make these changes
dynamically, we would need to add a spec requirement that "there must be
a way to ...".
>> Remember also that we're trying to create a platform that is both easy
>> for developers to use when getting started *and* scales to enterprise
>> deployments. If we *only* allowed things in the platform that made
>> sense for large enterprise deployments, we would lose lots of developers.
>> That's why we allow passwords to be included in applications at all.
>> It's not because we expect large enterprise deployments to have
>> applications
>> with clear text passwords embedded all over them.
>
> I certainly agree with the sentiment to make security easy. It just seems like
> there is a better way than further encouraging packaging within the deployment.
> Like for example, if a common transmission mechanism is desired between PAAS
> providers, we could define a standard for a *separate* security bundle file,
> which could be generated either via tools, or the provider, and then then it
> becomes clear, that this file needs to be kept safe.
If people feel that it would be both more secure and sufficiently
convenient to provide this information in a bundle separate from
the application, we could consider that. We already have the ability
to provide deployment descriptors separately from the application so
we could enhance that mechanism to support this use case as well.
We would have to define whether updating this information without
changing the application bundle is equivalent to redeployment (which
in the worst case it seems like it would be), or whether there would
be requirements on what you're allowed to change while the application
is running, and when the application is required to see those changes.