Security domains, How to secure access an ejb, Web subsystem – HP Integrity NonStop H-Series User Manual
Page 57
authorization action. The actual authorization is done during the invocation of a container
resource such as an EJB.
•
server-identities
: This is used to enable SSL communication between remote client and
server. For more information, see
The default configuration of ManagementRealm and ApplicationRealm are configured for
both local authentication mechanism (using the local element) and digest authentication.
Security domains
The security-domains configuration is present in the security subsystem in domain.xml. A
security domain can contain authentication and authorization definitions. The classes
that implement authentication and authorization rules are all JAAS compliant. For more information,
see
The default configuration has three security-domains defined, namely other,
jboss-web-policy
, and jboss-ejb-policy. The other security domain has only
authentication modules defined, while the other two are purely used for authorization. The security
domain jboss-ejb-policy is used to authorize users accessing EJBs. An EJB can list the roles
that are allowed access to the EJB by using the annotation RolesAllowed. The security domain
by name other is also not referenced anywhere. The default configuration contains two login
modules by name Remoting and RealmDirect. The remoting login module actually does not
itself authenticate the incoming request but rather, it just checks if the request is a remoting request.
The RealmDirect login module uses a realm to authenticate a user. By default, it uses
ApplicationRealm
. In this version of NSASJ, enabling the security domain other in any
application adds no extra value. This is because a remoting request is already authenticated by
the ApplicationRealm by the remoting connector. This security domain is given as an example,
and it is suggested to configure the domain using the various login modules.
How to secure access an EJB
1.
An application can define the security domain that needs to be used to authenticate access
to its resources such as EJBs. This can be achieved by defining a security element in the
assembly descriptor of jboss-ejb3.xml deployment descriptor.
2.
The roles that are allowed access to an EJB can be defined by the EJB annotation
RolesAllowed
.
Web subsystem
Web subsystem sets up the web container for NSASJ. The schema definition for the Web subsystem
can be found in the file jboss-as-web_1_1.xsd in the docs/schema folder of the NSASJ
installation. The following is a snippet from domain.xml:
<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
<connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" secure="true"/>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>
The default configuration of the Web subsystem in NSASJ contains sample configuration for HTTP
and HTTPS connectors supported by NSASJ. The connector configuration provides the scheme,
supported protocol, and defines the socket binding port. By default, both these connectors are
enabled. This default configuration also defines a configuration for a virtual host which needs to
be modified before starting the NSASJ Server. This configuration enables the bundled
welcome-content
. The default-web-module must be modified so that a specific Webapp
can be used as a default application.
Web subsystem
57