Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide (coming soon)
- Migrating from GT2
- Migrating from GT3
Reference
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces (coming soon)
- Resource Properties
- Samples
- Glossary
- Performance Studies (coming soon)
Manuals
Common Runtime
Security
- Non-WS (General) Security
- WS Java Security
- Message-level
- Authz Framework
- CAS
- Delegation Service
- MyProxy
- GSI-OpenSSH
- SimpleCA
- SGAS
Data Mgt
MDS4
Execution Mgt
Table of Contents
There are three main aspects to Java WS Security: authentication, message protection and authorization.
Authentication and message protection 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:
- Message-level Security mechanisms, which implement the WS-Security standard and the WS-SecureConversation specification to provide message protection for GT4’s SOAP messages
- Transport-level Security mechanisms, which use transport-level security (TLS) mechanisms
The message protection mechanisms are described in further detail under Message & Transport Level Security.
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 is permitted to perform the requested action. An Authorization Framework provides this functionality on the server and client side.
On the server side, authorization is accomplished via a framework that allows for a variety of authorization schemes, including the following:
- “grid-mapfile”,
- access control list,
- access control list defined by a service,
- custom authorization handler, and
- access to an authorization service via the SAML protocol.
On the client side, a similar but subset of the server mechanisms are provided. The client configures the preferred authentication mechanism to use for an invocation using stub configuration or security descriptors. Multiple message protection mechanisms can be used to secure the same message, with a performance cost incurred. The server can configure the set of acceptable security mechanisms in 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 mechanisms (see Message & Transport Level Security) allow for anonymous access, where the client need not furnish credentials. In this mechanism, authentication 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. Therefore, authorization must accomodate amonymous clients, if indeed the server would like to accept anonymous clients.
Another important piece of security infrastructure is 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.