Jim Knutson wrote on 02/13/12 13:06:
> Bill Shannon<bill.shannon_at_oracle.com> wrote on 01/30/2012 04:49:19 PM:
>> 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.
>>
>> http://java.net/projects/javaee-spec/downloads/download/password-
>> aliasing-ee7-proposal.pdf
>
> I like the idea of aliases, but I'd rather see this abstracted to
> credentials rather than just password. There's no guarantee that the
> specified id is correct and usable for all deployments so it would be
> better to tie the alias to both the id and password and have some dotted
> notation to refer to each part of the alias if we have to.
This wasn't intended primarily as a way to defer the specification of
credentials; we already have deployment descriptors and such for that.
Rather, it was intended as a way to provide the information that you
already knew to be correct, but to provide it securely. I suppose in
some cases the user name itself could be considered sensitive security
information. Is that what you're worried about? In that case, even
the host name might be considered sensitive.
> The syntax of substitution is of less interest to me though care should be
> taken when reusing existing substitution syntax. For example, there are
> going to be cases out there where someone is already using ant style
> substitution in a batch build environment and yet we need the id/pwd
> substitution to occur in a controlled runtime envionrment. Reusing the ant
> syntax may cause more frustration in trying to figure out how not to
> substitute for some parts of the metadata.
Good point, but I'm not sure there's a good alternative. We could
pick a syntax that no one else has used anywhere, but that's just more
likely to make this facility harder to use and less intuitive. I think
it's probably better to pick a syntax that's familiar, recognizing that
there will be cases where the user will need to understand how to
escape or quote the syntax.
Note that this is a much larger problem with the more general variable
substitution facility some have advocated.
Do you have a specific proposal for how we should address this issue
in this case?