« PrécédentContinuer »
<SOAP-ENV:Header> 505—-<p:traversalPathRefxmlns:xlink="www. w3.org/1999/xlink" xmlns:p=,,wvvw.ibm.com/p2p/schema/xlink/linkbase', xlink:type="simple" xlink:show="new" 51 Q- xlink:href='http://ibm.sampleRoute/linkbase/lb.xmr S0AP-ENV:mustUnderstand="17> </SOAP-ENV:Header>
<SOAP-ENV:Header> 605— <msgType>contentRequest</msgType> Q1Q— <securityHeader> <msgReceiver> ^m <receiverlD>22.214.171.124.999</receiverlD>
Q2Q- <receiverRole>remote trust proxy</receiverRole>
630- <RTPTag>aXbYcZ.. .9q8j7k6w5p</RTPTag>
WITHIN FEDERATED ENVIRONMENTS
The present invention is related to commonly-assigned U.S. Pat. No. 7,346,923 (Ser. No. 10/719,490, filed Nov. 21, 2003), which is titled "Federated Identity Management within a Distributed Portal Server". This commonly-assigned invention is referred to herein as "the related invention" and is 10 hereby incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention 15 The present invention relates to computer software, and
deals more particularly with techniques for achieving context-sensitive confidentiality within a federated environment for which content is aggregated in a distributed Web portal (or similar aggregation framework). 20
2. Description of the Related Art
Web portals (sometimes referred to equivalently as portal platforms, portal systems, or portal servers) are designed to serve as a gateway, or focal point, for access to an aggregation or collection of information and applications from many dif- 25 ferent sources. Portals often provide an end user view, commonly referred to as a "portal page". A portal page is often structured as a single overview-style page (which may provide links for the user to navigate to more detailed information). Alternatively, portal pages may be designed using a 30 notebook paradigm whereby multiple pages are available to the user upon selecting a tab for that page. (Other frameworks which aggregate content and/or services may have characteristics analogous to those of a portal. The term "portal", as used herein, is intended to include such other aggregation 35 frameworks.)
In addition to providing for content delivery to end users, Web portals are increasingly used as gateways to so-called "Web services" (i.e., network-accessible services) for distributed computing. Web services are a rapidly emerging tech- 40 nology for distributed application integration in a distributing computing environment such as the Internet. In general, a "Web service" is an interface that describes a collection of network-accessible operations. Web services fulfill a specific task or a set of tasks, and may work with one or more other 45 Web services in an interoperable manner to carry out their part of a complex workflow or a business transaction. For example, completing a complex purchase order transaction may require automated interaction between an order placement service (i.e., order placement software) at the ordering 50 business and an order fulfillment service at one or more of its business partners.
With Web services, distributed network access to software becomes widely available for program-to-program operation, without requiring intervention from humans. Web services 55 are generally structured using a model in which an enterprise providing network-accessible services publishes the services to a network-accessible registry, and other enterprises needing services (or human beings searching for network-accessible services) are able to query the registry to learn of the 60 services' availability. (Hereinafter, references to an entity or user making use of Web services are intended to include programmatic entities as well as human beings.) The participants in this computing model are commonly referred to as (1) service providers, (2) service requesters, and (3) service 65 brokers. These participants, and the fundamental operations involved with exchanging messages between them, are illus
trated in FIG. 1. The service providers 100 are the entities having services available, and the registry to which these services are published 110 is maintained by a service broker 120. The service requesters 150 are the entities needing services and querying 140 the service broker's registry. When a desired service is found using the registry, the service requester binds 130 to the located service provider in order to use the service. These operations are designed to occur programmatically, without requiring human intervention, such that a service requester can search for a particular service and make use of that service dynamically, at run-time. The Web services model is theoretically available for any type of computing application.
Web services allow applications and services (referred to hereinafter as services for ease of reference) to interact with one another using Web-based standards. A number of standards are being promulgated in the Web services arena as the problems inherent in that environment become better understood. A complete discussion of these protocols is beyond the scope of the present discussion, but basic protocols on which Web services work is being built include HTTP ("Hypertext Transfer Protocol"), SOAP ("Simple Object Access Protocol"), and WSDL ("Web Services Description Language"). HTTP is commonly used to exchange messages over TCP/IP ("Transmission Control Protocol/Internet Protocol") networks such as the Internet. SOAP is an XML ("Extensible Markup Language") based protocol used to send messages for invoking methods in a distributed environment. WSDL is an XML format for describing distributed network services.
For more information on SOAP, refer to "Simple Object Access Protocol (SOAP) 1.1, W3C Note 8 May 2000", which is available from the World Wide Web Consortium, or "W3C". The WSDL specification is titled "Web Services Description Language (WSDL) 1.1, W3C Note 15 Mar. 2001", and is also available from the W3C. HTTP is described in Request For Comments ("RFC") 2616 from the Internet Engineering Task Force, titled "Hypertext Transfer Protocol—HTTP/1.1" (June 1999). It should be noted that references herein to "HTTP" are intended in a generic sense to refer to HTTP-like functions. Some Web services operations, for example, require HTTPS instead of HTTP, where HTTPS is a security-enhanced version of HTTP.
The goal of Web services is to provide service requesters with transparent access to program components which may reside in one or more remote locations, even though those components might run on different operating systems and/or be written in different programming languages than those of the requester.
A federation within a Web services context relates to collaboration among loosely-coupled and complementary Web services across security domains. For example, suppose employees from two companies would like to meet with one another, and that the two companies have different automated calendar/meeting services, each of which provides complementary functionality (e.g., by managing employee's schedules). Federating these complementary services would allow the independent calendar services to exchange application information, enabling the employees to establish the joint meeting using their respective calendar services.
While support for Web services and portals in federated environments continues to make great progress, areas remain where improvements can be made.
SUMMARY OF THE INVENTION
An object of the present invention is to provide contextsensitive confidentiality within a federated environment.
Another object of the present invention is to provide context-sensitive confidentiality in an environment that leverages a distributed Web portal for aggregating a plurality of views or services.
A further object of the present invention is to define tech- 5 niques for securely transmitting messages within a federation that spans multiple trust models, where one or more intermediaries along a particular message path may need access to security-sensitive portions of a transmitted message.
Yet another object of the present invention is to provide 10 techniques whereby security-sensitive information transmitted with a message can be selectively disclosed to entities that are authorized to access that information.
Still another object of the present invention is to define techniques whereby a message can carry security-sensitive 15 information for multiple intended receivers, such that each intended receiver can access only the security-sensitive information specifically intended for that receiver.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings 20 which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention may be provided as methods for achieving 25 context-sensitive confidentiality among security domains within a federated environment that spans a plurality of security domains, further comprising: determining a route to be taken by a content request message to be transmitted from a content requester in the federated environment to a content 30 provider in the federated environment (wherein: the route comprises a network transmission path which begins at the content requester and ends at the content provider and passes through a plurality of intermediary nodes, each of the intermediary nodes located between the content requester and the 35 content provider on the network transmission path; the route is determined by consulting stored policy that specifies, for the content receiver sending the content request message to the content provider, the network transmission path; and the route spans a plurality of the security domains); storing the 40 determined route at a network-accessible location; determining, prior to transmitting the content request message from the content requester, a plurality of portions of the content request message that are security-sensitive, further comprising using a context to consult stored policy that identifies the 45 security-sensitive portions which are applicable to that context, wherein the context comprises an identification of the content requester, an identification of the content provider, and a message type identifying the content request message; determining, prior to transmitting the content request mes- 50 sage from the content requester, rights of each of the intermediary nodes to access each of the determined securitysensitive portions of the content request message, further comprising consulting stored policy for each of the intermediary nodes, wherein the stored policy specifies whether this 55 intermediary node is entitled to access this security-sensitive portion of the content request message; specifying, in unencrypted form in the content request message, the message type, an identifier of the network-accessible location where the determined route is stored, and a plurality of message 60 receiver elements, wherein a separate one of the message receiver elements is specified for each of the intermediary nodes that is entitled to access each of the security-sensitive portions, the separate one specifying an identification of that intermediary node as a permitted receiver of that security- 65 sensitive portion and a node-specific keyword corresponding to that intermediary node; selectively protecting the security
sensitive portions of the content request message, according to the determined access rights by encrypting, for each of the security-sensitive portions of the content request message, that security-sensitive portion separately for each distinct one of the intermediary nodes which is entitled to access that security-sensitive portion and storing that separately-encrypted security-sensitive portion in the content request message in association with the node-specific keyword corresponding to that distinct one of the intermediary nodes, thereby enabling each of the intermediary nodes to locate and access each of the security-sensitive portions which it is entitled to access and preventing that intermediary node from accessing any of the security-sensitive portions which it is not entitled to access; and transmitting the content request message with its selectively-protected portions from the content requester to the content provider on the determined route (wherein: the transmitted content request message contains information identifying an authentication authority from a first of the security domains and an identification of a party for which the content request message requests access to services and indicates that the identified authentication authority has already authenticated the party using security credentials of the party in the first security domain; the intermediary nodes and the content provider, upon receiving the content request message in other ones of the security domains, can bypass authentication of the party for access to services of that other security domain, upon verifying authenticity of the authentication authority, establishing that the authentication authority vouches for the received content request message, and using the identification of the party to locate previously-stored security credentials for the party which are usable within that other security domain; and the security credentials for the party in at least one of the other security domains are different from the security credentials of the party in the first security domain).
The present invention may also or alternatively be deployed as one or more services for ensuring context-sensitive confidentiality of messages transmitted within a federated environment. As one example, a message confidentiality service may be provided for securely transmitting messages among security domains within a federated environment, and this service may comprise: determining a route to be taken by a message to be transmitted in the federated environment, where the route spans a plurality of the security domains; determining rights of nodes to be encountered on the determined route to access security-sensitive portions of the message; and determining how the security-sensitive portions of the message should be protected, according to the determined access rights. A fee may be charged for performing the service. Optionally, the service may further comprise applying the determined protections to the security-sensitive portions.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 provides a diagram illustrating participants and operations of a service-oriented architecture in which Web services are deployed, according to the prior art;
FIG. 2 illustrates components of that may be involved when a confidential message is transmitted among participants in a federated environment;
FIG. 3 shows a generalized routing path between a message sender and an ultimate message receiver, as well as several intermediaries along the path that may need access to