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.
The following figure shows the different paths of communication within and to an example grid. The grid is called MyGrid, and it has two hosts and four different nodes. Keystores are denoted by padlock symbols.
Each grid has a master keystore called [gridname].ks. In this illustration, the grid is an ION Grid installed through the Java installation program, so this keystore (mygrid.ks) resides on Host 1. Mygrid.ks contains the grid root key pair, which is used to sign certificates in this grid.
Additionally, both hosts have their own server.ks keystore, which contains a host-specific key pair and a certificate signed with the grid root key. These credentials are used for communication between the nodes in the grid (N1-4), as well as for securing proxy calls.
Finally, there are host-specific https.ks keystores on both hosts. These contain the credentials used for SSL server authentication, when clients connect to the grid.
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 and ME clients). These clients access different types of grid-provided services.
The client connections are secured in the following manners:
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 server.ks. Clients may authenticate their users with a certificate signed by the grid root key, or through creating a session by calling a session provider (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 https.ks) or mutually authenticated. Clients may authenticate their users with a certificate signed by the grid root key. It is also possible to authenticate using regular HTTP transport security, for example, basic, digest, Kerberos, and so on. In the latter case, authentication is handled by the active session provider.
Web services use the same security mechanisms as web and REST applications. Additionally, Web Services Security with username and token may also be used.
Socket clients such as MI and ME (both of which are used in an M3 context) may use SSL, or an application-specific protocol to establish a session.
NoteIn order for server authentication to succeed, the client must trust the root key used to sign the certificate for the grid HTTPS keys.
In addition to the certificate-based authentication mentioned in Certificates in the Grid, the grid provides a pluggable architecture for using different sources and protocols for authentication such as LDAP, SAML, NTLM, or Kerberos. These services are provided by grid session providers. There are several different types of session provider, depending on the scenario.
When a user has been authenticated by a session provider, a grid session is created for that user.
Methods 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 are mapped in the Configuration Manager, using information obtained from the authentication source.
For more information, see Authorization Overview.