2:22 a.m.
I would suggest we do provide an out-the-box config that secures the HTTP endpoint:
<management>
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<users>
<user username="admin">
<password>password</password>
</user>
</users>
</authentication>
</security-realm>
</security-realms>
</management>
Any objections or good reasons not to do it?
Ike
2:39 a.m.
On Thu, 2011-05-26 at 09:22 +0200, Heiko Braun wrote:
I would suggest we do provide an out-the-box config that secures the
HTTP endpoint:
<management>
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<users>
<user username="admin">
<password>password</password>
</user>
</users>
</authentication>
</security-realm>
</security-realms>
</management>
Any objections or good reasons not to do it?
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.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
2:57 a.m.
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.
9:51 a.m.
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
10:04 a.m.
What we need are generic mechanisms to define identity information
(username/pass, x509 etc) in the security subsystem that can be
referenced by the other subsystems such as management. There is a dire
need to apply advanced encryption etc on the identity (if desired) in
the platforms. Let me discuss this with Marcus and get back.
Gone are the days where you could see a password in clear text.
I agree with Remy that we need to lock down the endpoint by default.
On 05/26/2011 09:51 AM, 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.
10:04 a.m.
On Thu, 2011-05-26 at 10:51 -0400, 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.
Ok, that makes sense too. But there shouldn't be any default user at
all, esp with access to the admin features.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
11:10 a.m.
On 5/26/11 10:04 AM, Remy Maucherat wrote:
On Thu, 2011-05-26 at 10:51 -0400, 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.
Ok, that makes sense too. But there shouldn't be any default user at
all, esp with access to the admin features.
Before we do this we need to have a good strategy for quickly and easily
setting things up for dev use, demo use etc.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
3:50 a.m.
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
6:59 a.m.
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
11:08 a.m.
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
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:12 a.m.
https://issues.jboss.org/browse/AS7-943
On 06/02/2011 05:08 PM, Brian Stansberry wrote:
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
1:52 a.m.
+1
On Jun 2, 2011, at 6:08 PM, Brian Stansberry wrote:
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
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4722
days inactive
4733
days old
11 comments
6 participants
participants (6)
-
Andrig Miller -
Anil Saldhana -
Brian Stansberry -
Darran Lofthouse -
Heiko Braun -
Remy Maucherat