Legislación Mexicana.

We return to the four requirements we listed earlier.

ePortal must know who the initiator is. ePortal’s authentication of the initiator does not occur across the Web Services boundary. But, the authenticated identity of this individual may be important to eBusiness. The Web server, possibly using operating system authentication, or a Web SSO system will authenticate Joe. He interacted with ePortal using a conventional browser and established a connection to ePortal. Joe did not need any additional software, helper apps, plug-ins, or applets, at his workstation. This is an important reason for the pop- ularity of Web SSO systems. Once Joe is authenticated, a SAML assertion is cre- ated. The user’s identity is passed on to the ePortal application system using the assertion. The application server establishes the user’s security context. This is done assuming that the application server has established a trust relationship with the Web server and its SSO system. Different authentication methods may be used. This includes passwords, one-time passwords, and SSL client-side authentication.

eBusiness must be sure that it received a SOAP request from ePortal. eBusiness must know that it is getting its SOAP request from ePortal. Since we are using HTTP to transmit the message, a connection-oriented authentication system is a possibility. However, there are times when messages are routed through an inter- mediary, the accounting system. At these times, connection-oriented techniques can’t be used to authenticate ePortal, and another technique must be used.

XML Signature, a document-authentication technique, can be used to authenti- cate the message even if the message is routed through an intermediary. Signing authenticates the source of the message rather than the other end of the connec- tion. In this case, the distinction is not significant. But, because the message is authenticated, it doesn’t matter what transport is used. It also doesn’t matter that other servers between the originator and the destination may relay the mes- sage. Since the digital signature is part of the message, the signature has persis- tence that allows it to be used to authenticate the message at a later time. Software to sign the message can be included on the eBusiness server.

eBusiness must know who the initiator is. In general, eBusiness will need the authenticated identity of the request initiator. However, since the initiator is not directly connected to the eBusiness, connection-oriented authentication tech- niques cannot be used. Since the initiator used a generic browser without any special-purpose software, there was no way to create a digital signature and attach it to his HTML document. Of course, doing so only makes sense if the document has an obvious relationship to the SOAP message that was actually sent to eBusiness. This may not be true. What Joe, the initiator, saw on his screen and submitted was formatted to be meaningful to him and probably looked nothing like the message that was sent. So, even if there was a way for him to sign his HTML document, it might not mean much to eBusiness.

In setting up Web Services between ePortal and eBusiness, mutual trust has been established between them. Since ePortal authenticated the initiator, eBusiness will take ePortal’s word for the identity of the initiator. In fact, eBusiness will also accept ePortal’s attributes for Joe. We must make sure that this information is passed to eBusiness in a secure and meaningful way. That’s where SAML comes in. When ePortal authenticated the initiator, it requested a SAML authen- tication assertion. Later, when ePortal knows it is going to make a Web Services request to eBusiness, it requests an attribute assertion with the attributes that eBusiness needs to decide whether Joe is authorized to order the merchandise. If the message has been signed, the assertion will be bound to the message, and no one will be able to separate the assertion from the message without detection and use it with another message. (Of course, we also want to make sure that the entire message can’t be reused either.)

ePortal must be sure that it is sending its SOAP request to eBusiness. Finally, we must make sure that eBusiness’s authenticated identity is known to ePortal. The most common method in use is SSL with server-side authentication. During the establishment of the SSL session, the server normally provides authentica- tion to the client by using public key cryptography. But, if ePortal is not directly connected to eBusiness, the possibility of using SSL server authentication is not feasible. ePortal’s ability to ensure itself of eBusiness’s identity before it sends a message to eBusiness is limited. Even if it could authenticate eBusiness, it still has other concerns. Since there are intermediaries that can handle the SOAP message, it must ensure that the message gets to eBusiness intact. Without authenticating eBusiness, ePortal could encrypt the SOAP message so that eBusiness and only eBusiness can decrypt the message. If the message gets into the wrong hands, it doesn’t matter because they couldn’t decrypt the message in a practical length of time.