From the Password Aliasing proposal:
> Password aliasing or indirection is a mechanism for storing and
> referencing a moniker or token instead
> of an actual clear text password.
The original purpose was only to address the clear text password problem.
The associated credential archive was meant to change based on the
deployment environment (e.g. dev, test, prod) and be consumed by the
platform as a credential store. The original proposal was not intended
to store arbitrary configuration like server names.
> 1. General aliasing which would enable secure storage of the alias
> values, that covers today and the existing passwords in config.
I guess it is a small leap to extend this to store any secure
configuration data. Darran, would you please add a JIRA covering this?
Just something to start a future conversation.
> 2. A more complete "identity aliasing" which covers obtaining an
> identity in general for outbound connections.
> 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
Is this what is meant? In @DataSourceDefinition, if someone specifies
Kerberos, the properties expand into the appropriate properties
configured for Kerberos?
@DataSourceDefinition(properties="${ALIAS=kerberos}")
Or, do we mean we want something like a client-side (outbound)
authentication method that is set in an API, which corresponds to a
ClientAuthenticationModule that understands the authentication method,
and knows how to get/use the credentials. This would not be a string
replacement alias, but rather something like a simple API for any
client-side authentication?
Thanks,
Alex
On 3/31/15 11:59 AM, Darran Lofthouse wrote:
>
>
> On 31/03/15 16:52, arjan tijms wrote:
>> Hi,
>>
>> On Tue, Mar 31, 2015 at 5:25 PM, Darran Lofthouse
>> <darran.lofthouse_at_redhat.com> wrote:
>>> @DataSourceDefinition(
>>> name="java:app/jdbc/test",
>>> className="com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
>>> user="root",
>>> password="${ALIAS=password}",
>>> databaseName="test",
>>> serverName="localhost",
>>> portNumber=3306 )
>>
>> When I see password="${ALIAS=password}", I think it strongly resembles
>> one of the proposals in the Configuration JSR; EL based placeholders
>> in XML and annotations. I haven't really looked at the password
>> aliasing proposal in detail lately, but what's stopping this from
>> being used for all other attributes as well?
>
> Maybe this is a problem to be split into two pieces: -
>
> 1. General aliasing which would enable secure storage of the alias
> values, that covers today and the existing passwords in config.
>
> 2. A more complete "identity aliasing" which covers obtaining an
> identity in general for outbound connections.
>
>> E.g.
>>
>> serverName="${ALIAS=serverName}
>>
>> ?
>>
>> Kind regards,
>> Arjan Tijms
>