Skip to main content

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

  • From: Bill Shannon <bill.shannon@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: password aliasing proposal
  • Date: Tue, 31 Jan 2012 11:56:52 -0800
  • List-id: <>

If you want to use variables just as a way to fill in the values later,
we already have that with the ability to specify information in the
deployment descriptor instead of the annotations, and the ability to
provide an alternate deployment descriptor to replace the one bundled
in the module.

An advantage of variable replacement is when you want the same value to
be used in multiple places.  It's a level of indirection that's being
used for a different purpose with passwords - allowing them to be stored
in a more secure location/format.

Adding anything like a full programming language here seems like overkill,
and even EL introduces all sorts of issues since it can reference beans
and methods in the application, which is tricky when you're using the result
of the expression to initialize the application.

There's been a lot of discussion about ways to improve the configuration
support in Java EE, and having a way to specify some configuration values
independently of the application seems like it would be useful.  If we
had such a capability it would be good to be able to reference such values
in existing configuration elements such as annotations and deployment

Note however that there's a compatibility issue here.  If we interpret some
new syntax in places that were previously uninterpreted, we can break
applications.  This is a risk with passwords as well, but we're assuming
that the likelihood that someone actually has a password of the form
${ALIAS=name} is vanishingly small.  With the more general proposal for
variable expansion, this is more of a real issue, and we would likely
need applications to explicitly opt in to such a feature.  I'd also be
concerned about the conflict of such a feature with existing uses of EL.

David Blevins wrote on 01/31/12 11:19:
I can't quite tell if we're off topic, we definitely are somewhat, but I like 
the discussion.

There are sort of two camps of thought on this kind of thing.  The one camp where you 
fill in "this can be replaced".

         portNumber=3306 )

  - myUserId = joe
  - password = cool
  - dbName = peanuts

We'll call it the "variables" approach.  In this approach you end up scooping 
out all the metadata till there is just a shell left.  In the extreme case the 
@DataSourceDefinition doesn't define anything anymore and ultimately serves little 
purpose aside from providing structure.

The other camp is "anything with simple properties can be replaced"

         portNumber=3306 )

  - moviesDataSource.user = joe
  - moviesDataSource.password = cool
  - moviesDataSource.databaseName = peanuts

We'll call it the "override" approach.

The advantages of the override approach:
   - there are defaults
   - all replacement is optional
   - all replacement is possible

Both approaches hinge on you having a unique name.  You either guarantee "moviesDataSource" is 
unique or you need to guarantee "myUserId" is a unique variable.  Really the same thing.  Slight 
difference is the number of "unique keys" you have to manage.  One vs six using 
@DataSourceDefinition as an example.

Geronimo uses the variables approach, OpenEJB/TomEE use the override approach.

What I've seen happen is the day you have two datasources, you fall into this 
with the variables approach:

  - moviesDataSourceUserId = joe
  - moviesDataSourcePassword = cool
  - moviesDataSourceDbName = movies
  - booksDataSourceUserId = arthur
  - booksDataSourcePassword = dent
  - booksDataSourceDbName = books

Only you didn't start with the long "moviesDataSourceUserId" kind of unique key, so you first 
have to go and rename all your old "myUserId" variables to the long version before you can deal 
with the new "booksDataSource".

In the override approach where name is the unique key, you get that from day 
one.  The downside is it isn't really easy to deal with complex annotations.

Attempting to be more on topic, I wonder if we need a syntax.

Instead of having to explicitly add a "this is not a password" entry in a 
deployment descriptor or xml file, why not just leave it out?  Do we need to actually a 
value to say that the value will be handled elsewhere?

As vendors we already have the ability to change any part of the application 
metadata without the code having to reflect that.  The status quo on that 
seems pretty good.  There could be good value in focusing on sections 2 and 3 
of the proposal and leaving out the part where application developers have to 
enable that in the annotations or descriptors.

In the extreme case would really put the entire<data-source>  definition in 
this secure storage.


On Jan 31, 2012, at 5:42 AM, Antonio Goncalves wrote:

Not sure about the ALIAS= syntax. What about the good old EL ? I agree with 
Jevgeni, we've already talked about configuration issues in EE. It has to go 
further not just restricted to passwords. What about :

     portNumber=3306 )

Sorry if I didn't understand well but passwords are just one of the many possible configuration 
on an EE app. The fact that it's encrypted makes it slightly different but we could treat it in a 
different way. Something like password="${aClearPassword}" and 


On Tue, Jan 31, 2012 at 09:45, Jevgeni Kabanov<jevgeni@...>  wrote:
Is there a reason it is limited to passwords? I'm sure a generic ${}
Ant-style configuration string post-processing would be greatly
appreciated by the community.

Sent from my iPhone

On 31.01.2012, at 0:49, Bill Shannon<bill.shannon@...>  wrote:

I've uploaded a proposal from our security team for password aliasing
support in Java EE 7.  Let me know if you have any comments.

Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | Blog | LinkedIn | Paris JUG

[javaee-spec users] [jsr342-experts] password aliasing proposal

Bill Shannon 01/30/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Werner Keil 01/30/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Bill Shannon 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Jeff Genender 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Florent BENOIT 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Jevgeni Kabanov 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Werner Keil 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Antonio Goncalves 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Werner Keil 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

David Blevins 01/31/2012

[javaee-spec users] [jsr342-experts] Re: password aliasing proposal

Bill Shannon 01/31/2012

[javaee-spec users] Re: [jsr342-experts] Re: password aliasing proposal

Andrew Phillips 01/31/2012

[javaee-spec users] Re: [jsr342-experts] password aliasing proposal

Lance Andersen - Oracle 01/31/2012
Please Confirm