Appendix A - Overview of Internet-based messaging

This appendix provides background information on Internet-based messaging to explain why security assertion messaging is only practical using the approach defined by the Liberty Alliance, Shibboleth, and OASIS.

Messaging is the process of exchanging information between web browsers, application systems, servers or services. A wide variety of mechanisms have been developed for exchanging messages, each offering different characteristics addressing different issues. For example, applications intended for use over internal networks differ from those suitable for use over the public Internet.

The major messaging systems are:

• email-based messaging
• browser-based messaging
• machine/application-based messaging.

Email- based messaging functionality

Email was arguably the first significant messaging application to use the Internet. It is a well-understood technology and an example of ‘store and forward’ messaging. An email message may be stored on a server for some period of time before being delivered. Historically, email messages were often passed between large numbers of servers before reaching their final destination. The broad reach of the Internet has allowed the majority of email messages to be directly delivered to the recipient’s email server. Email messaging uses the Simple Mail Transport Protocol (SMTP). This is a well-understood and documented protocol that allows one system to open a connection to the receiving server, determine that the recipient is valid, transmit the email and confirm that it was successfully received.

Email messaging suitability for security assertions

There is no guarantee that an email message will be successfully delivered within a certain timeframe, or even delivered at all. There is also no guarantee that an email message has been received or read by the recipient.

This means that email is not suitable for the exchange of security credentials and assertions. Consequently, while email is an excellent messaging format for exchanging electronic letters and documents, it is not suitable for real-time exchanges of information.

The New Zealand Government SEEMail system was designed to securely exchange email messages between SEEMail Gateway servers. Each server authenticates the identity of the other party using digital certificates. This means that email messages between government agencies cannot be intercepted or modified while in transit over the public Internet. However, SEEMail is still ‘store and forward’ technology and not suitable for the exchange of security credentials for a user wanting immediate access to a government agency website.

Browser-based messaging functionality

HTML over HTTP Messaging

A web browser session consists of a series of ‘real-time’ HTTP (Hyper Text Transfer Protocol) requests and responses. A HTTP request is often a request for a HTML (Hyper Text Mark-up Language) document (i.e. ‘GET /index.html’). The response from the destination web server is either the document itself or an error response if the requested document is not available.

HTTP requests and responses are exchanged ‘in the clear’ over the public Internet with no encryption or other data protection measures. While this exchange is suitable for publicly available information, it is not suitable for any exchange of sensitive information. Therefore, a higher level of security is needed if sensitive information is being exchanged. Examples of sensitive information include passwords, keys and credentials, personal health or financial information.

One solution to this problem is to employ SSL (Secure Sockets Layer) or its successor, TLS (Transport Layer Security) transport protocols to encrypt the connection. This is commonly known as ‘HTTPS’.

SSL or TLS transport protocols provide the browser and the web server with the ability to:

• verify the web address of the server matches its domain name
• verify the identity of the end user (optional)
• ensure the confidentiality of the information being exchanged
• ensure that information is not modified in transit (note that this excludes information residing in an end user’s browser on their PC).

HTTP requests and responses carry messages in various ways between the server and the browser either:

• as cookies
• as additional parameters to the URL request
• in the HTML document itself.

Cookies

Cookies are frequently used by websites to:

• maintain information about the state of a user’s session on that website
• allow websites to recognise repeat visitors allowing them to track and count users
• automatically log users in
• maintain knowledge of users’ preferences and customisations.

There are a number of issues associated with the use of cookies. Cookies are defined for a given domain or website. Browsers automatically present any cookies the user has used in past visits that match the domain or website being requested. This makes them unsuitable for maintaining state information across different domains or websites – an essential requirement for identity federation. The content of cookies can be openly read if they are not encrypted, which makes them unsuitable for the management of confidential information or security credentials.

URL Requests

URL requests can contain additional information useful for maintaining state information, such as key identifiers. However, it is relatively easy for a potential hacker to modify or “capture” a URL, for example, on a compromised PC. No confidential information should be exposed in the URL without a digital signature or similar security measures being used to verify the identity of the user and the integrity of the session.

AS2 over HTTP Messaging

