Session authentication protocol for web services - Applications and ...

Session Authentication Protocol for Web Services Satoshi Hada and Hiroshi Maruyama IBM Research, Tokyo Research Laboratory 1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242-8502, Japan {satoshih, maruyama}@jp.ibm.com Abstract The recent development of Web services allows composing a business flow by combining business processes provided by separate business via the Internet. One instance of a business flow can be executed by multiple service instances of the Web services of the participating business entities. At the same time, one business entity may have multiple services and service instances serving many different customers simultaneously. To establish trust relationships among these service instances, a new set of security protocols is necessary. We present a design for a session-oriented, multi-party authentication protocol based on standard Web services technologies such as SOAP, XMLSignature/Encryption, and SOAP-DSIG. The protocol consists of a message authentication protocol and a session management protocol.

1. Introduction Web services technology allows companies, or more generally business entities, to externalize their business processes that can be utilized by other business entities. In typical scenarios described by the service composition language proposals such as WSFL [8] and XLANG [10], multiple Web services can be combined to form a business flow. For example, a procurement business flow may involve a buyer service, a supplier service, and a shipper service. Once a service receives an initial request to participate in a business flow, the service usually allocates a service instance to handle the requests that are pertinent to this particular business flow. Thus, one business flow instance is composed of a set of service instances participating in the flow. Because one Web service may have multiple service instances, each of which may be serving a different customer, it is important to ensure that the business flow participants are communicating with the service instances that participate in the same business flow. Although it is generally understood that Web ser-

vices are addressed by their URLs in most cases, at this time how to address service instances is still unclear. Sometimes it is implicit when the underlying communication channel is stateful (e.g., HTTP using cookies). In this paper, we present a message-layer protocol that authenticates service instances for multi-party business flow scenarios. This protocol is based on standard Web services technologies such as SOAP [5], XMLSignature/Encryption [12, 11], and SOAP-DSIG [6]. In Section 2, we illustrate the requirements by using a motivating example and show the limitations of the existing security protocols. Then we present our solution in the following two sections. Our protocol consists of two parts: a message authentication protocol, discussed in Section 3, which authenticates the session participants once a session secret is shared among them, and the session management protocol, discussed in Section 4, which enables the participants to share the session secret. Section 5 presents two scenarios showing how these protocols are used to establish a session.

