GT 4.1.2: Security

Abstract

Security tools are concerned with establishing the identity of users or services (authentication), protecting communications (message protection), and determining who is allowed to perform what actions (authorization). It also includes supporting functions such as managing user credentials and maintaining group membership information.

GT4 provides distinct WS and pre-WS authentication and authorization capabilities. Both build on the same base, namely standard X.509 end entity certificates and proxy certificates, which are used to identify persistent entities such as users and servers and to support the temporary delegation of privileges to other entities.

For more information about the security concepts behind GT4, see Security: Key Concepts.

For a comparison of features between Java and C code, see Security Features.

For firewall information, click here.

GT4’s Java WS security: As mentioned above, there are three main aspects to Java WS Security: authentication, message protection and authorization. Authentication and message protected are tightly coupled: authentication establishes that the remote entity is who he claims to be and then using the keys the message sent is secured. Toolkit supports two types of mechanisms to achieve this:

In all mechanisms supported in the toolkit, integrity and privacy protection mechanisms are supported, with integrity being the default level of protection. Also, the authentication is mutual in all cases, that is the server authenticates the client and the client authenticates the server.

Once authentication is complete, the peer identity is established and the next step is authorization. Authorization happens after authentication (and in some cases once a secure message is received), where you establish whether the remote entity can perform the action that is being requested. An Authorization Framework provides this functioanality on the server and client side. On the server side, a framework that allows for a variety of authorization schemes, including a “grid-mapfile” access control list, an access control list defined by a service, a custom authorization handler, and access to an authorization service via the SAML protocol, is used to accomplish this. On the client side, similar, but a subset of the mechanisms are provided.

The client configures the preferred authentication mechanism to use for an invocation using stub configuration or security descriptors. Multiple message protection mechanims can be used to secure the same message, with a performance cost incurred. The server can configure the set of acceptable security mechanisms an invocation using security descriptors. The server response is secured with the same protection mechanism as the request.

The WS Secure Conversation and Transport Layer Security mechanims, allow for anonymous access, where the client need not furnish credentials. In this mechanism authentiction and message protection steps are still done and it is not an insecure call. But the keys are generated on the fly and the server has no way to establish the identity of the client. So authorization has to accomadate amonymous clients, if indeed the server would like to accept anonymous clients.

Another important piece of security infrastructure if the ability of an entity to delegate its rights to another. The WS Secure Conversation mechanism allows for delegation as a part of the protocol and alternatively Delegation Service can be used to delegate credentials to any service.

The toolkit also provides Community Authorization Service (CAS), a service that can be used to manage and assert fine-grained rights for users.

GT4’s Pre-WS security: GT4 provides similar authentication, delegation, and authorization mechanisms, although with fewer authorization options. Refer to Pre-WS Authentication & Authorization.

Other security components include:

TODO: add blurb about SGAS (SweGrid Accounting System)