Hi, Been thinking about the new username/password requirements. 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 ?

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.

>> >> 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.

You could just have the app-server automatically generate the keys for you the first time it ever boots (or even every boot cycle). Just have the CLI look at a pre-defined directory for the generated key-pair. THe idea here is that CLI works perfectly out-of-the-box with no config on the same machine as the CLI runs on. What is still protected is a remote machine accessing the app-server. This is fine, IMO. Usability problems still exist though as you would need to import the client-auth key into your browser. But, maybe this is a good thing as it will require the user to think about how they want to secure the app-server. On 11/14/11 6: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 ? > > /max > http://about.me/maxandersen > > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

It would need to be SSL not SSH as we need to support the mechanism for both the Native interface and the HTTP interface but I am starting to like this as an out of the box scenario. The advantage we have for the browser is we can always display a nice HTML page when they connect with full instructions, it is the other mechanisms where we have less opportunity to dynamically provide guidance. On 11/14/2011 01:42 PM, Bill Burke wrote: > You could just have the app-server automatically generate the keys for > you the first time it ever boots (or even every boot cycle). Just have > the CLI look at a pre-defined directory for the generated key-pair. THe > idea here is that CLI works perfectly out-of-the-box with no config on > the same machine as the CLI runs on. What is still protected is a > remote machine accessing the app-server. This is fine, IMO. > > Usability problems still exist though as you would need to import the > client-auth key into your browser. But, maybe this is a good thing as > it will require the user to think about how they want to secure the > app-server. > > On 11/14/11 6: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 ? >> >> /max >> http://about.me/maxandersen >> >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

It's also a problem with servers with SSD's. I ran into this myself. Andy ------------------------------------------------------------------------ *From: *"Jason T. Greene" <jason.greene(a)redhat.com&gt; *To: *"Darran Lofthouse" <darran.lofthouse(a)jboss.com&gt; *Cc: *jboss-as7-dev(a)lists.jboss.org *Sent: *Monday, November 14, 2011 7:53:38 AM *Subject: *Re: [jboss-as7-dev] How hard would it be to support key based auth by default to make life simpler and more secure ? It's something I thought about, we would have to make up a bunch of stuff in the CERT (not a big deal I guess). Although the thing I worry about is that cert generation requires gathering a major amount of entropy from /dev/random. It would seriously affect boot time, and it would potentially pause for a long period to gather more entropy. This is a problem for headless devices for example, that don't have a keyboard and mouse connected to them. On 11/14/11 7:57 AM, Darran Lofthouse wrote: > It would need to be SSL not SSH as we need to support the mechanism for > both the Native interface and the HTTP interface but I am starting to > like this as an out of the box scenario. > > The advantage we have for the browser is we can always display a nice > HTML page when they connect with full instructions, it is the other > mechanisms where we have less opportunity to dynamically provide guidance. > > On 11/14/2011 01:42 PM, Bill Burke wrote: >> You could just have the app-server automatically generate the keys for >> you the first time it ever boots (or even every boot cycle). Just have >> the CLI look at a pre-defined directory for the generated key-pair. THe >> idea here is that CLI works perfectly out-of-the-box with no config on >> the same machine as the CLI runs on. What is still protected is a >> remote machine accessing the app-server. This is fine, IMO. >> >> Usability problems still exist though as you would need to import the >> client-auth key into your browser. But, maybe this is a good thing as >> it will require the user to think about how they want to secure the >> app-server. >> >> On 11/14/11 6: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 ? >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Yeah this is why I like the username/password option the best. All of tools, including the CLI, can just notice there is no entry in the props file and just ask "Hey you didn't configure a user, would you like me to add one?" The passwords are stored in digest crypt form, and can be easily generated by any other external tools IDE etc. We also don't have a chicken-egg problem with somehow triggering the transport to relaunch, since the user auth is lazily discoverd (one the file is changed we notice). On 11/14/11 9:00 AM, Bill Burke wrote: > Geez guys, we're not trying to have CIA/NSA level security out of the > box. We're just trying to prevent the case where a really stupid user > (aka The Server Side) deploys their application on the internet without > thinking one bit about security. > > On 11/14/11 9:56 AM, Andrig Miller wrote: >> It's also a problem with servers with SSD's. I ran into this myself. >> >> Andy >> >> ------------------------------------------------------------------------ >> >> *From: *"Jason T. Greene&quot;&lt;jason.greene(a)redhat.com&gt; >> *To: *"Darran Lofthouse&quot;&lt;darran.lofthouse(a)jboss.com&gt; >> *Cc: *jboss-as7-dev(a)lists.jboss.org >> *Sent: *Monday, November 14, 2011 7:53:38 AM >> *Subject: *Re: [jboss-as7-dev] How hard would it be to support key >> based auth by default to make life simpler and more secure ? >> >> It's something I thought about, we would have to make up a bunch of >> stuff in the CERT (not a big deal I guess). Although the thing I worry >> about is that cert generation requires gathering a major amount of >> entropy from /dev/random. It would seriously affect boot time, and it >> would potentially pause for a long period to gather more entropy. This >> is a problem for headless devices for example, that don't have a >> keyboard and mouse connected to them. >> >> On 11/14/11 7:57 AM, Darran Lofthouse wrote: >> > It would need to be SSL not SSH as we need to support the >> mechanism for >> > both the Native interface and the HTTP interface but I am starting to >> > like this as an out of the box scenario. >> > >> > The advantage we have for the browser is we can always display a nice >> > HTML page when they connect with full instructions, it is the other >> > mechanisms where we have less opportunity to dynamically provide >> guidance. >> > >> > On 11/14/2011 01:42 PM, Bill Burke wrote: >> >> You could just have the app-server automatically generate the >> keys for >> >> you the first time it ever boots (or even every boot cycle). >> Just have >> >> the CLI look at a pre-defined directory for the generated >> key-pair. THe >> >> idea here is that CLI works perfectly out-of-the-box with no >> config on >> >> the same machine as the CLI runs on. What is still protected is a >> >> remote machine accessing the app-server. This is fine, IMO. >> >> >> >> Usability problems still exist though as you would need to >> import the >> >> client-auth key into your browser. But, maybe this is a good >> thing as >> >> it will require the user to think about how they want to secure the >> >> app-server. >> >> >> >> On 11/14/11 6: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 ? >> >>> >> >>> /max >> >>> http://about.me/maxandersen >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> jboss-as7-dev mailing list >> >>> jboss-as7-dev(a)lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> > _______________________________________________ >> > jboss-as7-dev mailing list >> > jboss-as7-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> Jason T. Greene >> JBoss AS Lead / EAP Platform Architect >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

>>> >>> 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 ?

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/ >

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/ >>

I guess I don't really care what we do out of the box. It doesn't really change the options on the table.

For example using a key-based mechanism for host-controller-to-domain-controller authentication would be much more convenient than certificate authentication.

On 11/14/2011 09:21 AM, Darran Lofthouse wrote: > If you don't keep the two in synch out of the box we are going to end up > with two completely different set ups one for HTTP and one for Native - > if tools like the CLI are ever going to be updated to support both > transports then the authentication configuration will be completely > different depending which approach is being used. > > Regards, > Darran Lofthouse. > > > On 11/14/2011 03:17 PM, 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/ >>>> >> >>

Hi, Been thinking about the new username/password requirements. 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 ? Then the tooling (cli, IDE plugins etc.) could create these by default and examples could use ${user.name} and ${user.home}/.jboss/default.pub as the preconfigured parameters. The examples would run out of the box and it would be limited to work from the machine that actually got the right key ( simpler and more secure) vs to the current AS7.1 master solution where examples won't run out of the box and when configured will run from anywhere - i.e. harder and less secure) WDYT ? /max http://about.me/maxandersen