2. Motivation 2.1. Motivating Example Figure 1 shows a typical business flow for purchasing goods. In the figure, services are represented by squares and service instances by circles. The buyer process, which is an instance of a buying application, sends a purchase order to a supplier. The supplier starts a new service instance (”Supplier instance #123” in the figure) that handles this particular request. The supplier selects an appropriate shipping company to fulfill this purchase order based on price, availability, etc., and sends a shipment request to the selected shipper. The shipper creates its own service instance to handle this request. The buyer then receives a notification from the shipper that the ordered goods are being shipped. The supplier and the shipper need to retain their service instances until the whole transaction is completed in order to

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

keep each other updated on the status of the transaction and to take appropriate actions should any of the processes fail.

“B uy”, Sid=99 B uyer

Supplier Supplier Instance #123

B uyer instance #672

scribed above is an example of session. We call the Web service instances that require access to the shared context participants in the session or session participants. As we have seen in our motivating example, the participants are normally not business entities, Internet hosts, or even Web services. We also have to distinguish multiple instances of the same Web services in order to properly authenticate participants.

“D elegate Shipm ent”, Sid=99

2.3. Limitations of Existing Security Protocols

Shipper “Shipm ent notice”, Sid=99

Shipper instance #456

Figure 1. Motivating Example Note that in this scenario, the buyer process may receive a notification from a shipper who is not known to the buyer because the shipper was dynamically chosen by the supplier. If the shipping service instance is asking for the buyer’s private information such as a telephone number, can the buyer trust it? In many cases, the buyer can trust the identity of the sender as a business. For example, the notification may be sent over an SSL/TLS connection with mutual authentication. The buyer may receive a certificate for a subject named ”Shipping Service, XYZ Trading, Co.” issued by some commercial CA. This guarantees that the notification was actually from this company. However, this does not necessarily mean that this company has something to do with the buyer’s particular purchase order. In addition, the buyer must also know that the shipping service instance has legitimately been delegated the responsibility for shipping of the goods on the purchase order identified by the supplier’s service instance #123. The shipping service may have hundreds of service instances, each of which are participating in different transactions serving different companies. If the shipping service is very flexible and allows configuring many different forms of notification, someone might be able to confuse such a configuration so that the service instance generates a false notification to an arbitrary user. Or this might also be caused unintentionally by software bugs or human errors. Therefore our goal for the protocol presented in this paper is to authenticate session participants without prior knowledge of all parties participating in the session.

2.2. Session and Participants We define a session as a series of operations executed by Web service instances that need to share a common state. An instance used for the purchase order business flow de-

There are a number of security protocols available for securing communications on the Internet. IPSec [1] can authenticate hosts on either side of the communication. S/MIME [3] can authenticate the sender, normally a human user, by means of X.509 certificates. Both protocols assume that the communicating parties have persistent identities verifiable by long-lived keys such as X.509 certificates. Thus, these protocols cannot be directly applied to authenticating the participants of dynamically generated sessions. SSL/TLS [7] has a concept of a session. Once a session negotiation is completed, the participants share the same session secret and thus, they can authenticate the following messages using the session key. If the dynamically created session secret is given to each service instance, it can be used to authenticate the session participants. Unfortunately, however, SSL/TLS is a two-party protocol and thus, it is not designed to share the same communication channel among multiple parties. A Kerberos ticket can be used to represent a session [2]. Once a service receives a ticket, it is possible to create a new instance and assign the ticket to the created instance, so that the following communication can trust the authenticity of the service instance. In addition, the forwardable bit in a ticket allows forwarding a ticket to a third party, thus delegating a grant of authority. The forwarded ticket can be used to prove that the entity has the same behavioral rights as the forwarder. However, this is still based on a two-party communication model because a ticket (and its corresponding key) is to be generated for each pair of communicating entities. We need to extend this concept to deal with multiple parties. Our protocol design does not preclude the use of these existing protocols as the underlying means of securing the communication channels. Some of the features described in the following section are optional if the underlying transport protocol provides appropriate protection against the threats for which the features are designed.

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

3. The Message Authentication Protocol 3.1. Overview In our protocol design, we assume that a service is a persistent, long-lived entity that has a globally known identifier such as a URL and a associated public-key certificate. In addition, we assume that an appropriate public-key infrastructure (PKI) is in place for authenticating services. On the other hand, a service instance is a transient, short-lived entity that does not usually have a global identifier. We do not assume any particular means of delivering messages to a service instance within a host (e.g., it could be a responsibility of an application program). Corresponding to the two types of communicating entity (service and service instance), this section describes two levels of message authentication protocols used in the session management protocol. One is called a session authenticator and the other is called a service authenticator. Conceptually, the session authenticator protocol allows service instances to mutually verify their transient membership in a session while the service authenticator protocol allows services to mutually verify their permanent identities. The session authenticator is used to ensure that the service instance that sent a message is participating in a particular session, i.e., that the service instance is a valid participant of the session . This is done by appending a message authentication code (MAC) to a transmitted SOAP envelope using a session key. The session key used to compute MACs is derived from a common session secret shared by all the session participants via the session management protocol, which is discussed in Section 4 1 . Note that the session authenticator authenticates session membership only; by itself, the session authenticator does not guarantee the real identity of the sending service instance, because the sender could be any of the current session participants. The service authenticator guarantees the identity of the message sender as a service. It is based on the permanent identity of the sending service, which is assured by the underlying PKI. If messages are sent over a secure transport protocol such as SSL/TLS that is configured to authenticate the services on the both ends of the communication, the service authenticator might be unnecessary. As we discussed, we do not directly deal with the issue of authenticating the identity of the sending service instance, because we do not assume there are global identifiers for service instances. Depending on application requirements, however, the service authenticator may be combined with the session authenticator to give a reasonable level of assurance of the identity of the sending service instance. 1 This means that the session key must not be the same as the session secret. This paper does not specify any particular way for deriving it.

Before describing the two authenticators in more detail, we summarize the building blocks used. PKI: As described above, we use a PKI so that each service is identified by a public-key certificate. We also assume that certificates are distributed or exchanged between services in an “out of band” manner (e.g. via a UDDI registry). SOAP-DSIG: We use the SOAP security extensions: digital signature (SOAP-DSIG) [6] to authenticate SOAP envelopes. It provides a general mechanism for signing/validating SOAP envelopes based on XML-Signature [12]. The mechanism can also be used to append MAC’s to SOAP envelopes. XML-Encryption: We use the XML-Encryption [11] to encrypt/decrypt SOAP envelopes. XML-Encryption provides a mechanism for encrypting/decrypting arbitrary XML documents. In this paper, we do not describe how to apply it to encrypt/decrypt SOAP envelopes in detail but one proposal is found in IBM’s Web Services Toolkit [9].

3.2. Session Authenticator Now we describe the session authenticator as a protocol for a sending service instance to send a SOAP envelope to a receiving service instance, where the sending service instance uses a session key to append a MAC to a SOAP envelope as follows: Step 1. A sending service instance prepares a SOAP envelope that it wants to send to a receiving service instance in a session. At this point, the receiving service instance may not yet have the session key. Step 2. Optionally, the sending service instance uses XMLEncryption to encrypt the SOAP envelope for confidentiality. Step 3. The sending service instance adds authentication information to the SOAP header, which we call an authentication header entry (the element in the example below). It consists of the session handle, a message identifier, the sending service’s certificate, and the receiving service’s certificate. The use of the message identifier is essential to avoid replay attacks and its uniqueness must be guaranteed in the session. The session handle identifies the session through a combination of a session authority and a session identifier. The session identifier is unique with respect to the session authority. The session handle may also include other information such as an expiration date. Step 4. The sending service instance uses the SOAP-DSIG to apply a MAC to the entire SOAP envelope under the session key, using the enveloped signature transform defined in the XML-Signature [12]. Then it sends the MACed SOAP envelope to the receiving service. Step 5. On receiving the MACed SOAP envelope, the receiving service instance checks whether it already has a

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

valid session secret for the session. If not, it obtains the current session secret through the Session Management Protocol described in Section 4. Step 6. Having the session key, the receiving service instance validates the MAC and the uniqueness of the message identifier. It accepts the SOAP envelope only when the validation succeeds. Step 7. If the SOAP envelope was encrypted, the receiving service instance decrypts it. Step 8. Now the receiving service instance receives the authenticated message and the session handle. As described above, the SOAP envelope to be sent may be encrypted using XML-Encryption before being MACed. We omit the detailed description here since this paper focuses on the authentication issue. Here is an example of the above steps. First of all, the sending service instance prepares a SOAP envelope that it wants to send: IBM

The instance then inserts an authentication header entry (represented by the element) including the session handle, a message identifier, the sending service’s certificate, and the receiving service’s certificate: 3A247BCD77DE9057 The certificate itself or a link to it. The certificate itself or a link to it. IBM



The sending service instance uses the SOAP-DSIG signature generation procedure to MAC the entire SOAP envelope: A element should be put here as a result of MACing the entire SOAP envelope. The element in this signature may reference the shared session key. 3A247BCD77DE9057 The certificate itself or a link to it. The certificate itself or a link to it. IBM

Recall that the session authenticator does not authenticate the identity of the sending service instance. The sending service instance could be any of the current participants. We assume that the application provides an appropriate means to distinguish individual participants if necessary. Once a standard way of identifying services instances is agreed upon, such a scheme should be used. On the other hand, authenticating the sending service is often required. If the underlying transport does not provide the required level of authentication, the service authenticator described next can be used.

3.3. Service Authenticator We describe the service authenticator as a protocol for a sending Web service to send a SOAP envelope to a receiving service. The sending Web service uses its own private key to sign the SOAP envelope as follows:

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

Step 1. The sending service prepares a SOAP envelope that it wants to send to a receiving service. Step 2. Insert an authentication header entry (See the example below). This step may be skipped when the authentication header entry is already present (e.g., associated with a session authenticator). However, we stress that the message identifier in the authentication header entry must be unique across different sessions. This is required for avoiding replay attacks across different sessions. Step 3. The sending service uses the SOAP-DSIG to sign the entire SOAP envelope via the enveloped signature transform defined in the XML-Signature. Step 4. Optionally, the sending service may encrypt the signed envelope for confidentiality using XML-Encryption. Step 5. The signed (and optionally encrypted) SOAP envelope is sent to the receiving service. Step 6. On receiving the signed SOAP envelope, the receiving service decrypts the envelope if required and validates the signature and the uniqueness of the message identifier. Also, it verifies that the certificate specified as the receiving service’s certificate is its own certificate. It accepts the SOAP envelope as a message from the sending service only when both the signature validation and the certification verification succeed. Now we give an example, where the service authenticator is used independently of the session authenticator. First, the sending service prepares a SOAP envelope, using the same SOAP envelope as above. Then a header entry including a message identifier is added, along with the certificates of the sending service and the receiving service: The certificate itself or a link to it. The certificate itself or a link to it. IBM

The sending service uses the SOAP-DSIG digital signature generation procedure to sign the entire SOAP envelope.

A element should be put here as a result of signing the entire envelope. The element in this signature may reference the one in the element. The certificate itself or a link to it. The certificate itself or a link to it. IBM

4. The Session Management Protocol This section describes the session management protocol, assuming that the messages will be sent using a message authentication protocol such as the service authenticator and SSL/TLS.

4.1. Overview The overview of the session management protocol is shown in Figure 2. We assume that there is a Session Authority (SA) that manages sessions. As we will discuss later, an SA can either be a separate entity or the initiator of the session filling an SA role. An SA is responsible for: (1)assigning session IDs, (2)creating session secrets, (3)maintaining the status information for each session and keeping the participants informed of the status, and (4)shutting down sessions. A session is created by sending a StartSession request to the SA. There are two ways for a participant to join the created session. One is to ask the SA by sending a JoinSession request. If it is permitted according to the admission policy set by the initiator and the SA, the participant receives the session secret. The alternative way is for a participant to forward the session secret to the receiving participant. This allows for the ”offline” scenario that we will describe later.

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

SA StartSession JoinSession E ndSession Q uerySession

N otifySession

Forw ardSession Participant

Participant

Figure 2. Session Protocol

4.2. Participants - SA Operations First we describe the protocol used between a participant and an SA. An SA acts as a SOAP-based Web service, so its interface can be naturally described in WSDL. Because of space limitations, however, we show only the skeletons of the messages exchanged between an SA and a participant instead of the full WSDL definitions. 4.2.1 StartSession The message is used for creating a new session. The initiator can optionally send a set of policies that control admission to the session. The details of the admission policy are beyond the scope of this paper.

3A247BCD77DE9057

If the SA decides to approve the request to join the session based on the admission policy, it returns the session secret. This message needs to be protected appropriately. Success HctvEowak92lZ6xF2pMwsAjNDfY=

4.2.3 EndSession A participant can request the shutting down of a session. This message needs to be authenticated by the session authenticator protocol described in the previous section. 3A247BCD77DE9057

If the admission policy allows the requester to shut down the session, the SA shuts down the session and notifies all the participants.

...

Success

The reply to a command contains the session handle and the session secret that were created for the session. Note that this message must be protected by an appropriate method (such as the use of SSL/TLS as the transport protocol).

4.2.4 QuerySession

Success 3A247BCD77DE9057 HctvEowak92lZ6xF2pMwsAjNDfY=

4.2.2 JoinSession A would-be participant can ask to join a session by sending a message to the SA of that session.

An SA keeps track of the information about a session. The information include the current set of participants and the time the session was initiated. The protocol is designed to allow for handling other information pertinent to the session. 3A247BCD77DE9057

The session status information is not specified in this paper. However, the information is defined as an extensible element. Success ...

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

4.2.5 NotifySession An SA should be capable of notifying its participants of changes in the session status. In contrast to the previous messages, which are all request/response, this message is one-way. The most important change to be notified of is the shutdown of the session. This message can also be used for renewing a session secret before it expires. 3A247BCD77DE9057 ...

message to the SA, and the other is by receiving a message. We present scenarios for both cases. Again, it is implicit that messages are sent using a message authentication protocol such as the service authenticator and SSL/TLS as required. However, when the session authenticator must be used in combination with such a underlying authentication protocol, it will be explicitly specified.

5.1. Online Session Management The session management via JoinSession messages is shown in Figure 3. In this case, session admission is done by the SA. SA

4.3. Participants - Participants Message

6.Session Secret

1.StartSession

4.3.1 ForwardSession R equester

When one participant wishes to invite another party to participate in the session, they can do so by sending a message to the new participant. The forwarder must conform to the admission policy when forwarding a session. The forwarder also needs to trust that the forwardee will conform to the policy. This message needs to be protected from eavesdroppers by an appropriate means because this message contains the session secret. 3A247BCD77DE9057 HctvEowak92lZ6xF2pMwsAjNDfY= ... ...

The details of the admission policy are not presented here but the policy must be digitally signed by the SA if the policy needs to be protected from unauthorized modifications. Also if the forwardee needs to know the forwarding path, the forwarding path from the original requester to the forwarder must be included in the message.

5. Session Management Scenarios As mentioned above, there are two ways for a participant to join a session. One is through a

2. Session Secret

5. JoinSession Service instance

Service#1 3.M essage over Session 9.JoinSession A uthenticator 10.Session Secret

4.Spaw n Instance

Service#2 11.M essage over Session A uthenticator

7.M essage over Session A uthenticator

8.Spaw n Instance

Figure 3. Online Session Management First, the requester initiates a session by sending a message to the SA (Step 1). The requester will receive a session secret in the reply to that message (Step 2). Then the requester sends an application message to a Web service (denoted ”Service#1”) over the session authenticator (Step 3). On receiving the message, the service is given the session handle and asked to join the session. Next the service creates a new service instance and transfers control (Step 4) to the instance. Then it sends a message to the SA (Step 5) using the access point for the SA that was provided in the session handle, and receives the session secret (Step 6). Now the service instance has the session secret so it authenticates the received message and obtains the payload. If the service instance needs to delegate its operation to some other service, it can send a message to another Web service (denoted ”Service#2”) using the session authenticator (Step 7). The same process happens in the second service provider (Steps 8-10) and the service instance of the second service provider now has the session secret. This service instance can send a message to the original requester using the session authenticator (with the same session secret) so that the

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE

requester can be sure that the second service instance is a legitimate session participant. In our protocol, all the session participants share the same session secret. This means that all the participants must trust each other to behave faithfully once they are admitted to the session. Malicious service instances cannot pretend to be legitimate participants because they do not have the session secret. Note that there is no restriction on who fills the SA role in the scenario. In particular, it is possible that the requester is also the SA. In this case, the initial message can be a local call. Also it is easy for the requester to track the progress of the transaction because it will know who has participated in the session through the messages.

5.2. Offline Session Management The online scenario requires extra communication in order to acquire the session secret. By using the ForwardSession message, this extra communication can be eliminated. Figure 4 shows this ”offline” scenario. SA 1. StartSession 2.Session Secret

4. Spaw n Instance

R equester

3. Forw ardSession

Service#1

Service instance

5.Forw ardSession 7.M essage over Session A uthenticator

Service#2 6.Spaw n Instance

Figure 4. Offline Session Management First, the requester acquires a session as in the online scenario (Steps 1-2). Then it forwards the session secret in a ForwardSession message to Web service #1 (Step 3). It creates a new service instance and sends the ForwardSession message (Step 4). The newly created instance now has the session secret. If it needs to further delegate the session to a third Web service and it is allowed to do so by the admission policy, it can re-forward the session (Step 5) to Web service #2. The second Web service spawns a new instance (Step 6) which is now capable of sending an application message to any of the session participants using the session authenticator (Step 7). Again, the requester can act as the SA in this scenario. If it does, and if we piggyback the ForwardSession and

the NotifySession messages on the application messages, there will be very little communication overhead for session management. The downside of this offline scenario is that the list of the session participants cannot always be maintained accurately.

6. Conclusion We have presented the design of a multi-party, sessionoriented protocol that enables authenticating service instances that participate in a session. The syntax presented here is for discussion purposes only. There are a few related standards that may be used for protocols such as this. In particular, SAML [4] should be used whenever appropriate (e.g., for session handles, policies, etc.) once it has been approved as a standard. There are a number of related issues in the areas of session control of Web services. An incomplete list would include things such as: (1)How to address service instances and how to deliver messages to them? (2)How to identify sessions and how to manage them? (3)Session tear down strategies. (e.g., When should local states about a session be expired?) (4)Whether transaction semantics is necessary for sessions? We hope that this paper stimulates discussion in this exciting area.

References [1] IETF, IP Security Protocol, http://www.ietf.org/html.charters/ipseccharter.html. [2] IETF, Kerberos, charter.html.

http://www.ietf.org/html.charters/krb-wg-

[3] IETF, S/MIME Version 3 Message Specification, IETF RFC 2633. [4] OASIS, Security Assertion Markup Language, http://www.oasisopen.org/committees/security/. [5] W3C NOTE, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/SOAP/ (The latest version is available at http://www.w3.org/TR/soap12/). [6] W3C NOTE, SOAP Security Extensions: http://www.w3.org/TR/SOAP-dsig.

Digital Signature,

[7] IETF, The TLS Protocol Version 1.0, IETF RFC 2246. [8] IBM, Web Services Flow Language (WSFL 1.0), http://www4.ibm.com/software/solutions/webservices/pdf/WPS.pdf. [9] IBM alphaWorks, Web Services http://www.alphaworks.ibm.com/tech/webservicestoolkit.

Toolkit,

[10] Microsoft, XLANG Web Services for Business Process Design, http://www.gotdotnet.com/team/xml wsspecs/xlang-c/default.htm. [11] W3C WORKING DRAFT, XML Encryption Syntax and Processing, http://www.w3.org/TR/xmlenc-core/. [12] W3C Proposed Recommendation, XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/.

Proceedings of the 2002 Symposium on Applications and the Internet (SAINT’02w) 0-7695-1450-2/02 $17.00 © 2002 IEEE