jsr375-experts@javaee-security-spec.java.net

[jsr375-experts] Re: [JAVAEE_SECURITY_SPEC-6] Password Aliasing - is it necessary?

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 31 Mar 2015 17:32:43 +0200

Darran/all,

You suggest not to use a username/password combination in the first place
it seems.

Which of course makes sense, either via some SSO security token (OAuth,...)
or SSH certificate one can avoid passwords.

What I'd add to the discussion is, a simple password string may not be the
only sensitive information. Other details you may rather alias than store
in plain text could be a credit card number or similar, so IMHO the term
"password aliasing" is probably a little too narrow.

Regards,
Werner

On Tue, Mar 31, 2015 at 5:25 PM, Darran Lofthouse <
darran.lofthouse_at_redhat.com> wrote:

> IMO this is potentially a large topic and should actually be bigger than
> just aliasing of passwords, as I have said elsewhere we need to stop
> thinking purely in-terms of a username and passwords.
>
> Take the example in the linked PDF: -
>
> @DataSourceDefinition(
> name="java:app/jdbc/test",
> className="com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
> user="root",
> password="${ALIAS=password}",
> databaseName="test",
> serverName="localhost",
> portNumber=3306 )
>
> This covers the situation quite nicely where the database is configured to
> support username and password based authentication but is quickly
> inadequate when another mechanism is needed e.g. Kerberos.
>
> Overall what I actually believe is needed is that when the application
> server is acting as a client to some remote process a standard mechanism
> needs to be supplied to specify how that identity is obtained. This
> identity could be a username / password pairing or it could be something
> entirely different such as a Kerberos ticket, maybe better integration with
> various SSO specs, considerations for propagating the users identity...
>
> Obviously none of this negates the need for secure storage and management
> of that storage where sensitive passwords are held but as I say I think
> identity aliasing is something that should happen first.
>
> Regards,
> Darran Lofthouse.
>
>
>
>
> On 23/03/15 20:48, Alex Kosowski wrote:
>
>> Any opinion on Password Aliasing in the Security API JSR?
>>
>> On 3/20/15 11:52 AM, Alex Kosowski wrote:
>>
>>> Hi,
>>>
>>> What are your thoughts on standardizing password aliasing in Java EE?
>>>
>>> The feature was originally proposed in EE 7:
>>> [https://java.net/projects/javaee-security-spec/
>>> downloads/download/password-aliasing-ee7-proposal.pdf]
>>>
>>>
>>> And mentioned in this JIRA:
>>> [https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-6]
>>>
>>> I think it was deferred out of EE 7 because of time constraints. When
>>> I think about what may be involved, perhaps this should be in its own
>>> JSR: alias scanning, archive format, deployment mechanism,
>>> encryption/decryption, and lots of opportunity for vulnerabilities.
>>>
>>> But what do you think? Should we standardize password aliasing to
>>> promote portability? 57.9% of EE 8 Survey respondents said yes to
>>> "Should we add support for password aliases (including the ability to
>>> provision
>>> credentials along with the application)?"
>>>
>>> Thanks,
>>> Alex
>>>
>>
>