On 01/04/15 22:55, Alex Kosowski wrote:
> 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.
Will do.
>> 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?
I am thinking the latter i.e. the simple API. At the same time this
would also need a close relationship with SSL.
> 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
>>
--
Darran Lofthouse - Principal Software Engineer
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson
(US), Michael O'Neill(Ireland)