Table of Contents
This component provides an API for authentication and two APIs for authorization.
The authentication API is an implementation of the GSS-API (RFC 2743 and RFC 2744) extended with the functions described in the GSS-API Extensions document.
On the authorization front there is a coarse grained API, which in addition to authorizing also provides a mapping function, and an API that allows finer grained authorization decisions to be made. The finer grained API follows the subject, object, action paradigm.
Both of the authorization APIs allow different back end implementations through the use of dynamic library loading.
Features new in GT 4.0
- None
Other Supported Features
- Authentication of user using standard X.509 End Entity and Proxy Certificates.
- Delegation using X.509 Proxy Certificates.
- Pluggable authorization based on the client's certificate chain for GridFTPD and Pre-WS GRAM.
- Pluggable authorization for Pre-WS GRAM based on the RSL of the job.
Deprecated Features
- None
Protocol changes in Pre-WS Authentication and Authorization since GT 3.2
- None
API changes since GT 3.2
- None
Exception changes since GT 3.2
- Not applicable
Schema changes since GT 3.2
- Not applicable
The Pre-WS Authentication and Authorization component depends on the following GT components:
- C Common Libraries
The Pre-WS Authentication and Authorization component depends on the following 3rd party software:
- OpenSSL
During host authorization, the toolkit treats DNs "hostname-*.edu" as equivalent to "hostname.edu". This means that if a service was setup to do host authorization and hence accept the certificate "hostname.edu", it would also accept certificates with DNs "hostname-*.edu".
The feature is in place to allow a multi-homed host following a "hostname-interface" naming convention to have a single host certificate. For example, host "grid.test.edu" would also accept the likes of "grid-1.test.edu" or "grid-foo.test.edu".
![[Note]](../../../../../docbook-images/note.gif) | Note |
|---|---|
The wildcard character "*" matches only the name of the host and not the domain components. This means that "hostname.edu" will not match "hostname-foo.sub.edu" but will match "host-foo.edu". |
| Note |
|---|---|
If a host was set up to accept "hostname-1.edu", it will not accept any of "hostname-*.edu". |
A bug has been opened to see if this feature needs to be modfiied.
As mentioned in the introduction, the pre-WS security framework uses the GSSAPI API and extensions to it to abstract security mechanism specific details. Below the GSSAPI layer there exist multiple APIs for dealing with credential management, X.509 certificates in general and proxy certificates in particular as well as security configuration. Each of these APIs is described in more detail below.
The general design principle guiding these APIs is data encapsulation. Data structures (handles and attributes) capture and encapsulate the state of the system. These data structures are then acted upon by various getters and setters, as well as other functions.
The GSS Assist API provides helper functions wrapping the process of security (GSS) context establishment, support for gridmap authorization and various other helper functions that wrap GSSAPI functions and capture common usage.
The GSSAPI implementation provided by the toolkit is based upon SSL/TLS with extensions to the standard path validation mechanism to handle proxy certificates. It relies upon the credential and certificate utility APIs for general certificate acquisition and inspection functionality.
This API provides a callback that can be plugged into the OpenSSL path validation framework. This callback provides the additions to path validation required for dealing with proxy certificates and X.509 extensions. Furthermore, it allows applications to inspect data, e.g. the validated certificate chain, after the validation is done.
The Certificate Utilities API provides helper functions for dealing with X.509 certificates. This API does not use the "handle" concept mentioned in the introduction. Rather, it operates on datatypes provided by the OpenSSL APIs.
The Credential API deals with reading and writing certificates from and to the file system and the OpenSSL I/O abstraction layer. It also provides functions for inspecting and validating the read credentials.
The Proxy APIs provide a implementation of the X.509 Proxy Certificate Extension ASN.1 structure as well as functions for creating new proxies.
This API serves as an abstraction layer for OS specific information needed by the security infrastructure. It provides OS specific functions for discovering certificates from a set of predefined standard locations as well as functions for doing the same for various configuration files.
As described in the introduction the pre-WS security framework essentially provides two authorization APIs, the generic Authorization API and the Gridmap API. These APIs differ in various ways:
The Authorization API provides a framework that allows callouts to 3rd party authorization solutions, does not provide a default authorization mechanism and is geared to authorizing the subject-action-object tuple.
The Gridmap API on the other hand, while allowing for custom callouts to be plugged in and override the default behavior, provides a default authorization and mapping mechanism based on the grid map file. Also, it only furnishes the callouts with information about the entity to be authorized, i.e. it does not provide information on the action and the object, so it is somewhat simpler in its approach. Finally, it provides the ability to map authorized entities to local system entities, e.g. UNIX user names. More information on the interface used for Gridmap callouts can be found here.
The semantics and syntax of the APIs for the component, along with descriptions of domain-specific structured interface data, can be found in the public interface guide.
- RFC 3820 Proxy Certificates
- RFC 2744 GSSAPI: C-bindings
- RFC 2743 GSSAPI
- GSSAPI Extensions
- RFC 2246 TLS
- Grid Security Infrastructure Message Specification