[jboss-as7-dev] Secure HTTP API Endpoint

[Brian Stansberry]

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 at 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 at redhat.com>
>>>> To: "Remy Maucherat"<rmaucher at redhat.com>
>>>> Cc: jboss-as7-dev at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat