9:05 a.m.
Just want to double check one last time that there will be no support
for subsystems in the domain controller.
For securing the management APIs the backing infrastructure that we
would need to be able to connect to is most likely already covered by
the login modules included within PicketBox. The integration of this
with JBossAS 7 is also already working to provide a nicer schema when
defining a security domain.
http://community.jboss.org/thread/154409?tstart=0
If a schema already exists then the benefit of re-using it really means
that administrators only need to learn how to configure these modules
once rather than once for the management API and once for the actual
subsystems used by servers.
The first problem is that the existing parsing of the configuration will
be based around the detyped API and performing operations in the context
of a subsystem. Secondly operations to operate on this configuration
will also be in that context.
In the context of the domain controller configuration we could still
re-implement the parsing and operations without the dependency of a
server and the subsystem so at least the configuration appears the same
even if the integration with the server is different.
However the next issue that crops up using the PicketBox modules is the
dependence on things like JNDI and Datasources, probably not a massive
issue to solve but has there been any consideration yet regarding how to
manage datasources in the domain controller process?
Regards,
Darran Lofthouse.
12:24 a.m.
On 2/7/11 9:05 AM, Darran Lofthouse wrote:
Just want to double check one last time that there will be no
support
for subsystems in the domain controller.
What I want to avoid is arbitrary configuration profiles on the domain
controller/host controller. The configuration of the DC/HC should be
limited to the things that need to be exposed, no more and no less.
For securing the management APIs the backing infrastructure that we
would need to be able to connect to is most likely already covered by
the login modules included within PicketBox. The integration of this
with JBossAS 7 is also already working to provide a nicer schema when
defining a security domain.
http://community.jboss.org/thread/154409?tstart=0
If a schema already exists then the benefit of re-using it really means
that administrators only need to learn how to configure these modules
once rather than once for the management API and once for the actual
subsystems used by servers.
Sure, reusing schema makes sense. But within the context of an HC
<management/> config I don't see any requirement that the outer tag
needs to be
<subsystem xmlns="urn:jboss:domain:security:1.0">...</subsystem>
It can just be <security>, or, if we decide it's important that the
version of HC's security schema be configurable (I don't think that's
necessary), then perhaps
<security xmlns="urn:jboss:domain:security:1.0">...</security>
The first problem is that the existing parsing of the configuration
will
be based around the detyped API and performing operations in the context
of a subsystem. Secondly operations to operate on this configuration
will also be in that context.
In the context of the domain controller configuration we could still
re-implement the parsing and operations without the dependency of a
server and the subsystem so at least the configuration appears the same
even if the integration with the server is different.
If we're smart, we should be able to get a lot of re-use. The existing
subsystem code is purposefully oblivious as to where the subsystem
resource sits in the overall management tree.
If absolutely necessary, we can look at setting up a
mini-server/ServerController inside the HostController process, and use
it to manage a limited set of subsystems. But we need to think carefully
before going down that road.
However the next issue that crops up using the PicketBox modules is
the
dependence on things like JNDI and Datasources, probably not a massive
issue to solve but has there been any consideration yet regarding how to
manage datasources in the domain controller process?
We certainly don't want to run a JCA container in the HC just so
PicketBox can talk to a DB. A simple connection pool seems adequate.
Regards,
Darran Lofthouse.
_______________________________________________
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
5 a.m.
On 02/08/2011 06:24 AM, Brian Stansberry wrote:
On 2/7/11 9:05 AM, Darran Lofthouse wrote:
> Just want to double check one last time that there will be no support
> for subsystems in the domain controller.
>
What I want to avoid is arbitrary configuration profiles on the domain
controller/host controller. The configuration of the DC/HC should be
limited to the things that need to be exposed, no more and no less.
> For securing the management APIs the backing infrastructure that we
> would need to be able to connect to is most likely already covered by
> the login modules included within PicketBox. The integration of this
> with JBossAS 7 is also already working to provide a nicer schema when
> defining a security domain.
>
> http://community.jboss.org/thread/154409?tstart=0
>
> If a schema already exists then the benefit of re-using it really means
> that administrators only need to learn how to configure these modules
> once rather than once for the management API and once for the actual
> subsystems used by servers.
>
Sure, reusing schema makes sense. But within the context of an HC
<management/> config I don't see any requirement that the outer tag
needs to be
<subsystem xmlns="urn:jboss:domain:security:1.0">...</subsystem>
Yes, this is what I am thinking as well - if we are not going to
actually have subsystems then just use the types from the schema that
make sense in this context.
It can just be<security>, or, if we decide it's important
that the
version of HC's security schema be configurable (I don't think that's
necessary), then perhaps
<security xmlns="urn:jboss:domain:security:1.0">...</security>
I think versioning makes sense even more so if we are re-using the
types, if the security subsystem releases a later schema we will need to
indicate at the management level which versions are supported and if we
support multiple will need the same mechanism to identify which the user
is using.
> The first problem is that the existing parsing of the
configuration will
> be based around the detyped API and performing operations in the context
> of a subsystem. Secondly operations to operate on this configuration
> will also be in that context.
>
> In the context of the domain controller configuration we could still
> re-implement the parsing and operations without the dependency of a
> server and the subsystem so at least the configuration appears the same
> even if the integration with the server is different.
>
If we're smart, we should be able to get a lot of re-use. The existing
subsystem code is purposefully oblivious as to where the subsystem
resource sits in the overall management tree.
The part that I think we will need to look at further is that the
subsystem initialisation reads the XML and converts this to a set of
operations that make sense in the context of a server - we will need
that to either work in the domain controller process or possibly just
make some of the common areas available for re-use.
If absolutely necessary, we can look at setting up a
mini-server/ServerController inside the HostController process, and use
it to manage a limited set of subsystems. But we need to think carefully
before going down that road.
> However the next issue that crops up using the PicketBox modules is the
> dependence on things like JNDI and Datasources, probably not a massive
> issue to solve but has there been any consideration yet regarding how to
> manage datasources in the domain controller process?
>
We certainly don't want to run a JCA container in the HC just so
PicketBox can talk to a DB. A simple connection pool seems adequate.
So for the DatabaseLoginModule we start we have a couple of additional
items to look into - do we request that the DatabsaseLoginModule
supports the plug in / override of the Datasource lookup code or do we
provide a new implementation specifically for use in a domain controller.
This is definitely an advantage of not using fully qualified class names
as we can now consider these options which will be transparent to the
end user - for this I will start a PicketBox discussion.
> Regards,
> Darran Lofthouse.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5041
days inactive
5042
days old
2 comments
3 participants
participants (3)
-
Brian Stansberry -
Darran Lofthouse -
Darran Lofthouse