Date: Thu, 24 May 2012 13:14:22 +0200
On Mon, May 21, 2012 at 9:17 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> Are there any final comments on this proposal? Given the little feedback
> I got to the message below, I'm assuming everyone is ok with this proposal.
>
> Markus suggested (and Werner supported) that we provide a way to bundle
> this information separately from the application. The only ways we
> currently
> support for supplying deployment information separately from the
> application
> bundle is the "alt dd" mechanism and the non-standard deployment plan.
>
> A related issue that we haven't addressed yet is the ability to provide
> per-tenant "customizations" for a multi-tenant SaaS app.
>
> I would recommend that we use one of these mechanisms to address this
> concern
> rather than invent a new capability just for this.
>
>
Especially the multi-tenant capability where tenants are usually added on
the fly during application runtime means, there must be a separate source.
Nobody seriously wants to touch their WAR or EAR file just to add a new
tenant[?]
Either a structure that supports multiple tenants in one file or even
adding files for new tenants should be considered. At least this must be
reloaded, ideally avoiding an app server restart which may violate SLAs,
even if you normally have clusters which could reduce the burden of restart
and availability.
Any thoughts beside Markus on this?
> Markus also suggested (and Werner also supported) that we add password
> strength requirements for the keystore password. I'm hesitant to do that
> since such things are usually subject to local security policy and it
> seems unlikely that we could come up with requirements that would satisfy
> everyone.
>
>
If that is too complicated, or diverse across projects maybe we could leave
it for now.
> Any other final comments before I consider this proposal accepted?
>
>
> Bill Shannon wrote on 04/04/12 17:20:
> > Have people had a chance to reconsider this proposal in the light of
> > the discussion that followed? The initial reaction seemed to be
> > "it's evil, don't do it". I'm hoping that the discussion clarified
> > our goals with this proposal and you understand better the use cases
> > it does and doesn't address.
> >
> > We'd love to hear the current thinking of the expert group on this topic.
> >
> > Thanks.
> >
> >
> > Bill Shannon wrote on 03/09/12 11:02:
> >> Jason T. Greene wrote on 03/08/12 22:42:
> >>> On 3/8/12 6:09 PM, Bill Shannon wrote:
> >>>> I've uploaded another proposal from our security team. Please review
> >>>> and give us your feedback.
> >>>>
> >>>>
> http://java.net/projects/javaee-spec/downloads/download/credential-ssl-config-ee7-proposal.pdf
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> Frankly the whole idea of sticking private keys and password databases
> in
> >>> deployments seems like a major hazard. Developers are used to copying
> these
> >>> around everywhere. I could easily see someone forgetting they have
> sensitive
> >>> information in here. People also tend to use short and bad passwords in
> >>> keystores which makes bruteforcing a PKCS12 file not that difficult.
> >>
> >> Note that we *already* allow you to include clear text passwords in
> your code.
> >> That's nothing new. As always, you have to apply judgment when using
> these
> >> mechanisms.
> >>
> >> The point of this proposal is to allow you to include passwords in a
> more
> >> secure manner. The passwords would be encrypted, not clear, and the
> >> encryption password would be supplied separately. If you think we should
> >> have password strength requirements for the keystore password, we could
> >> talk about that.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> This new proposal tries to bridge the gap between developers and
> enterprise
> >> deployers by providing the convenience of bundling passwords with
> applications
> >> but doing so in a way that provides some security for those passwords.
> >> Rather than telling developers "don't include passwords in your
> application,
> >> you figure out what to do instead", we can tell them "here's a secure
> and
> >> convenient way to include passwords in your application".
> >
>
>
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * Dutch Mobile Conference: June 8 2012, Amsterdam, Netherlands. Werner Keil, JCP EC Member, OpenDDR Evangelist will present "OpenDDR" * Eclipse DemoCamp Vienna: June 22 2012, Vienna, Austria. Werner Keil, Eclipse UOMo Lead will present "Using Xtext/TS for type-safe DSLs"
(image/gif attachment: 329.gif)