8:26 a.m.
From the requirements the APIs used to access the server need to be
secured and there also needs to be the possibility of integrating with
existing infrastructure - however what do we need for the out of the box
experience?
Within prior AS releases default security configuration would generally
be provided using login modules that read the users, their password and
their roles from properties files. These files would be static and for
updates they would need to be edited by hand.
For AS7 would we also use a statically defined approach like this or for
the out of the box security configuration would we be looking for an
approach where the users and their roles can also be configured through
the management APIs?
Regards,
Darran Lofthouse.
9:15 a.m.
----- Original Message -----
From: "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Monday, February 7, 2011 7:26:39 AM
Subject: [jboss-as7-dev] Out of the Box - Management API Security
From the requirements the APIs used to access the server need to be
secured and there also needs to be the possibility of integrating with
existing infrastructure - however what do we need for the out of the
box
experience?
Within prior AS releases default security configuration would
generally
be provided using login modules that read the users, their password
and
their roles from properties files. These files would be static and for
updates they would need to be edited by hand.
For AS7 would we also use a statically defined approach like this or
for
the out of the box security configuration would we be looking for an
approach where the users and their roles can also be configured
through
the management APIs?
I would personally love to see the properties files disappear. It has always felt crude.
Andy
Regards,
Darran Lofthouse.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:20 a.m.
On a separate thread it appears there will be no domain support for the
properties files anyway and applications using them will need to bundle
them in their own deployment: -
http://community.jboss.org/thread/162307?tstart=0
So this now leads to the question for the out of the box case how would
we want users and their roles to be stored / distributed across the
domain? And if this is a custom store of some sort should the users and
their roles be manageable through the management APIs.
Regards,
Darran Lofthouse.
On 02/07/2011 03:15 PM, Andrig Miller wrote:
----- Original Message -----
> From: "Darran Lofthouse"<darran.lofthouse(a)jboss.com>
> To: jboss-as7-dev(a)lists.jboss.org
> Sent: Monday, February 7, 2011 7:26:39 AM
> Subject: [jboss-as7-dev] Out of the Box - Management API Security
> From the requirements the APIs used to access the server need to be
> secured and there also needs to be the possibility of integrating with
> existing infrastructure - however what do we need for the out of the
> box
> experience?
>
> Within prior AS releases default security configuration would
> generally
> be provided using login modules that read the users, their password
> and
> their roles from properties files. These files would be static and for
> updates they would need to be edited by hand.
>
> For AS7 would we also use a statically defined approach like this or
> for
> the out of the box security configuration would we be looking for an
> approach where the users and their roles can also be configured
> through
> the management APIs?
I would personally love to see the properties files disappear. It has always felt
crude.
Andy
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12:09 p.m.
Here is a response from Jason on a PicketBox thread discussing modules
normally used for out of the box security: -
We need to be very careful about how user management is done, if it
should be done at all for 7.0. Anything that stores state has to somehow be replicated
across all the hosts in the domain. This opens the door to all kinds of problems:
* Do you allow distribution of keystores which may have private keys? (very
dangerous)
* Do you store passwords in the domain.xml, and do you obfuscate them giving a false
sense of security?
* If it's not in domain.xml how is the state going to be replicated in a way
thats consistent with domain.xml?
Also note that anyone serious about security, is probably going to prefer a centralized
security server over a user password distribution model. In this case all of the work we
do here would go to waste.
In the meeting in Madison, we talked about how the likely easiest thing to do was to just
have the domain.xml REFER to whatever the security store is, and then let the user decide
how it gets on the box if it needs to be. They already have to install AS for every
location, so that might as well drop a properties file if thats what they are using.
http://community.jboss.org/thread/162307?tstart=0
On 02/07/2011 02:26 PM, Darran Lofthouse wrote:
From the requirements the APIs used to access the server need to
be
secured and there also needs to be the possibility of integrating with
existing infrastructure - however what do we need for the out of the box
experience?
Within prior AS releases default security configuration would generally
be provided using login modules that read the users, their password and
their roles from properties files. These files would be static and for
updates they would need to be edited by hand.
For AS7 would we also use a statically defined approach like this or for
the out of the box security configuration would we be looking for an
approach where the users and their roles can also be configured through
the management APIs?
Regards,
Darran Lofthouse.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5352
days inactive
5353
days old
3 comments
2 participants
participants (2)
-
Andrig Miller -
Darran Lofthouse