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