Standards Support

RESTful Services

REST
HTTP & HTTPs
JSON
JSONPath
Native Javascript
RSS & ATOM
OAuth 1.0a & 2.0
OpenId 2.0

SOAP Services

SOAP and XML
Attachments
SOAP 1.1 Request Optional Response HTTP Binding
WS-Security
WS-Security Policy
WS-MetadataExchange
WS-Addressing
WS-Addressing 1.0 - WSDL Binding
WS-Routing
WS-Inspection
WS-ReliableMessaging
WS-I Basic Profile
WS-I Basic Security Profile

General Security Standards

HTTPs Mutual
X.509 PKI
Security Assertions Markup Language
XML Encryption
XML Signature
HMAC
RSA
SHA-1
SHA-2

Infrastructure Services

XSLT
WS-Policy
UDDI
WS-I Attachments Profile
XPath
Transparent Pass-through of Non-Mediated Messages

Restful Services

REST
REST isn’t strictly a “standard”, but it is generally considered to be a service pattern commonly used for APIs.  Our products provide extensive first order support for RESTful, SOAP, XML-RPC and POX Services, with comprehensive mediation capabilities between them.

HTTP & HTTPS
The API Gateway provides high-performance http and https processing supporting a comprehensive set of the verbs required by RESTful services, including GET, POST, PUT, DELETE and OPTIONS.

JSON
The products support both JSON and XML natively, with the ability to mediate seamlessly between the two (typically based on Accept and Content-Type headers).

JSONPath
The products support JSONPath for fast finding and manipulation of JSON documents in flight.

Native Javascript
The products support Javascript natively for easy manipulation of JSON documents and message headers.

RSS and Atom
The Network Director intermediary provides a number of mediation services for feed and syndication formats. Consumption and delivery support, as well as aggregation of items from multiple sources can occur across and between multiple standards (i.e. RSS 0.94 items and Atom 0.3 items can be aggregated into a single logical feed and re-transmitted as Atom 1.0).

Along with email and WS-Eventing subscriptions, alerts and notifications can also be created and consumed in any of the syndication formats listed below.

Supported Formats:

  • RSS 0.9
  • RSS 0.92
  • RSS 0.93
  • RSS 0.94
  • RSS 1.0
  • RSS 2.0
  • Atom 0.3
  • Atom 1.0

OAuth 1.0a and 2.0
The products provide a comprehensive OAuth solution with an OAuth server that can expose multiple OAuth providers, act as a token server, resource server and authorization server, as well as enabling the enforcement and implementation of OAuth for APIs and consumers.

OpenId 2.0
The products include a security token server than can expose existing enterprise identity systems via an array of authentication services including SAML and OpenId.

SOAP Services

SOAP and XML
The Service Manager intermediaries (Agent, Delegate, and Network Director) are capable of receiving, routing and emitting SOAP messages conformant to the SOAP 1.1 or SOAP 1.2 specifications, relevant parts of the WS-I basic profiles (Simple SOAP Binding Profile Version 1.0, etc.), and non-disruptive to canonicalization transformations (Canonical XML 1.0, Exclusive XML Canonicalization Version 1.0, SOAP 1.2 Message Normalization) used in common message signature algorithms.

Non SOAP messages (aka XML-over-HTTP or plain-old XML [POX]) can also be routed (XML 1.0 and 1.1, XML Schema 1.0 and 1.1 are supported).

Attachments
The Service Manager intermediaries (Agent, Delegate, and Network Director) provide transparent pass-through of message attachments. Retransmission of mediated messages will emit transformed messages with identical or specification equivalent attachment descriptions, references, and attachment encodings. This also includes indirection models like Resource Representation SOAP Header Block et al.

SOAP 1.1 Request Optional Response HTTP Binding
The Network Director and Agent intermediaries provide out-of-the-box support for the SOAP 1.1 Request Optional Response HTTP Binding. If a SOAP 1.1 message arrives at either type of endpoint over an HTTP transport, and the SOAP envelope header contains a WS-Addressing header of type ReplyTo or From, and the header value is non-anonymous, the Network Director or Agent will follow the Optional Response HTTP Binding specification and return a 202 HTTP status code with no payload.

