[jboss-as7-dev] How hard would it be to support key based auth by default to make life simpler and more secure ?

[Jason T. Greene]

We are talking about the management interfaces, so having the admin 
authenticate in as similar as possible (at least under default 
scenarios) is the most intuitive.

On 11/14/11 9:17 AM, David M. Lloyd wrote:
> This I don't buy. Where did this requirement come from?
>
> On 11/14/2011 09:13 AM, Darran Lofthouse wrote:
>> The problem is whatever we can use for the Native interface we also need
>> to be able to use for the HTTP interface, for the SASL mechanisms we are
>> using so far there is a corresponding mechanism that can be used with
>> HTTP.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> On 11/14/2011 03:10 PM, David M. Lloyd wrote:
>>> On 11/14/2011 05:40 AM, Max Rydahl Andersen wrote:
>>>>>>>
>>>>>>> These will make all examples that uses maven deploy plugin, cli
>>>>>>> scripts, arquillian, jboss tools etc. to somehow
>>>>>>> either tell users to type in their username and full password in
>>>>>>> clear text in pom.xml and other files.
>>>>>>>
>>>>>>> Which sounds worse to me than a default locked down to only
>>>>>>> localhost…but I'm not a security expert :)
>>>>>>>
>>>>>>> I was wondering how hard it would be to make the authentication
>>>>>>> support key based auth by default and we make
>>>>>>> the tools use ${user.name} and ${user.home}/.jboss/default.pub and
>>>>>>> .priv (or some other name) for the public/private keys ?
>>>>>>
>>>>>> You would need a key-based SASL authentication mechanism. There
>>>>>> are no
>>>>>> standard ones as of right now. If you know of a key-based SASL
>>>>>> mechanism that you think we should support, let me know and we'll
>>>>>> evaluate it.
>>>>>
>>>>> We would have to do noauth + SSL + trust. I think it's an option
>>>>> worth considering. The big problem though is that we have to have a
>>>>> setup process to generate the certs, which is greater complexity
>>>>> than the user/pass option. We would have to generate a host key pair
>>>>> and a client key pair.
>>>>
>>>>
>>>> I'm not an expert on these things at all but eclipse uses
>>>> http://www.jcraft.com/jsch/ to manage and create ssh keys and uses
>>>> the standard .ssh location's etc.
>>>>
>>>> Is something additional needed ?
>>>
>>> Yeah, an authentication mechanism that uses SSH keys. There is none
>>> currently.
>>>
>>> Again, we can use any combination of SASL and TLS for authentication.
>>> Neither spec (to my knowledge) has a simple key-based client
>>> authentication mechanism (TLS is cert-based; SASL could support such a
>>> mechanism but none presently exist). If such a mechanism were to be
>>> defined, we could evaluate using it. If we were to use such a
>>> mechanism, we would obviously want to have good tooling to back it up.
>>> Perhaps you might even considering contributing one (though I'd strongly
>>> recommend consulting with security experts if you do).
>>>
>>> As an aside, as far as I can tell SASL has the best shot at supporting
>>> client key authentication as it has the simplest SPI. JSSE has a
>>> similar conceptual model but is considerably more complex
>>> implementation-wise and I'd be very cautious about defining new
>>> algorithms for it. Yeah this excludes HTTP (unless something like this
>>> [1] gets resurrected). However I'm quite skeptical that HTTP would be
>>> expected to use the same mechanism.
>>>
>>> Also, even if we did support such an algorithm, the initial server-side
>>> key generation doesn't necessarily have to impact boot time; in fact it
>>> should only come into play either (a) when a user explicitly requests
>>> the server key, or (b) when a user attempts to authenticate using
>>> key-based authentication.
>>>
>>> [1] https://datatracker.ietf.org/doc/draft-nystrom-http-sasl/
>>>
>
>


-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat