Hi Darran,
> Where authentication is going to be using username / password based
> authentication having some form of alias to reference the password in
> a secure store works well, but we also have a couple of additional cases.
Although I recognize that username/password is just one of many ways to
establish an outbound connection, it is arguably the most prevalent and
the most problematic. I do not think there is currently a standardized
way to specify passwords in EE configuration other than plain text. The
Password Aliasing proposal provides a secure approach for supplying
passwords in a portable way. I think for the 1.0 version of the spec, we
should try to tackle the "low hanging fruit", and standardizing password
aliasing would be an effective feature to include.
> The first being SSL where the clients certificate is being used.
I suppose you mean specifying keystore path, keystore passphrase,
keystore type, alias, and private key passphrase for an outbound
connection? This could take advantage of the password aliasing for the
passphrases.
> The real point being there are different ways the identity of the
> client side can be established but the username with protected
> password is just one of them.
Do you have an example of an existing framework which does what you
propose? Please add a JIRA New Feature to capture the idea.
This seems like a difficult (and time consuming) problem. We would have
to standardize a client-side authentication framework for various client
protocol APIs, like HTTP, LDAP, database, JMS, RMI. Since there are a
multitude of client APIs, I am not sure how we would hook into various
authentication mechanisms.
This problem is more feasible on the server side, since we have JASPIC
as a standardized hook in the authentication mechanism.
This sounds like a post version 1.0 feature.
With regards,
Alex
On 4/20/15 8:41 AM, Darran Lofthouse wrote:
>
>
> On 10/04/15 07:50, Jean-Louis Monteiro wrote:
>>
>>
>> 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.
>>
>>
>> Do you have real use cases for that.
>
> This is something I have experienced in a couple of places within
> JBoss AS7 and WildFly where we have outbound connection, sometimes
> this is where we have server to server connection, another case that
> pops up is where we connect to LDAP servers.
>
> Where authentication is going to be using username / password based
> authentication having some form of alias to reference the password in
> a secure store works well, but we also have a couple of additional cases.
>
> The first being SSL where the clients certificate is being used.
>
> The next case is Kerberos authentication where in it's present form a
> suitably populated Subject needs to be provided.
>
> The real point being there are different ways the identity of the
> client side can be established but the username with protected
> password is just one of them.
>
>> In my head and from my experience, replacing clear passwords with
>> tokens/alias would have been very useful in many projects, but to be
>> honest I'm still trying to figure out about the API usage.
>