After lots of back and forth, the plan is to:
1) Ship unsecured
2) Ship a secure-mgmt.cli script that can be executed from the CLI
./jboss-admin.sh --file secure-mgmt.cli
3) Include in the domain/configuration and standalone/configuration dirs
a properties file with a commented out user
#admin=CHANGEIT
Darran is going to take care of implementing and documenting this.
On 5/31/11 6:59 AM, Heiko Braun wrote:
Still, none of these concerns have anserwered my initial question.
Will it be secured by default? Who takes care of it? Where will it be documented?
On May 31, 2011, at 10:50, Darran Lofthouse<darran.lofthouse(a)jboss.com> wrote:
> Yes the sample posted was for a quick out of the box config, in addition to that for
the separation of configuration we do also have a properties file based approach.
>
> Both will support an obfuscated form of the password and once I have had a chance to
review the SASL mechanisms used in the Remoting integration I will be looking to store
these as pre-prepared hashes which if compromised would only be useable for a specific
user against a specific security realm. If a single user used the same password against
multiple realms then the hash would not be usable against the other realms.
>
> Regards,
> Darran Lofthouse.
>
>
>
> On 05/26/2011 03:51 PM, Andrig Miller wrote:
>> I know that from the security side of things, we are trying to make sure that
usernames and passwords don't end up in configuration files.
>>
>> I think we should rope in Anil and company into this discussion.
>>
>> Andy
>>
>> ----- Original Message -----
>>> From: "Heiko Braun"<hbraun(a)redhat.com>
>>> To: "Remy Maucherat"<rmaucher(a)redhat.com>
>>> Cc: jboss-as7-dev(a)lists.jboss.org
>>> Sent: Thursday, May 26, 2011 1:57:08 AM
>>> Subject: Re: [jboss-as7-dev] Secure HTTP API Endpoint
>>>
>>>
>>> In general I would agree with your approach.
>>>
>>> But AFAIK the HTTP API endpoint doesn't support authorization
>>> schemes.
>>> So no roles in this case.
>>>
>>> On May 26, 2011, at 9:39 AM, Remy Maucherat wrote:
>>>
>>>> The right solution is to require some special role for any admin or
>>>> management operations, but not provide any default user having it.
>>>> So,
>>>> locked down by default.
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev