JBoss7配置指南(三)
4.管理任务
4.1 网络接口和端口
4.1.1 网络接口声明
JBoss AS 7 在整个配置文件中都引用命名的接口。一个网络接口通过指定一个逻辑名和选择一个物理接口来声明。
[standalone@localhost:9999 /] :read-children-names(child-type=interface)
{
"outcome" => "success",
"result" => [
"management",
"public"
]
}
以上操作意味着server声明了两个接口:一个可以使用”management”进行引用,另外一个可以用”public”引用。管理层(比如HTTP 管理点)需要用到的所有组件和服务都可以使用”management”接口。与网络通讯有关的应用(如Web, Message等等)都可以使用”public”接口.接口的名字没有任何特别的要求;可以用任何名字声明接口。配置的其他部分可以用逻辑名来引用这些接 口,而不用包含接口的所有详细信息(在管理域里服务器上的这些信息随着机器不同而不同).
domain.xml, host.xml 和standalone.xml 都包含声明接口的部分。但我们看这些在xml文件中接口声明时,就会发现接口的选择条件(selection criteria)。接口选择的条件有两种类型:一种是单独的xml元素,接口绑定到通配符地址;另外一种是接口或者地址有一个或者多个特征值需要满足。 下面是一个接口条件选择的例子,每个接口都有特定的IP地址:
<interfaces>
<interface name="management">
<inet-address value="127.0.0.1"/>
</interface>
<interface name="public">
<inet-address value="127.0.0.1"/>
</interface>
</interfaces>
另外一些使用通配符的例子:
<interface name="global">
<!-- 使用任何地址 -->
<any-address/>
</interface>
<interface name="ipv4-global">
<!--使用任何IPV4的例子-->
<any-ipv4-address/>
</interface>
<interface name="ipv6-global">
<!-- 使用任何IPV6的例子 -->
<any-ipv6-address/>
</interface>
<interface name="external">
<nic name="eth0"/>
</interface>
<interface name="default">
<!-- 匹配下面子网地址,而且支持multicats不是点对点的地址-->
<subnet-match value="192.168.0.0/16"/>
<up/>
<multicast/>
<not>
<point-to-point/>
</not>
</interface>
4.1.2 Socket Binding Groups
AS7中socket的配置类似于interface的声明,Sockets用一个逻辑名来声明,可以在整个配置中引用。 多个Sockets声明可以用一个特定的名字声明成为一个组。这样在配置一个在管理域里的server group时可以方便的引用一个特定的socket binding group. Socket binding group通过interface逻辑名来引用interface:
<socket-binding-group name="standard-sockets" default-interface="public">
<socket-binding name="jndi" port="1099"/>
<socket-binding name="jmx-connector-registry" port="1090"/>
<socket-binding name="jmx-connector-server" port="1091"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8443"/>
<socket-binding name="jacorb" port="3528"/>
<socket-binding name="jacorb-ssl" port="3529"/>
<socket-binding name="osgi-http" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<socket-binding name="messaging" port="5445"/>
<socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
一个socket binding 包含一下信息:
- name – socket配置的逻辑名,可以在配置的其他任何地方引用。
- port – 这个配置中socket要绑定到的基础端口 (注意server可以通过配置增减所有端口值来覆盖这一配置)
- interface (可选) – 配置中socket要绑定接口的逻辑名 (参考 上面的接口声明 ) .如果没有指定, socket binding group 配置元素中的default-interface属性值将会被使用。
- multicast-address (可选) --如果socket用于多播,将会使用这个多播地址。
- multicast-port (可选) – 如果socket用于多播,将会使用这个多播端口
- fixed-port (可选, 默认是false) – 如果是true, 端口值将一直使用这个值,这个值不会被使用增减端口值而覆盖。
4.2 管理接口的安全性
除了在运行服务器或者服务器组上的各种服务,JBoss7还提供了两个管理接口允许远程的客户端可以管理JBoss AS7.这个章节中介绍如何使用这些接口,以及如何对这些接口进行加密。
这两个管理接口被暴露成一个HTTP接口和一个Native接口。HTTP接口既用来提供基于GWT的管理控制台(admin console)使用,也提供给使用JSON编码协议和de-typed RPC API各种管理操作使用。当运行在单独运行服务器(standalone)时候,Native接口允许管理操作通过私有的二进制协议访问。这种使用二进制 协议类型的操作可以通过AS7提供的命令行工具,也可以通过使用AS7jar文件的远程客户端进行交互。
在管理域下使用这些接口稍有些负责。在每一个主机上都有一个host controller的进程。在主机上的host controller会配置成为domain controller.在管理域中可以用同样的方式来使用HTTP接口; HTTP接口允许基于GWT的管理控制台(admin console)运行在主domain controller,也允许任何基于HTTP和JSON的管理控制客户端在任何host controller上执行管理操作。然而其他的一些客户端则使用Natvie接口:一旦host controller启动真正的应用服务器实例,这些应用服务器则通过native接口与host controoler后台建立连接;从host controller则使用native 接口与主domain controller在后台建立连接来获取domain 模型的拷贝,并随后接收主domain cotroller的操作请求。
4.2. 1初始化设置
单独运行服务器的接口配置在standalone.xml里定义,在管理域里运行服务器的接口配置在host.xml 中。在两个文件种,接口配置都有相同的结构:
<management>
...
<management-interfaces>
<native-interface interface="management" port="9999" />
<http-interface interface="management" port="9990"/>
</management-interfaces>
</management>
...
<interfaces>
<interface name="management">
<inet-address value="127.0.0.1"/>
</interface>
<interface name="public">
<inet-address value="127.0.0.1"/>
</interface>
</interfaces>
navtive接口默认监听9999端口,http接口监听9990.管理接口同时与一个命名为 “management”的网络接口(network inteface)相关联。虽然management网络接口(network interface)的配置和public 网络接口的默认配置相同,但我们推荐不要合并这两个配置。managment和public的网络接口分开配置可以保证任何将应用服务器中服务更为公开的 配置更改,不会无意识的公开本不需要公开的管理接口。
4.2.2 快速配置
在本章节剩下的部分我们讲更为详细的讲述安全域的配置-但是如果你想快速的启用安全域并且完善安全配置来满足需求,默认的配置包含一个预先定义的安全域,它基于一个property文件和一个可以通过命令行来启用的脚本。
安全域定义在standalone.xml或者host.xml文件中<management>元素. 默认的安全域:
<management>
<security-realms>
<security-realm name="PropertiesMgmtSecurityRealm">
<authentication>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" />
</authentication>
</security-realm>
</security-realms>
...
</management>
默认安全域通过调用在configuratiion目录下的mgmt-user.properties来校验连接的用户。property文件默认没有任何用户,因此新的用户要用username=password格式添加到文件中:
手动启用两个接口配置好的管理域:
<management>
...
<management-interfaces>
<native-interface interface="management" port="9999" security-realm="PropertiesMgmtSecurityRealm" />
<http-interface interface="management" port="9990" security-realm="PropertiesMgmtSecurityRealm"/>
</management-interfaces>
</management>
这将为Http interface启用Http Digest authentication,并且在Native interface启用Digest SASL-这也意味着对于原始密码不会在客户端和服务器端进行传输验证。
使用脚本来启用安全域,首先要编辑“mgmt-users.properties”,因为配置会马上生效。你需要至少定义一个用户,并且执行以下命令:
对于单独运行的服务器:
./jboss-admin.sh --connect --file=scripts/secure-standalone-mgmt.cli
对于在管理域的服务器:
./jboss-admin.sh --connect --file=scripts/secure-host-controller-mgmt.cli
注意这个脚本只能运行在默认配置为master的host上。如果创建了其他具有不同名称的host,那么需要更新这个脚本或者手动对这个新的配置实施安 全性。并且还要注意,这个脚本仅仅改变它要运行的名为master的host,如果有多个host controller,这个脚本需要使用他们所有正确的host名字运行去更改。同时,请阅读这个章节的其他部分关于如何配置从host controller连接主host controller的校验。
禁用JMX远程访问
除了以上的JBoss管理协议,还有允许JDK和应用管理操作的远程JMX 连接。为了安全性,可以通过删除远程连接配置来禁止这一服务,或者删除整个subsystem.
<subsystem xmlns="urn:jboss:domain:jmx:1.0">
<!-- Delete the following line to disable remote access -->
<jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
</subsystem>
4.2.3 详细配置
管理接口的配置在<management>下的三个节点中:
<management>
<security-realms />
<outbound-connections />
<management-interfaces />
</management>
<security-realms /> - 配置一个或者多个安全域来定义远程用户如何连接到服务器进行验证,并且定义服务器上的身份(identity)。
<outbound-connections /> -有时候安全域的配置需要连接到一个外部的资源;这些连接在这里配置。
<management-interfaces /> - 这里定义Http interface和Native interface,正如我们在简介里描述的那样。
4.2.3.1 管理接口
对于单个管理接口的配置是最简单的。仅仅需要配置管理接口的”security-realm”属性,来指定使用安全域的名字。因为管理接口启动安全 域时,要查询安全域所提供的功能,并且启动安全相依的传输:比如用户的密码如果可以从安全域中获得,Http interface会尝试使用Digest验证,如果用户密码不能从安全域中获取,http interface会转而支持Basic验证。
<management> ...
<management-interfaces>
<native-interface ... security-realm="PropertiesMgmtSecurityRealm" />
<http-interface ... security-realm="PropertiesMgmtSecurityRealm"/>
</management-interfaces>
</management>
管理接口可以使用同样的安全域,但这不是必须的。如果需要,不同的管理接口可以使用不同的安全域。
4.2.3.2 安全域
<security-realms /> 元素用来配置一个或者多个安全域。安全域的配置具有以下结构:
<management>
<security-realms>
<security-realm name="SampleRealm">
<server-identities />
<authentication />
</security-realm>
</security-realms>
...
</management>
<server-identities />元素定义server的身份信息。目前可以配置一个SSL身份(identity)来定义服务器如何从一个keystore 取得身份信息。也可以配置一个加密的身份-服务器使用什么样的命令或密码和其他的服务器进行通信。
<authentication /> 定义如何验证连接到服务器的用户.
4.2.3.2.1 Authentication(验证)
最初,AS7支持三种机制来验证连接到服务器的用户:
LDAP – 使用LDAP 服务器来验证用户的额身份信息。
Users – 定义在domain model里的用户名和密码信息,这仅作为简单测试使用。
Properties – 用户名和密码定义在一个服务器安装文件目录的 property文件中。
下表概括了管理接口支持的验证机制,用来对终端用户在传输级别上进行验证:
Authentication | HTTP Interface | Native Interface |
LDAP | HTTP BASIC | Not Supported1 |
Users | HTTP DIGEST | SASL DIGEST |
Properties | HTTP DIGEST | SASL DIGEST |
1 – 将被增加到AS7-1167
HTTP Basic和SASL Plain(实现以后)在一个表单里传输用户密码,很容易被破解。
下面的章节阐述如何配置这些验证机制:
4.2.3.2.1 . 1 LDAP
LDAP验证操作首先要建立一个和远程目录服务器的连接。然后使用用户提通的用户名去执行查找区别用户的识別名(distinguished name)。最后验证器和目录服务器建立一个新的连接,使用查找到的识別名和用户提供的密码来验证是否是合法用户。
这是一个使用LDAP验证的安全域配置:
<security-realm name="TestRealm">
<authentication>
<ldap connection="ldap_connection" base-dn="CN=Users,DC=mydomain,DC=aslab" username-attribute="sAMAccountName" />
</authentication>
</security-realm>
ldap元素可以配置以下属性:
connection - 定义在 <outbound-connections>的连接来连接到LDAP目录服务器。
base-dn - 开始搜索用户的上下文中的识别名(基准识别名).
Username-attribute – 目录中的用户名的属性,用来匹配提供的用户名
recursive (default - false) - 是否需要迭代查找
user-dn (default - dn) - 用户中存放识别名的属性, 用来校验用户信息
4.2.3.2.1 . 2 User
User校验器是一个对存储在domain model里用户名和密码进行验证的简单校验器。校验器仅用作简单的测试使用:
这是一个使用User验证器的例子:
<security-realm name="TestRealm">
<authentication>
<users>
<user username="TestUser">
<password>TestUserPassword</password>
</user>
</users>
</authentication>
</security-realm>
在这个配置中,每个用户都用<user>进行定义,用户名使用”username” 属性定义,password定义在user下的<password>中。
4.2.3.2.1 . 3 Properties
Properties校验器和User校验器类似,除了用户名和密码定义在一个properties文件中。比起 User校验的优点是password不必在domain model中暴露。
这是一个使用properties验证器配置安全域的一个例子:
<security-realm name="TestRealm">
<authentication>
<properties path="users.properties" relative-to="jboss.server.config.dir" />
</authentication>
</security-realm>
Properties文件通过简单定义”path”属性来指定文件的路径和 ”relative-to”属性来引用定义好的路径和path属性相对的路径。在这个例子中,user.properties在存放 stadnalone.xml文件相同的目录下。 如果”relateive-to”属性没有指定,那么path属性的之必须是一个绝对路径。
4.2.3.2.2 Server Identities(服务器身份)
<server-identities>用于配置在多种场景中服务器辨别自己身份的信息。 目前在HTTP interface中可以定义一个SSL indentiy并且使用这一indentity来启用SSL,另外一个Secret identity可以存放一个密码,当host controller和远程的domain controller 建立连接时,使用这一个定义好的Secret indentity.
- SLL
SSL identity的配置目前需要从本地文件系统中加载一个静态的keystore.以后会增强这一个功能来允许多种类型的keystore:
一个SSL indentity的配置示例如下:
<security-realm name="TestRealm">
<server-identities>
<ssl>
<keystore path="server.keystore" relative-to="jboss.server.config.dir" password="keystore_password" />
</ssl>
</server-identities>
</security-realm>
keystore的路径信息和properites验证器中properties文件信息相同,使用一个路径指定keystore和一个可选的relative-to 属性来指定path属性相对于一个已知的路径。
- Secret
从domain controller连接到一个加密的主domain controller时,需要配置Secret identity.
为了实现连接加密的主domain controoler,下面是在从domain controller中增加的配置:
<host xmlns="urn:jboss:domain:1.0"
name="slave">
<management>
<security-realms>
<security-realm name="TestRealm">
<server-identities>
<secret value="c2xhdmVfcGFzc3dvcmQ=" />
</server-identities>
</security-realm>
</security-realms>
...
</management>
<domain-controller>
<remote host="127.0.0.1" port="9999" security-realm="TestRealm" />
</domain-controller>
...
</host>
这里<remote>定义了domain controller引用了一个定义好的安全域。,这个引用意味着这个安全域会被用来加载客户端的配置(以后这将会扩展使得域也同样可以为客户端的连接定义SSL)
secret是密码采用Base64编码,连接会使用host名(在这个示例中是'slave')和从secret中得到的密码进行验证。
AS7-1102列出了密码的处理将会被增强,来更好的保护密码的配置。如采用密码混淆,加密方式以及使用外部的security provider, smart card或者使用 PKCS#11的硬件加密模块。
4.2.3.3 Outbound connections(外部连接)
如前面所述,外部连接用来连接一个远程的服务器,目前仅支持LDAP连接,以后会增加数据库连接来支持对存储在数据库中的信息进行验证。
- LDAP
下面是一个连接LDAP服务器的例子:
<outbound-connections>
<ldap name="ldap_connection" url="ldap://127.0.0.1" search-dn="CN=AS7 Test Server,CN=Users,DC=mydomain,DC=aslab" search-credential="AS_Password" />
</outboundconnections>
<ladp>可以配置以下属性:
name - 连接名,ladp验证其会使用这个名字来引用这个连接。
url – 连接目录服务器的URL.
search-dn - 用户初始化搜索的识别名
search-credential – 连接进行搜索的密码
initial-context-factory (default - com.sun.jndi.ldap.LdapCtxFactory) -用来建立连接的 initial context factory
4.2.4 问题:
Application server如何连接到host controller的native interface上-是如何进行验证的?
当JBossAS7进程启动时会创建一个随机的key并且将这个key传输到启动的服务器实例,applicaiotn server使用这个key来验证native interface的连接。
转载于:https://blog.51cto.com/cntway/755252