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 here. More information about the security descriptor can be found here.
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.
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 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 [link]
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).
Client side security is set up by either 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 for the two approaches:
Setting 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);
The descriptor file is defined by the following Client Security Descriptor Schema.
![[Note]](../../../../../docbook-images/note.gif) | Note |
|---|---|
If the client needs to use transport security, the following API must be used to register the Axis transport handler for "https":
import org.globus.axis.util.Util;
static {
Util.registerTransport();
}
|
Table 1. Client side security properties
| # | Feature | Description | Stub Configuration | Descriptor Configuration |
|---|---|---|---|---|
| 1 | WS-Security Username/Password | 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. | Descriptor settings are currently not available for username/password. |
| 2 | GSI Transport | Enable GSI Transport with specified message protection level. |
Property: org.globus.gsi.GSIConstants.GSI_TRANSPORT
Values equal one of the following:
|
Signature setting: <securityConfig xmlns="http://www.globus.org"> ... <GSITransport> <integrity/> </GSITransport> ... </securityConfig> Encryption setting: <securityConfig xmlns="http://www.globus.org"> ... <GSITransport> <privacy/> </GSITransport> ... </securityConfig> |
| 3 | GSI Secure Message | Enable GSI Secure Message with specified message protection level. |
Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG
Values equal one of the following:
You can set the SOAP Actor of the signed message using the |
Signature setting: <securityConfig xmlns="http://www.globus.org"> ... <GSISecureMessage> <integrity/> </GSISecureMessage> ... </securityConfig> Encryption setting: <securityConfig xmlns="http://www.globus.org"> ... <GSISecureMessage> <privacy/> </GSISecureMessage> ... </securityConfig> |
| 4 | GSI Secure Conversation | Enable GSI Secure Conversation with specified message protection level. |
Property: org.globus.wsrf.security.Constants.GSI_SEC_CONV
Values equal one of the following:
Furthermore, you can set the SOAP Actor of the GSI signed/encrypted
SOAP message by using the |
|
| 5 | Credentials | Allows for setting credentials for authentication. If not specified, the default user proxy is used. Please see the Security Library Compatibility Document for some hints on loading and managing different GSI credentials. |
Property: org.globus.axis.gsi.GSIConstants.GSI_CREDENTIALS
Value equals the Instance of | The credential can be specified either as: a) the path to a proxy file, or b) the path to a certificate and key file. Example for option (a): <securityConfig xmlns="http://www.globus.org"> ... <proxy-file value="proxyFile"/> ... </securityConfig>
Example for option (b): <securityConfig xmlns="http://www.globus.org"> ... <credential> <key-file value="keyFile"/> <cert-file value="certFile"/> </credential> ... </securityConfig>
|
| 6 | Delegation | 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:
|
Delegation can be configured using the element <delegation value="value"/>. It needs to be a subelement of <GSISecureConveration>. Currently the following values are supported:
Example: <securityConfig xmlns="http://www.globus.org"> ... <GSISecureConversation> <integrity/> <delegation value="limited"/> ... </GSISecureConversation> ... </securityConfig> Note: By default, if nothing is specified, no delegation is performed. |
| 7 | Anonymous authentication | 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:
|
Anonymous authentication can be configured as follows: <securityConfig xmlns="http://www.globus.org"> ... <GSISecureConversation> <integrity/> <anonymous/> ... </GSISecureConversation> ... </securityConfig> |
| 8 | Peer credentials | 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);
|
Peer credential file name can be configured as follows: <securityConfig xmlns="http://www.globus.org"> ... <GSISecureMessage> <integrity/> <peer-credentials value="fileName"/> ... </GSISecureMessage> ... </securityConfig> The fileName should be the path to the credential file. |
Configuration of service-side security settings can be achieved in two ways. The preferred way is to provide these settings in a security descriptor, although it is also possible to manipulate security settings via CoG properties.
- X509_USER_PROXY <path>, where <path> is the path of the proxy credential.
- X509_CERT_DIR <path>, where <path> is the path to a directory containing trusted, that is CA, certificates.
Note that the above environment variable does not supersede any settings provided in security descriptors.