Introduction
This component contains mainly framework-level code and, as such, developing services and clients utilizing this component does in general involve either programmatically or declaratively driving the framework-level security code.
Now, what does this entail? On the programmatic side of things, it involves acquiring credentials, passing these credentials on to the framework, and setting various authentication- and protection-related flags, either in a descriptor or as properties on a stub object. On the declarative side, it involves setting up security descriptors, both client and service side, to prescribe the security policy used to drive the security framework code.
Table of Contents
- 1. Before you begin
- 2. Usage scenarios
- 3. Tutorials
- 4. Architecture and design overview
- 5. APIs
- 6. Services and WSDL
- 7. Framework-level Protocols
- Command-line tools
- globus-credential-delegate - Delegation client
- 8. Domain-specific interface
- 9. Configuring
- 10. Environment variable interface
- 11. Debugging
- 12. Troubleshooting
- 13. Related Documentation
- Glossary
Table of Contents
Features new in GT 4.2.1
None.
Other Supported Features
- Compliance with published IBM/Microsoft WS-Trust and WS-SecureConversation specifications
- Compliance with the Web Services Security 1.0 standard
- HTTPS support
- Message integrity protection.
Deprecated Features
- None.
C WS A&A should work on any platform that supports J2SE 1.3.1 or higher.
Tested Platforms for C WS A&A
- Linux (Red Hat 7.3)
- Windows 2000
- Solaris 9
Since GT 4.2.0 release, some incompatible changes have been made:
- Security Descriptors: The security descriptor schema has changed since GT 4.0.x and the descriptors from GT 4.0.x cannot be used as is.
- Secure Conversation port type: The WS Addressing version in Java WS Core has been updated and the secure conversation port type has changed to reflect this. Therefore, GT 4.0.x secure conversation clients are incompatible with GT 4.2.x servers and vice versa.
C WS A&A depends on the following GT components:
C WS Core
GSI
C WS A&A depends on the following 3rd party software:
The Java security code currently does not enforce secure permissions and, implicitly, file ownership requirements on any of the security related files, e.g. configuration and credential files. It is thus important that administrators ensure that the relevant files have correct permissions and ownership. Permissions should generally be as restrictive as possible, i.e. private keys should be readable only by the file owner and other files should be writable by owner only, and the files should generally be owned by the globus user (the requirements that the C code enforces are documented in Configuring GSI).
Also refer to Section 5, “Known Problems” for details on any other open issues.
Table of Contents
There are two ways a client can delegate its credential to a service:
using Delegation Service, and
using GSI Secure Conversation.
A client can delegate using the Delegation Service. This method is independent of the security scheme used and can be reused across multiple invocations of the client to multiple services (provided the services are in the same hosting environment as the Delegation Service). The link provided has details on client-side steps to delegate and service-side code to get the delegated credential.
GSI Secure Conversation has delegation built into the protocol.
Delegation can be requested by setting the GSIConstants.GSI_MODE
property on the Stub. If full or limited
delegation is performed, the client credential can be obtained from the
message context as follows:
Subject subject = (Subject) msgCtx.getProperty(Constants.PEER_SUBJECT);
The server can be configured such that container, service or
client credentials are used for the operation invoked. For the client
credentials to be used, the client should have delegated the
credentials.
Note that this is a server-side configuration. If
caller-identity is chosen for the
run-as configuration and the client's credentials
have been successfully delegated, then the delegated credentials are
associated with the current thread. The credentials in this case can be
obtained as follows:
Subject subject = JaasSubject.getCurrentSubject();
GT provides an API to embed key information in an Endpoint Reference, as defined in the OGSA Basic Security Profile. The key information is embedded in the extensibility element of the EPR rather than the meta-data element as defined in the specification, since the toolkit uses older version of the WS Addressing specification.
This information would be useful to ascertain the expected
identity of the service for authorizing the service or to get the public
certificate of the resource to be used for encrypting the request to the
service. The optional usage element in
the emebedded key information indicates the use of the embedded keys,
either for signature or encryption.
The API is in class
org.globus.wsrf.impl.security.util.EPRUtil. The
method to embed the certificates is called
insertCertificates and the method to extract the
key information is called extractCertificates.
Please refer to API
documentation for details on using the methods.
The security handlers populate a Subject object with peer information. The following code can be used to access the peer credentials. Note that the message context needs to be associated with the thread.
import org.globus.wsrf.security.SecurityManager;
import javax.security.auth.Subject;
org.apache.axis.MessageContext mctx =
org.apache.axis.MessageContext.getCurrentContext();
SecurityManager manager = SecurityManager.getManager(mctx);
Subject subject = manager.getPeerSubject();
The following code snippet shows how the certificate chain can be extracted from the peer subject:
java.util.Set set =
subject.getPublicCredentials(X509Certificate[].class);
Iterator iterator = set.iterator();
while (iterator.hasNext()) {
X509Certificate[] certArray = (X509Certificate[]) iterator.next();
System.out.println("Cert array " + certArray.length);
}
To obtain the peer principal (for example, the Distinguished Name from X509 Certificate), the following code snippet can be used:
org.apache.axis.MessageContext mctx =
org.apache.axis.MessageContext.getCurrentContext();
SecurityManager manager = SecurityManager.getManager(mctx);
Principal principal = manager.getCallerPrincipal();
String caller = manager.getCaller();
If credentials were delegated as described above, private credentials are also populated:
java.util.Set set = subject.getPrivateCredentials();
GSI Secure Conversation: With this mechanism, the peer credentials can be obtained once the handshake is completed:
import org.globus.wsrf.impl.security.authentication.Constants; import org.globus.wsrf.impl.security.authentication.secureconv.service.SecurityContext; import org.ietf.jgss.GSSContext; import org.globus.gsi.gssapi.GSSContants; // Get current secure context from message context SecurityContext secContext = messageContext.getProperty(Constants.CONTEXT); GSSContext gssContext = secContext.getContext(); Vector peerCerts = gssContext.inquireByOid(GSSContants.X509_CERT_CHAIN);GSI Secure Transport: With this mechanism, the peer credentials can be obtained once the handshake is completed:
import org.ietf.jgss.GSSContext; import org.globus.gsi.gssapi.GSSContants; import org.globus.wsrf.impl.security.authentication.Constants; // Get current secure context from message context GSSContext gssContext = messageContext.getProperty(Constants.TRANSPORT_SECURITY_CONTEXT); Vector peerCerts = gssContext.inquireByOid(GSSContants.X509_CERT_CHAIN);GSI Secure Message: With this mechanism, the peer credentials can be obtained only when the response is received:
import org.globus.wsrf.impl.security.authentication.Constants; // Get peer subject from current message context Subject subject = (Subject) messageCtx.getProperty(Constants.PEER_SUBJECT); Set peerCerts = subject.getPublicCredentials(X509Certificate[].class);
Multiple message protection schemes can be used in a single invocation, although it is worth noting that this will cause a performance penalty.
For example, both Secure Transport and Secure Conversation can be done on the same invocation by using the following:
stub._setProperty(Constants.GSI_SEC_CONV, Constants.INTEGRITY);
stub._setProperty(Constants.GSI_TRANSPORT, Constants.PRIVACY);
![[Note]](/docbook-images/note.gif) | Note |
|---|---|
These two mechanisms share a single property for authorization. There is a bug open to provide independent support: Bug 4350 |
Similarly Secure Messages can be used in tandem with other message protection mechanisms.
Table of Contents
The toolkit by default is deployed with our implementation of transport security, which is based on HTTP over SSL, also known as HTTPS, with modifications to path validation to enable X.509 Proxy Certificate support. In contrast to the GT3 version of the toolkit, the default transport security enabled in the toolkit does not support delegation of proxy certificates as part of the security handshake.
However, the underlying security libraries and handlers required for secure transport with delegation, also known as HTTPG, is still supported and shipped as part of the CoG library. The GT4 Java WS code base and configuration can be modified to use the HTTPG protocol as required.
Transport security is implemented by layering on top of the GSISocket class provided in JGlobus. This class deals with the security-related aspects of connection establishment as well as message protection. The socket interface serves as an abstraction layer that allows the HTTP protocol handling code to be unaware of the underlying security properties of the connection.
Container-level credentials are required and, irrespective of security settings on the service being accessed, these credentials are used for the handshake.
On the server-side, transport security is enabled by simply switching a non-secure socket implementation with the GSISocket implementation. In addition to this change, some code was added to propagate authentication information and message protection settings to the relevant security handlers, in particular the authorization and security policy handlers.
On the client-side, transport security is similarly enabled by switching a non-secure socket implementation with the GSISocket implementation and registering a protocol handler for HTTPS that uses the secure socket implementation. In practice, this means that any messages targeted at an HTTPS endpoint will, irregardless of any stub properties, be authenticated and protected. It also means that any messages sent to an HTTP endpoint will not be secured, again irregardless of any stub properties. Stub properties are only used to communicate the desired message protection level, i.e. either integrity only or integrity and privacy.
This section aims to describe the message flow and processing that occurs for a security-enabled service. The figure below shows the JAX-RPC handlers that are involved in security-related message processing on a server.
GT4 provides two mechanisms, GSI Secure Conversation and GSI Secure Message security, for authentication and secure communication.
In the GSI Secure Conversation approach the client establishes a context with the server before sending any data. This context serves to authenticate the client identity to the server and to establish a shared secret using a collocated GSI Secure Conversation Service. Once the context establishment is complete, the client can securely invoke an operation on the service by signing or encrypting outgoing messages using the shared secret captured in the context.
The GSI Secure Message approach differs in that no context is established before invoking an operation. The client simply uses existing keying material, such as an X509 End Entity Certificate, to secure messages and authenticate itself to the service.
Securing of messages in the GSI Secure Conversation approach, i.e. using a shared secret, requires less computational effort than using existing keying material in the GSI Secure Message approach. This allows the client to trade off the extra step of establishing a context to enable more computationally efficient messages protection once that context has been established.
When a message arrives from the client, the SOAP engine invokes several security-related handlers:
The first of these handlers, the WS-Security handler, searches the message for any WS-Security headers. From these headers, it extracts any keying material, which can be either in the form of an X509 certificate and associated certificate chain or a reference to a previously established secure conversation session. It also checks any signatures and/or decrypts elements in the SOAP body. The handler then populates a peer JAAS subject object with principals and any associated keying material whose veracity was ascertained during the signature checking or decryption step.
The next handler that gets invoked, the security policy handler, checks that incoming messages fulfill any security requirements the service may have. These requirements are specified, on a per-operation basis, as part of a security descriptor during service deployment. The security policy handler will also identify the correct JAAS subject to associate with the current thread of execution. Generally, this means choosing between the peer subject populated by the WS-Security handler, the subject associated with the hosting environment and the subject associated with the service itself. The actual association is done by the pivot handler, a non-security handler not shown in the figure that handles the details of delivering the message to the service.
The security policy handler is followed by an authorization handler. This handler verifies that the principal established by the WS-Security handler is authorized to invoke the service. The type of authorization that is performed is specified as part of a deployment descriptor. More information can be found in the authorization framework documentation.
Once the message has passed the authorization handler, it is finally handed off to the actual service for processing (discounting any non-security-related handlers, which are outside the scope of this document).
Replies from the service back to the client are processed by two outbound handlers: the GSI Secure Conversation message handler and the GSI Secure Message handler. The GSI Secure Conversation message handler deals with encrypting and signing messages using a previously established security context, whereas the GSI Secure Message handler deals with messages by signing or encrypting the messages using X509 certificates.
The operations that are actually performed depend on the message properties associated with the message by the inbound handlers, i.e. outbound messages will have the same security attributes as inbound messages. That being said, a service has the option of modifying the message properties, if so desired. These handlers are identical to the client-side handlers described in the following section.
This section describes the security-related message processing for Java-based GT4 clients. In contrast to the server side, where security is specified via deployment descriptors, client side security configuration is handled by the application. This means that a client-side application must explicitly pass information to the client-side handlers on what type of security to use. This is also true for the case of services acting as clients. The below figure shows the JAX-RPC handlers that are involved in security-related message processing on a server.
The client-side application can specify the use of either the GSI Secure Conversation security approach or the GSI Secure Message security approach. It does this by setting a per-message property that is processed by the client-side security handlers.
There are three outbound client-side security handlers:
The secure conversation service handler is only operational if GSI Secure Conversation mode is in use. It establishes a security session with a secure conversation service collocated with the service with which the client aims to communicate. When the client sends the initial message to the service with a property indicating that session-based security is required, this handler intercepts the message and establishes a security session. It will also authorize the service by comparing the service's principal/subject obtained during session establishment with a value provided by the client application. Once the session has been established, the handler passes on the original message for further processing.
The next handler in the chain, the secure message handler, is only operational if GSI Secure Message mode is in use. It signs and/or encrypts messages using X.509 credentials.
The third outbound handler [fixme - is there a name?] is operational only if GSI Secure Conversation mode is in use. It handles signing and/or encryption of messages using a security session established by the first handler.
The client-side inbound handler (the WS-Security client handler) deals with verifying and decrypting any signed and/or encrypted incoming messages. In the case of the GSI Secure Message operation, it will also authorize the remote side in a similar fashion to the outbound secure conversation service handler.
Table of Contents
The security programming model differs between the client and server side. The client side model is programmatic in nature, i.e. security-related code is driven by making actual function calls, whereas the server-side model is declarative, i.e. security-related settings are declared in a security descriptor. For more information on the available client side calls see Chapter 4, Configuring client authentication and message/transport security. More information about the security descriptor can be found in Java WS A&A Security Descriptor Framework.
Stable interfaces:
- org.globus.wsrf.security.Constants
- org.globus.wsrf.security.SecureResource
- org.globus.wsrf.security.SecurityManager
- org.globus.wsrf.security.SecurityException
Less stable interfaces:
- org.globus.wsrf.impl.security.descriptor.ClientSecurityDescriptor
- org.globus.wsrf.impl.security.descriptor.ResourceSecurityDescriptor
Documentation for these interfaces can be found here.
Table of Contents
This service provides a mechanism for generating a security session, i.e the negotiation of a shared secret which may be used to secure a set of subsequent messages. It is based on the WS-Trust and WS-SecureConversation specifications.
RequestSecurityToken: This operation initiates a new security session negotiation. Furthermore, since the actual schema for this message is not unambiguously defined by the specifications, this is the actual schema used:
<xs:element name='RequestSecurityToken'>
<xs:complexType name='RequestSecurityTokenType'>
<xs:sequence>
<xs:element ref='wst:TokenType'/>
<xs:element ref='wst:RequestType'/>
<xs:element ref='wst:BinaryExchange'/>
</xs:sequence>
<xs:attribute name='Context' type='xs:anyURI'/>
</xs:complexType>
</xs:element>
<xs:element name='RequestSecurityTokenResponse'>
<xs:complexType name='RequestSecurityTokenResponseType'>
<xs:sequence>
<xs:element ref='wst:TokenType'/>
<xs:element ref='wst:RequestType'/>
<xs:element ref='wst:BinaryExchange'/>
</xs:sequence>
<xs:attribute name='Context' type='xs:anyURI'/>
</xs:complexType>
</xs:element>RequestSecurityTokenResponse: This operation continues a security session negotiation. Furthermore, since the actual schema for this message is not unambiguously defined by the specifications, this is the actual schema used:
<xs:element name='RequestSecurityTokenResponse'>
<xs:complexType name='RequestSecurityTokenResponseType'>
<xs:sequence>
<xs:element ref='wst:TokenType'/>
<xs:element ref='wst:RequestType'/>
<xs:element ref='wst:BinaryExchange'/>
</xs:sequence>
<xs:attribute name='Context' type='xs:anyURI'/>
</xs:complexType>
</xs:element>
<xs:element name='RequestSecurityTokenResponse'>
<xs:complexType name='RequestSecurityTokenResponseType'>
<xs:sequence>
<xs:element ref='wst:TokenType'/>
<xs:element ref='wst:RequestType'/>
<xs:element ref='wst:BinaryExchange'
minOccurs="0"/>
<xs:element ref='wsc:SecurityContextToken'/>
</xs:sequence>
<xs:attribute name='Context' type='xs:anyURI'/>
</xs:complexType>
</xs:element> In the above schema, the second
RequestSecurityTokenResponse element refers to the
final message in the exchange.
Both RequestSecurityToken and
RequestSecurityTokenResponse throw the following
faults:
ValueTypeNotSupportedFault: This fault indicates that the value type attribute on the binary exchange token element is not supported by the service.EncodingTypeNotSupportedFault: This fault indicates that the encoding type attribute on the binary exchange token element is not supported by the service.RequestTypeNotSupportedFault: This fault indicates that the request type specified in the request type element is not supported by the serviceTokenTypeNotSupportedFault: This fault indicates that the token type specified in the token type element is not supported by the service.MalformedMessageFault: This fault indicates that the message content received by the service does not conform to the expected content. This is necessary since the schema does not give a well defined content model.BinaryExchangeFault: This fault indicates that a failure occurred during the in the underlying security constant responsible for the session negotiation.InvalidContextIdFault: This fault indicates that the context id passed in the message is not valid within the context of this service or negotiation.
- WS-Trust WSDL
- WS-Trust XSD
- WS-SecureConversation XSD
- Secure Conversation WSDL [fixme - link]
Table of Contents
The framework implements the Web Services Security: SOAP Message Security, Web Services Security: Username Token Profile and Web Services Security: X.509 Token Profile specifications.
The transport security solution used by the framework consists of HTTP over SSL/TLS (HTTPS) using X.509 certificates. The path validation step has been augmented to support the Proxy Certificate Profile (RFC3820).
Table of Contents
- globus-credential-delegate - Delegation client
Name
globus-credential-delegate — Delegation client
Synopsis
globus-credential-delegate
Tool description
Used to contact a Delegation Factory Service and store a delegated credential. A delegated credential is created and stored in a delegated credential WS-Resource, and the Endpoint Reference(EPR) of the credential is written out to a file for further use.
Command syntax
globus-credential-delegate [options] <eprFilename>
Table 1. globus-credential-delegate options
| [option1] | Enables anonymous authentication. Only supported with transport security or the GSI Secure Conversation authentication mechanism. |
| [option1] | Specifies the server's certificate file used for encryption. Only needed for the GSI Secure Message authentication mechanism. |
Table of Contents
Client-side security is set up by setting individual
properties on the javax.xml.rpc.Stub
object used for the web service method invocation or by setting properties
on a client-side security descriptor object, which in turn is propagated
to client-side security handlers by making it available as a stub object
property. Here are examples of the two approaches:
Setting a property on the stub:
// Create endpoint reference EndpointReferenceType endpoint = new EndpointReferenceType(); // Set address of service String counterAddr = "http://localhost:8080/wsrf/services/CounterService"; // Get handle to port CounterPortType port = locator.getCounterPortTypePort(endpoint); // set client authorization to self ((Stub)port)._setProperty(Constants.AUTHORIZATION, SelfAuthorization.getInstance());Setting properties using a client descriptor:
// Client security descriptor file String CLIENT_DESC = "org/globus/wsrf/samples/counter/client/client-security-config.xml"; // Create endpoint reference EndpointReferenceType endpoint = new EndpointReferenceType(); // Set address of service String counterAddr = "http://localhost:8080/wsrf/services/CounterService"; // Get handle to port CounterPortType port = locator.getCounterPortTypePort(endpoint); //Set descriptor on Stub ((Stub)port)._setProperty(Constants.CLIENT_DESCRIPTOR_FILE, CLIENT_DESC);
| Note |
|---|---|
If the client needs to use transport security, the following API
must be used to register the Axis transport handler for
import org.globus.axis.util.Util;
static {
Util.registerTransport();
}
|
Table 8.1. Client side security properties
| Number | Task | Stub Configuration | |
| 1. | Allows for configuration of credentials for authentication. | Property: org.globus.axis.gsi.GSIConstants.GSI_CREDENTIALS Value equals the Instance of
| |
| 2. | Allows for configuring client-side authorization. | Property: org.globus.wsrf.security.Constants.AUTHORIZATION Value equals the Instance of
If GSI Secure Transport or GSI Secure Conversation is
used, the value should be an instance of
| |
| 3. | Enable GSI Secure Conversation with specified message protection level. | 1. Property: org.globus.wsrf.security.Constants.GSI_SEC_CONV Values equal one of the following:
2. Property: org.globus.wsrf.security.Constants.GSI_SEC_CONV_SECREPLY_UNNECESSARY
If the value is set to Boolean.TRUE, the GSI Secure conversation protection is not required in the reply message. By default, if the request was secured with GSI Secure Conversation, the response is also required to have the same protection. 3. Property: You can set
the SOAP Actor of the GSI signed/encrypted SOAP message by using
the | |
| 4. | Sets the GSI delegation mode. Used for GSI
Secure Conversation only. If limited or full
delegation is chosen, then some form of client-side
authorization needs to be done (i.e client-side authorization
cannot be set to none). | Property: org.globus.axis.gsi.GSIConstants.GSI_MODE Value equals one of following:
| |
| 5. | Enables GSI Secure Transport with some protection level. | Property: org.globus.gsi.GSIConstants.GSI_TRANSPORT Values equal one of the following:
| |
| 6. | Enables anonymous authentication. This option only applies to GSI Secure Conversation and GSI Transport. | Property: org.globus.wsrf.security.Constants.GSI_ANONYMOUS Value equals one of following:
| |
| 7. | Enable GSI Secure Message with specified message protection level. | 1. Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG Values equal one of the following:
2. Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG_SECREPLY_UNNECESSARY
If the value is set to Boolean.TRUE, the GSI Secure Message protection is not required in the reply message. By default, if the request was secured with GSI Secure Message, the response is also required to have the same protection. 3. Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG_SINGLECERT
If the value is set to Boolean.TRUE, only a single certificate is used for the GSI Secure Message request. By default, the whole certificate chain is sent. 4. Property: You can set the SOAP Actor of the signed
message using the | |
| 8. | Enable WS-Security username/password authentication. | Properties: org.globus.wsrf.security.Constants.USERNAME Value equals the username. org.globus.wsrf.security.Constants.PASSWORD Value equals the password. | |
| 9. | Sets the credential that is used to encrypt the message (typically, the recipient's public key). Used for GSI Secure Message only. | Property: org.globus.wsrf.impl.security.authentication
.Constants.PEER_SUBJECT Value
equals the instance of
The credential object needs to be wrapped in
For example,
if Subject subject = new Subject();
X509Certificate serverCert =
CertUtil.loadCertificate(publicKeyFilename);
EncryptionCredentials encryptionCreds =
new EncryptionCredentials(
new X509Certificate[] { serverCert });
subject.getPublicCredentials().add(encryptionCreds);
stub._setProperty(Constants.PEER_SUBJECT, subject);
| |
| 10. | Sets the trusted certificates location. | Property: org.globus.wsrf.security.TRUSTED_CERTIFICATES Value should be a comma-separated list of directories and file names. | |
| 11. | Sets the SAML Authorization Assertion to embed in SOAP Header. | Property: org.globus.wsrf.impl.security.authentication.Constants.SAML_AUTHZ_ASSERTION Value should be an instance of org.opensaml.SAMLAssertion. | Cannot be configured using descriptors. |
Table of Contents
Configuration of service-side security settings can be achieved by using container or service security descriptor. Some of the security configuration, like the credential to use and trusted certificates location, can also be configured using CoG properties or rely on default location. The preferred way is to provide these settings in a security descriptor.
The next section provides details on the relevant properties. An overview of the syntax of security descriptors can be found in Java WS A&A Security Descriptor Framework. Available CoG security properties can be found in Chapter 2, Configuring
The following properties are relevant to authentication and message/transport security:
Table 9.1. Configuring server side authentication and message/transport security
| Number | Task | Descriptor Configuration | Alternate Configuration |
| 1 | Credentials | Container or service descriptor configuration |
If no explicit configuration is
found, the default proxy is read from
|
| 2 | Trusted Certificates | Container security descriptor configuration | CoG Configuration |
| 3 | Limited proxy policy configuration | Container or service descriptor configuration | None. |
| 4 | Replay Attack Window | Container or service descriptor configuration | None. |
| 5 | Replay Attack Filter | Container or service descriptor configuration | None. |
| 6 | Replay timer interval | Container descriptor configuration | None. |
| 7 | Context timer interval | Container descriptor configuration | None. |
Table of Contents
Refer to Chapter 2, Configuring for environment variables. Note that the above environment variable [fixme - not clear which envar you mean] does not supersede any settings provided in security descriptors.
Table of Contents
Because C WS A&A is built on top of C WS Core, developer debugging is the same as described in Chapter 8, Debugging.
For information about system administrator logs, see Chapter 6, Debugging.
C WS Core also provides an API for CEDPs-compliant logging as described in Section 2, “Logging”.
As of 4.2.1, the Globus Toolkit provides system administration logs that are CEDPs best practices compliant.
To enable CEDPS logging, pass the -log PATH parameter to the globus-wsc-container program.
For more details on the CEDPS Logging format, including descriptions of reserved name-value pairs, see http://cedps.net/index.php/LoggingBestPractices:
The sample log file contains many log entries for various scenarios in the C WS container.
Table of Contents
For a list of common errors in GT, see Error Codes.
Table 12.1. C WS A&A Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
ERROR: Couldn't read user key: Bad passphrase key file location: /Users/bester/.globus/userkey.pem globus_credential: Error reading user credential: Can't read credential's private key from PEM OpenSSL Error: pem_lib.c:423: in library: PEM routines, function PEM_do_header: bad decrypt OpenSSL Error: evp_enc.c:509: in library: digital envelope routines, function EVP_DecryptFinal: bad decrypt Use -debug for further information. | Unable to decrypt private key | Rerun grid-proxy-init with the correct password. |
globus_gsi_gssapi: Error with gss credential handle globus_credential: Valid credentials could not be found in any of the possible locations specified by the credential search order. Valid credentials could not be found in any of the possible locations specified by the credential search order. Attempt 1 globus_credential: Error reading host credential globus_sysconfig: Error with certificate filename globus_sysconfig: Error with certificate filename globus_sysconfig: File is not owned by current user: /etc/grid-security/hostcert.pem is not owned by current user Attempt 2 globus_credential: Error reading proxy credential globus_sysconfig: Could not find a valid proxy certificate file location globus_sysconfig: Error with key filename globus_sysconfig: File does not exist: /tmp/x509up_u501 is not a valid file Attempt 3 globus_credential: Error reading user credential globus_credential: Key is password protected: GSI does not currently support password protected private keys. OpenSSL Error: pem_lib.c:401: in library: PEM routines, function PEM_do_header: bad password read | No user proxy could be found |
|
globus_gsi_gssapi: Error with GSI credential
globus_gsi_gssapi: Error with gss credential handle
globus_credential: Error with credential: The proxy credential:
/tmp/x509up_u1499
with subject: /DC=org/DC=example/DC=grid/OU=People/CN=Joe
User/CN=1235439010
expired 44 minutes ago. | Proxy has expired. | Run grid-proxy-init to generate a new proxy. |
globus_xio: The GSI XIO driver failed to establish a secure connection. The failure occured during a handshake read. globus_xio: An end of file occurred | Communication disrupted during SSL handshake | Verify with the service administrator that your certificate is signed by a certificate authority that is trusted by the service. |
globus_gsi_gssapi: Unable to verify
remote side's credentials
globus_gsi_gssapi: Unable to verify remote side's credentials: Couldn't verify
the remote certificate
OpenSSL Error: s3_pkt.c:1052: in library: SSL routines, function
SSL3_READ_BYTES: sslv3 alert bad certificate SSL alert number 42
| Unable to verify remote certificate. Often a clock-synchronization problem where the service clock is behind that of the client. | Verify that the client and service hosts have accurate time of day clocks. Use a NTP daemon if possible. |
OpenSSL Error: s3_clnt.c:894: in
library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE:
certificate verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: The certificate is not yet valid: Cert with
subject: /DC=org/DC=example/DC=grid/OU=People/CN=Joe User/CN=464555355 is not
yet valid- check clock skew between hosts.
| Unable to verify remote certificate. Often a clock-synchronization problem where the client clock is behind that of the service. | Verify that the client and service hosts have accurate time of day clocks. Use a NTP daemon if possible. |
globus_gsi_callback_module: Error with signing policy globus_sysconfig: Error getting signing policy file globus_sysconfig: File does not exist: /etc/grid-security/certificates/2b0e42b2.signing_policy is not a valid file | The service's certificate is not trusted by the client | Determine if the certificate authority used by the server is worth trusting. If so, retrieve the CA certificate and signing policy and place them in the client's trusted certificate directory. |
globus_gsi_callback_module: Could not verify credential globus_gsi_callback_module: Error with signing policy globus_gsi_callback_module: Error in OLD GAA code: CA policy violation: <no reason given> | Service certificate is not trusted because the CA signing policy does not trust the CA to sign the subject name of the certificate. | Verify with the service administrator that the certificate is valid. Verify that the signing policy file is up-to-date |
Error: globus_soap_message_module: SOAP Fault Fault code: Client Fault string: globus_handler_ws_secure_message: Server Request handling failed globus_handler_ws_secure_message: Failed to verify the message: Unable to get Security header element from message attributes. | The client sent a request to a service which message security without properly invoking the security handlers | Invoke the client program with the WS-SecureMessage handler.
Typically this is done by add -m msg to the
command-line. |
Error: globus_soap_message_module: SOAP Fault
Fault code: Client
Fault string: globus_soap_message_module: Loaded message handlers do not
understand required header element:
{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}
Security | The client sent a request protected with message-level security but the server did not understand the required security headers | Disable WS-SecureMessage on the client |
See Section 9, “Associated standards for C WS A&A” for a list of associated standards.
C
P
- private key
The private part of a key pair. Depending on the type of certificate the key corresponds to it may typically be found in
$HOME/.globus/userkey.pem(for user certificates),/etc/grid-security/hostkey.pem(for host certificates) or/etc/grid-security/(for service certificates).<service>/<service>key.pemFor more information on possible private key locations see this.
- proxy certificate
A short lived certificate issued using a EEC. A proxy certificate typically has the same effective subject as the EEC that issued it and can thus be used in its place. GSI uses proxy certificates for single sign on and delegation of rights to other entities.
For more information about types of proxy certificates and their compatibility in different versions of GT, see http://dev.globus.org/wiki/Security/ProxyCertTypes.
- public key
The public part of a key pair used for cryptographic operations (e.g. signing, encrypting).