Applicability Statement 2 (AS2) is an initiative developed to address some of the shortcomings of HTTP. The AS2 protocol was designed to send data securely and reliably across the public Internet. Each message is encrypted so that only the sender and the recipient can view the data. The message is digitally signed to ensure the identity of the sender, and the message is encrypted to ensure that it has not been altered in transit. AS2 has a number of shortcomings, including the cost of owning a static IP address (which makes it unsuitable for temporary dial-up Internet connections), the cost of the AS2 software, and the need for digital certificates (which limits its use to high volume transactions between applications not directly involving the end user).

Browser messaging suitability for security assertions

The advantage of browser-based messaging is that it is real-time. Any message exchanged between a server and a browser is guaranteed to be received almost immediately. This makes browser-based messaging more suitable than email-based messaging for the exchange of security assertion messages. Generally, browser-based messaging is suitable where the user needs to play a role in the messaging.

Machine / Application-based messaging

A number of mechanisms for exchanging messages directly between application systems have also been developed. Messaging is not instigated by a user working with email or a web browser. Instead, security assertion messages are transacted between applications and/or machines. Examples of such mechanisms include:

• ebXML
• SOAP
• Web Services.

ebXML

ebXML is a high quality messaging system, incorporating many ‘quality of service’ features that are not present in some other messaging systems such as email and browser-based messaging. ebXML has been designed as a replacement for EDI messaging over proprietary networks (e.g. EDIFACT, X12).

ebXML is an acronym for ‘Electronic Business using eXtensible Markup Language’, commonly known as ‘e-business XML’. ebXML consists of several XML technical specifications designed to provide electronic business information in an open XML-based infrastructure enabling interoperable, secure and consistent data exchange.

The ebXML standards define the various operations required to locate and use the applicable Web Service to securely and reliably perform a transaction over the Internet. The ebXML standards include support for features such as reliable delivery and non-repudiation, providing both parties with proof that a transaction occurred.

ebXML messages are formatted as XML documents and are transported between application systems via the agreed transport mechanism. SMTP (Simple Mail Transport Protocol) and HTTP (Hyper Text Transport Protocol) are commonly used transports.

SOAP

SOAP is a protocol for exchanging XML-based messages over the Internet or an Intranet, typically using HTTP.

The name ‘SOAP’ was originally an acronym for ‘Simple Object Access Protocol’, but the full name was dropped in version 1.2 of the SOAP specification as the focus of SOAP shifted from object access to object interoperability.

A SOAP message consists of an envelope containing an optional header and a message body. The header contains relevant information about the message. For example, a header can contain the date the message is sent, or authentication information. It is not required but, if present, must always be included at the top of the envelope.

The body of a SOAP message contains the actual message itself. This can take many forms, but is frequently a request for some action to be performed, or a request for information. The response to the request is also a SOAP message where the body of the message contains the information requested, or the result of the action to be performed.

Web Services

Web Services have added a new level of functionality to the Internet by offering a way to seamlessly integrate distributed applications. Applications can use the Web Services standards to use the functionality offered by another application located elsewhere, without the need for deep integration between the applications. A Web Service request is encoded as an XML document in either SOAP or XML-RPC format. The request and the response are transported between the requesting application and the service provider over the HTTP(S) protocol.

This approach has many benefits:

• Interoperability between various software applications running on different platforms.
• Web Services can work through many common firewall security measures using HTTP.
• Services from different companies can be combined to provide an integrated service.

There are also a number of drawbacks:

• Poor support for transactions.
• Poor performance when compared to other distributed computing approaches such as RMI, CORBA or DCOM.
• It is relatively new in the developer community compared to RMI, CORBA or DCOM.

Machine/application-based messaging suitability for security assertions

Only certain messaging formats and transport protocols are suitable for the exchange of security assertions. This is due to a variety of factors:

• Guaranteed delivery within a certain period of time
• User or application instigated
• Authentication of either party
• Non reliance on proprietary solutions.

Web Services and SOAP and, in some circumstances, XML-RPC structures are suitable for server-to-server or application-to-application messaging, particularly in supporting higher level security requirements.

However, the higher cost of implementing ebXML makes it more suited to the exchange of application level transactional data rather that the real-time exchange of security credentials and assertions.