WS-Security
WS-Security 1.0 and 1.1 is supported in both Service Manager Policy Implementation and Enforcements Points (Agent, Delegate, and Network Director). The aspects of WS-Security that will be enforced and/or implemented at runtime are configured as policies in the Service Manager console. The configurable aspects include the following:

  • Encryption
  • Digital Signature
  • Timestamp
  • Username Token Profile
  • SAML Token Profile
  • X.509 Token Profile
  • Kerberos Token Profile

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2002/07/secext
  • http://schemas.xmlsoap.org/ws/2002/04/secext
  • http://schemas.xmlsoap.org/ws/2003/06/secext
  • http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

WS-Security Policy
Responses to WS-MetadataExchange requests for a dialect of WS-Policy will include WS-Security Policy assertions describing WS-Security capabilities (i.e. acceptable WS-Security token types, etc.).

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2002/12/secext
  • http://specs.xmlsoap.org/ws/2005/07/securitypolicy/
  • http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

WS-MetadataExchange
The Network Director intermediary can respond to WS-MetadataExchange requests for WS-Policy, WSIL, and WSDL dialects for any virtual or proxied service. The capbilities and metadata expressed in each of the dialect specific responses are those of the mediated, virtual service interface, regardless of MEX support at the original, proxied endpoint.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2004/09/mex

WS-Addressing
The Service Mangaer intermediaries (Delegate, Agent, and Network Director) allow for asynchronous dispatch and receipt via WS-Addressing. Dynamic routing and next-hop transmission is also supported, again via WS-Addressing. WS-Addressing headers are also used (or suppressed) in Message Exchange Pattern (MEP) mediation scenarios. The WS-Addressing infoset is realized concretely via the WS-A SOAP binding.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2003/03/addressing
  • http://schemas.xmlsoap.org/ws/2004/03/addressing
  • http://schemas.xmlsoap.org/ws/2004/08/addressing
  • http://www.w3.org/2004/12/addressing
  • http://www.w3.org/2005/02/addressing
  • http://www.w3.org/2005/03/addressing
  • http://www.w3.org/2005/08/addressing

WS-Addressing 1.0 - WSDL Binding
By default, WSDLs consumed through Service Manager’s Delegate, Agent and Network Director Intermediaries will not decorate the basic service description with WS-Addressing attachments or bindings. This is done in order to guarantee that the WSDL emitted by default is compatible with all SOAP stacks and toolkits out of the box. However, for enterprises using toolkits or stacks that are able to consume and generate code form WS-Addressing elements in the WSDL, Delegate, Agent and Network Director Intermediaries provides an “addHeaders” directive to force decoration of the WSDL with the WS-Addressing bindings. For stacks capable of consuming and emitting the operation bound WS-Addressing Action header, generic virtual endpoints are provided to enable simple configuration and loose coupling with concrete service implementations.

WS-Routing
For legacy systems and SOAP stacks that do not support WS-Addressing specification, the Network Director and Agent intermediaries provide routing and mediation for the legacy WS-Routing specification.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2002/04/rp
  • http://schemas.xmlsoap.org/rp/

WS-Inspection
For any virtual endpoint deployed in the Network Director or Agent intermediaries, an HTTP GET request to the virtual URL, appended with a “?wsil” or “?WSIL” query string, will return a WS-Inspection document for that service. Alternatively, the WSIL document can be retrieved via a WS-MetadataExchange request to the endpoint for the WS-Inspection dialect.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2001/10/inspection/

WS-ReliableMessaging
The service manager intermediaries (Network Director, Agent, and Delegate) can participate in a Web Services Reliable Messaging exchange either as a client or a receiver. Alternatively, the Network Director intermediary can bridge non-WS-RM reliable exchanges with WS-RM exchanges.

Furthermore, the Network Director intermediary can mediate between any two of the WS-RM specification versions listed below.

Configuration of the WS-RM capabilities is done via WS-RM policy assertions specifying the behavior of the exchange (i.e. delivery assurance, sequence expiry, etc.).

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2003/03/rm
  • http://schemas.xmlsoap.org/ws/2004/03/rm
  • http://schemas.xmlsoap.org/ws/2004/08/rm
  • http://schemas.xmlsoap.org/ws/2005/02/rm
  • http://docs.oasis-open.org/ws-rx/wsrm/200602
  • http://docs.oasis-open.org/ws-rx/wsrm/200510
  • http://docs.oasis-open.org/ws-rx/wsrm/200608

WS-I Basic Profile
All Service Manager Policy Implementation and Policy Enforcement Points (Delegate, Agent and Network Director Intermediaries) can process messages that conform to the WS-I Basic Profile versions 1.0 and 1.1. Any message, such as a fault message that is generated by a Policy Implementation or Policy Enforcement point will conform to the WS-I Basic Profile. Service Manager can also validate that created or imported WSDL documents conform to the WS-I Basic Profile.

WS-I Basic Security Profile
Service Manager provides a flexible policy model for securing SOAP messages using WS-Security. These policies can be assembled to ensure compliance with the Core WS-I Basic Security Profile as well as the following related profiles:

  • Username Token
  • X.509 Certificate Token
  • Kerberos Token
  • SAML Token

General Security Standards

HTTPs Mutual
The products support HTTPs Mutual to authenticate applications and users using X.509 certificates.

X.509 PKI
The products provide a built-in X.509 Certificate Authority that can act as a root or subordinate CA.  They can issue and distribute public/private key pairs and certificates, and manages expiry, revocation and CRL checking.

Security Assertions Markup Language
The Network Director, Delegate, and Agent intermediaries support SAML 1.0 and 1.1. For receiving intermediaries, the following confirmation methods are supported: “Holder of Key” and “Sender Vouches” are supported, though PKI resources must be configured prior to enabling SAML Assertion support.

XML Encryption
All Service Manager Policy Implementation and Policy Enforcement Points (Delegate, Agent and Network Director Intermediaries) can encrypt and decrypt message content based on the XML Encryption specification. The configuration of the use of XML Encryption is specified through policies. This support is independent of WS-Security.

XML Signature
All Service Manager Policy Implementation and Policy Enforcement Points (Delegate, Agent and Network Director Intermediaries) can sign message content and verify message signatures based on the XML Signature specification. The configuration of the use of XML Signature is specified through policies. This support is independent of WS-Security.

HMAC Header Signature
Network Director supports the authentication of consumer applications using an HMAC signed Authorization header.

RSA Key Generation and Management
The products support the generation, management and distribution of RSA public/private keypairs, and the encryption, decryption, signing, and signature verification of messages, message elements, and headers using RSA keys.

SHA-1 Key Generation and Management
The products support the generation, management and distribution of SHA-1 keys, and the encryption and decryption of messages, message elements and headers using these SHA-1 keys.

SHA-2 Key Generation and Management
The products support the generation, management and distribution of SHA-2 keys (256bit and 512bit), and the encryption and decryption of messages, message elements and headers using these SHA-2 keys.

Infrastructure Standards

XSLT
The Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) support transformations over the entire message.

Policies are re-evaluated post transformation in case the message content change meets new policy enforcement criteria.

Both XSLT 1.0 and 1.1 style sheets are supported by the Service Manager XSLT engine.

WS-Policy
Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) provide two means of generating consumable WS-Policy serializations. The first is via WS-MetadataExchange requests - for any virtual or proxied service, sending a WS-Policy dialect request to the service endpoint will return the WS-Policy assertions germane to that service interface.  The second means is consuming applicable WS-Policy attachments in the WSDL served up from the intermediary. 

Supported Namespaces

  • http://schemas.xmlsoap.org/ws/2004/09/policy
  • http://www.w3.org/2006/07/ws-policy

UDDI
Service Manager deploys with a UDDI v2 and v3 (3.02) compatible registry. All services managed by Service Manager are stored in the registry. Customers can categorize and search those services using customer-defined categorization schemes.

WS-I Attachments Profile
All Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) can process messages that contain attachments as defined by the WS-I Attachments Profile. Service Manager can also validate that created or imported WSDL documents conform to the WS-I Attachments Profile.

XPath
All Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) can process messages that contain attachments as defined by the WS-I Attachments Profile. Service Manager can also validate that created or imported WSDL documents conform to the WS-I Attachments Profile.

Transparent Pass-through of Non-Mediated Messages
In situations where a dialect or specification is not explicitly understood by the intermediary, then the message model will be passed through without interference. For instance, while Service Manager Intermediaries do not provide domain specific transformations (other than the enveloping and metadata message aspects) for specifications such as WS-DM, ebXML, etc.