Refer to these general considerations to achieve the most
efficient and secure use of Telecom Web Services Server.
When planning security for Telecom Web Services Server,
consider the following:
- Telecom Web Services Server supports WebSphere® Application Server global
security for the application server and administrative console. Global
security means that administrative and application security is enabled.
Roles defined for Telecom Web Services Server applications
must be mapped to users or groups when turning on security. For more
information, refer to the WebSphere Application Server Information
Center.
- The Trust Association Interceptor (TAI)
security component is the recommended security mechanism for handling
traffic from the IMS network.
A single sign-on scheme is recommended for transactions between the Access Gateway and
the Service Platform components,
and optionally between the Access Gateway and
the Service Policy Manager.
Note: This
model requires a two cluster deployment. If the TAI is
not used, and a combined Access Gateway and Service Platform components deployment
is used, then the Web service implementations will
run with security enabled. This requires roles for mapping to all
authenticated users. Calls can be enabled directly to the Web service implementations from
the enterprise domain, .bypassing the Access Gateway.
This method is not ideal, unless you take steps to prevent direct
calls. You can do this by instituting a firewall.
- Java™ 2 security must be
turned off.
- JMS/SIBus security must be turned off.
- HTTP digest authentication is supported.
Note: When WebSphere Application Server global
security is disabled, the Telecom Web Services Server user
is assigned to the "unauthenticated" user.
Common user registry
If you enable security
but do not choose to use the TAI,
then you must use an LDAP directory server, such as IBM Directory Server, to define
a common user registry for the Service Platform components,
the Access Gateway,
and the Service Policy Manager.
The
Access Gateway
acts as a point of authentication, so it requires a user registry.
For authentication to work properly, the following are strongly recommended:
- The Access Gateway must
share a common user registry with the Service Platform components.
- Single sign-on certificates must be established between the Access Gateway
server and the server that houses the Service Platform components.
Refer to the WebSphere Application Server information
center for information about configuring certificates for single sign-on.
Users and user roles
The following users
are required when you deploy WebSphere Telecom Web Services
Server.
- A user for access to the database, such as db2inst1 for DB2®. For Oracle, a user needs to
be created as described in the installation section of this Information
Center. The database user needs to be defined in the operating system
and the database server.
- A user for Service Policy Manager.
All authenticated users can be granted policy retrieval access. For
policy administration, the role should be mapped to an administrative
user.
- A WebSphere Application Server Administrator,
which should also be granted the TWSSAdministrator role. In addition,
the user should be added to the Integrated Solutions Console users
list. This user is defined in the WebSphere Application Server user
registry.
- A user for managing service policies. This user is granted the
PolicyAdministrator role and is defined in the WebSphere Application Server
user registry. This user can be a new user or one that previously
existed. When deploying of Service Policy Manager,
you should map the PolicyAccessor role to this user.
- A user for each service implementation. Examples of such users
include TS_Parlay_TSAccessor and SMS_SMPP_SMSAccessor. The users can be mapped to all authenticated users or to
a group of users that are enrolled in the system. To enroll each user
in the system, the user needs to be added to the user registry and
have policies set up. Each user is defined in the WebSphere Application Server user
registry.
The Telecom Web Services Server services
require that requesters be authenticated. All of the users you define
will be authenticated at the Access Gateway before
being passed to the individual services.
Considerations for the Access Gateway
The Access Gateway supports
standard WebSphere Application Server security
features. Access Gateway supports
Web services security capabilities according to the level supported
by the underlying WebSphere ESB and WebSphere Application Server.
For a secure environment, application and administration security
must be enabled. Web services security is intended to be applied between
third-parties and Access Gateway
exported flows. The WebSphere Enterprise Service
Bus information
center has instructions for enabling Web services security.
The Access Gateway acts
as an authentication point for Web service access to the IMS network. The
assumption is that the Web services reside in the trusted network.
When the Access Gateway passes
requests to Web services, it includes header information in the HTTP
request. The Access Gateway must
be able to front converged HTTP and SIP Web service requests for SIP
service implementations. This will require support for the session
affinity model.
WebSphere ESB version 6.2.0.2 or 7.0.0.1 does
not support propagation of session information. The Access Gateway provides
an extension to the platform to allow HTTP information to be propagated.
This propagation capability is only a conduit. Access Gateway instances
are intended to be stateless, which assures that any failover considerations
are pushed to the requesting client application.
The Web service implementations run
with security disabled, and they use asserted identities to pass security
credentials between the secured Access Gateway and
the trusted Web services. A trusted network is assumed; however, you
can enable transport-level security if desired.
Single sign-on
certificates are used for transactions between the Access Gateway and
the Service Platform components.
This makes it possible for the Access Gateway to
pass requests to the Service Platform components without
authentication credentials, which is the recommended approach.
Considerations for Service Platform components
Service Platform components typically
are deployed using the TAI trust
mechanism, with transport layer security using IPSec or SSL.
Service Platform components also
support transport level security (HTTP digest authentication). You
can enable SSL (HTTPS) authentication on the HTTP server.
Considerations for Web service implementations
In
addition to the security plans you implement for Telecom Web Services Server,
the Web service implementations can
also be affected by the way in which security is configured for the
remote network elements with which they interact–for example, IBM® XDMS or
the Parlay Connector.
Some of the Web service implementations
require specific Telecom Web Services Server policies
if you plan to enable security. For more information, review the policy
descriptions for each service implementation you plan to deploy. The
descriptions are found in the topic Reference: default policies
for the Access Gateway and Web services.