Administration guide > Secure the deployment environment



Security integration with WAS

When WebSphere eXtreme Scale is deployed in a WAS environment, you can simplify the authentication flow and transport layer security configuration from WAS.


Simplified authentication flow

When eXtreme Scale clients and servers are running in WAS and in the same security domain, you can use the WAS security infrastructure to propagate the client authentication credentials to the eXtreme Scale server. For example, if a servlet acts as an eXtreme Scale client to connect to an eXtreme Scale server in the same security domain, and the servlet is already authenticated, it is possible to propagate the authentication token from the client (servlet) to the server, and then use the WAS security infrastructure to convert the authentication token back to the client credentials.

Figure 1. Authentication flow for servers within the same security domain

All the application servers are in a common security domain.

In the previous diagram, the application servers are in the same security domain. One application server hosts the web application, which is also an eXtreme Scale client. The other application server hosts the container server. The deployment manager or node agent JVM (JVM) hosts the catalog service. The arrows in the diagram indicate how the authentication process flows:

  1. An enterprise application user uses a Web browser to log in to the first application server with a user name and password.

  2. The first application server sends the client user name and password to the WAS security infrastructure to authenticate with the user registry. For example, this user registry might be an LDAP server. As a result, the security information is stored in the application server thread.

  3. The JSPs file acts as an eXtreme Scale client to retrieve the security information from the server thread. The JSP file calls the WAS security infrastructure to get the security tokens that represent the enterprise application user.

  4. The eXtreme Scale client, or JSP file, sends the security tokens with the request to the container server and catalog service that is hosted in the other JVMs. The catalog server and container server use the WAS security tokens as an eXtreme Scale client credential.

  5. The catalog and container servers send the security tokens to the WAS security infrastructure to convert the security tokens into user security information. This user security information is represented by a Subject object, which contains the principals, public credentials, and private credentials. This conversion can occur because the application servers that are hosting the eXtreme Scale client, catalog server, and container server are sharing the same WAS Lightweight Third-Party Authentication (LTPA) tokens.


Authentication integration


Distributed security integration with WAS:

For the distributed model, use the following classes:

For examples on how to use these classes, see Tutorial: Integrate WebSphere eXtreme Scale security with WAS.

On the server side, use the WSTokenAuthentication authenticator to authenticate the WSTokenCredential object.


Local security integration with WAS:

For the local ObjectGrid model, use the following classes:

For more information about these classes, see Local security. You can configure the WSSubjectSourceImpl class as the SubjectSource plug-in, and the WSSubjectValidationImpl class as the SubjectValidation plug-in.


Transport layer security support in WAS

When an eXtreme Scale client, container server, or catalog server is running in a WAS process, eXtreme Scale transport security is managed by the WAS CSIV2 transport settings. For the eXtreme Scale client or container server, you should not use eXtreme Scale client or server properties to configure the SSL settings. All the SSL settings should be specified in the WAS configuration.

However, the catalog server is a little different. The catalog server has its own proprietary transport paths which cannot managed by the WAS CSIV2 transport settings. Therefore, the SSL properties still need to be configured in the server properties file for the catalog server. See Tutorial: Integrate WebSphere eXtreme Scale security with WAS for more information.


Parent topic:

Secure the deployment environment


Related concepts

Data grid authentication

Data grid security

Application client authentication

Application client authorization

Transport layer security and secure sockets layer

Java Management Extensions (JMX) security

Security integration with external providers


Related tasks

Enable local security

Start and stop secure servers

Secure the REST data service

Start secure servers in WAS

Start and stop servers in a WAS environment

Troubleshoot security

Related reference

Security descriptor XML file

objectGridSecurity.xsd file

Server properties file


Related information

Tutorial: Integrate WebSphere eXtreme Scale security with WAS

Tutorial: Integrate WebSphere eXtreme Scale security in a mixed environment with an external authenticator

Lesson 2.2: Configure catalog server security

Lesson 2.3: Configure container server security


+

Search Tips   |   Advanced Search