ION Grid security overview

Most grid security considerations are related to communication – communication within a grid, as well as to and from different types of grid clients. To maintain the security of this communication, the grid uses certificates for communication within a grid. In addition, for communication involving grid clients, it uses both certificates and other types of authentication, such as those provided through session providers. You can further use session-based authentication and role restrictions to control access to methods or functionality within a grid.

Certificates in the Grid

The figure shows the different paths of communication within and to an example grid. The grid has two hosts and four different nodes. Keystores are denoted by padlock symbols. The keystores are persisted in the grid database, but shown here for each host.

Each grid has a master keystore called the grid root keystore. The grid root keystore contains the grid root key pair, which is used to sign certificates in this grid.

Additionally, both hosts have two server keystores (server.ks and client.ks). Each keystore contains a host-specific key pair and a certificate signed with the grid root key. These credentials are used for communication between the nodes and the host routers, as well as for securing proxy calls.

Finally, there are keystores for the host default HTTPS identities for each host. These contain the credentials used for SSL server authentication, when clients connect to the grid. By adding additional HTTPS identities, routers can be configured to use other keystores.

Grid-provided services

As shown in the previous figure, a grid can be accessed by different types of clients. These include proxy clients, HTTP clients (web application, REST application, and web service), and socket clients (MI clients). These clients access different types of grid-provided services.

The client connections are secured in the following manners:

  • Proxy clients

    Grid proxy calls are transmitted over the grid proxy protocol, which in turn uses sockets or secure sockets. The server authenticates with the key material in the server keystore. Clients may authenticate their users with a certificate signed by the grid root key, or through creating a session (see Grid principals and sessions) once the connection has been established.

  • Web and REST applications

    Web and REST applications can be accessed via HTTP or HTTPS, in which case the connection can be either server-authenticated (using the key material in the HTTPS identity keystore used by the accessed router) or mutually authenticated. Clients may authenticate their users with a certificate signed by the grid root key or by a CA whose certificate is in the HTTPS identity trust store. It is also possible to authenticate using regular HTTP transport security.

  • Web services

    Web services use the same security mechanisms as web and REST applications.

  • Socket clients

    Socket clients such as MI (which is used in an M3 context) may use SSL, or an application-specific protocol to establish a session.

Note: In order for server authentication to succeed, the client must trust the root key used to sign the certificate for the router's HTTPS keys. Read more about HTTPS identities and certificates in section "HTTPS/SSL certificates".

Authentication

In addition to the certificate-based authentication mentioned previously, the grid provides SAML authentication for end user.

When a user has been authenticated, a grid session is created for that user.

For more information, see Authentication overview and Grid principals and sessions.

Authorization

Functionality in the grid may be protected in one of several ways. The authorization level that mostly affects users is the session-based authorization with or without role restrictions. Plain session-based authorization means that a user must have a valid grid session (that is, the user must be authenticated). When role restrictions are added, the authenticated user needs to have at least one of a predetermined set of roles. These roles can be mapped to other roles in the Grid Management Pages by using information obtained from the authentication source.

For more information, see Authorization Overview.