US20080256364A1 - Dynamic negotiation of security arrangements between web services - Google Patents

Dynamic negotiation of security arrangements between web services Download PDF

Info

Publication number
US20080256364A1
US20080256364A1 US10/246,276 US24627602A US2008256364A1 US 20080256364 A1 US20080256364 A1 US 20080256364A1 US 24627602 A US24627602 A US 24627602A US 2008256364 A1 US2008256364 A1 US 2008256364A1
Authority
US
United States
Prior art keywords
preferences
security
service
message
community
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/246,276
Other versions
US7444522B1 (en
Inventor
Symon Szu-Yuan Chang
Joseph S. Sanfilippo
Jayaram Rajan Kasi
Christopher Crall
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Perfect Commerce Holdings LLC
Open Invention Network LLC
Original Assignee
Commerce One Operations Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commerce One Operations Inc filed Critical Commerce One Operations Inc
Priority to US10/246,276 priority Critical patent/US7444522B1/en
Assigned to COMMERCE ONE OPERATIONS, INC. reassignment COMMERCE ONE OPERATIONS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHANG, SYMON SZU-YUAN, KASI, JAYARAM RAJAN, SANFILIPPO, JOSEPH S., CRALL, CHRISTOPHER
Priority to AU2003263904A priority patent/AU2003263904B2/en
Priority to JP2004537673A priority patent/JP2005539453A/en
Priority to EP03797854A priority patent/EP1540479A4/en
Priority to CNB038251655A priority patent/CN100342347C/en
Priority to KR1020057004614A priority patent/KR100970771B1/en
Priority to PCT/US2003/025894 priority patent/WO2004027618A1/en
Assigned to JGR ACQUISITION, INC. reassignment JGR ACQUISITION, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: COMMERCE ONE OPERATIONS, INC.
Assigned to OPEN INVENTION NETWORK, LLC reassignment OPEN INVENTION NETWORK, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: JGR ACQUISITION, INC.
Assigned to WELLS FARGO FOOTHILL, INC., AS AGENT reassignment WELLS FARGO FOOTHILL, INC., AS AGENT PATENT SECURITY AGREEMENT Assignors: COMMERCE ONE, LLC, PANTELLOS CORPORATION, PANTELLOS I INCORPORATED, PANTELLOS II INCORPORATED, PERFECT COMMERCE LP, PERFECT COMMERCE OPERATIONS, INC., PERFECT COMMERCE, INC.
Publication of US20080256364A1 publication Critical patent/US20080256364A1/en
Publication of US7444522B1 publication Critical patent/US7444522B1/en
Application granted granted Critical
Priority to JP2011177761A priority patent/JP4892640B2/en
Assigned to CORMINE, LLC reassignment CORMINE, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WELLS FARGO FOOTHILL, INC.
Assigned to PERFECT COMMERCE HOLDINGS, LLC reassignment PERFECT COMMERCE HOLDINGS, LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: CORMINE, LLC
Adjusted expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105Multiple levels of security
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/606Protecting data by securing the transmission between two devices or processes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113Multi-level security, e.g. mandatory access control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the computer program listing appendix includes the following files:
  • the present invention relates to computer-based devices and methods to negotiate and implement security arrangements between two or more Web Services. More particularly, it relates to devices and methods that specify input and output interfaces, compute and generate a security contract consistent with inputs, and implement security in accordance with negotiated security arrangements. Particular aspects of the present invention are described in the claims, specification and drawings.
  • B2B and A2A electronic commerce are replacing former protocols for electronic data interchange (EDI).
  • EDI electronic data interchange
  • Standards related to simple web service include UDDI, WSDL, XSDL and SOAP.
  • these standards do not fully meet the security, reliability, manageability, and choreography requirements for practical B2B and A2A electronic commerce.
  • Security in particular presents numerous options and configuration issues. Collaborative web services and their security needs are expected to evolve as non-web businesses do. There is no any comprehensive or unified device or method that dynamically resolves and updates security options and configurations as web services evolve.
  • Choreography efforts include ebXML/BPSS from OASIS, WSFL from IBM, and XLANG from Microsoft.
  • Conversation efforts include ebXML/TRP from OASIS and Microsoft's WS-routing.
  • the dominant security effort is WS-security from IBM and Microsoft, there is also a complementary security effort in OASIS called SAML.
  • SAML complementary security effort in OASIS
  • W3C is addressing standardization in all of these areas. Key industry players have formed a rival consortium called WSI. However, they have not addressed the dynamic security negotiation issue.
  • the present invention relates to computer-based devices and methods negotiate and implement security arrangements between two or more web services. More particularly, it relates to devices and methods that specify input and output interfaces, computation and generation of a security contract consistent with inputs, and implementation of security in accordance with negotiated security arrangements. Particular aspects of the present invention are described in the claims, specification and drawings.
  • FIG. 1 illustrates communities and networks of communities, which are one environment in which computer-assisted, dynamic negotiation of security arrangements is useful.
  • FIG. 2 depicts negotiation and implementation of security arrangements.
  • FIG. 3 illustrates reconciling preferences among algorithm types.
  • FIG. 4 illustrates alternative embodiments for obtaining receiver's information when the sender is local to calculations of the security arrangements.
  • FIG. 5 illustrates one network of program logic and resources that can be used to implement aspects of the present invention.
  • FIG. 1 illustrates communities and networks of communities, which are one environment in which computer-assisted, dynamic negotiation of security arrangements is useful.
  • a community maintains a local registry that includes information such as users, companies, services and connectors that are part of the community.
  • the community can be a marketplace, an enterprise or a sub enterprise.
  • communities can belong to one or more community networks. Typically, communities and networks have some common business interest. Interoperation is between member communities in one or more community networks.
  • the networks include a gold marketplace network 1 , a precious metal marketplace network 2 , a private network 3 and a global trading web network 4 . In this illustration, the gold marketplace network 1 and the precious metal marketplace network 2 are contained within the global trading web network 4 .
  • the precious metals marketplace network 2 includes gold and silver marketplaces 14 , 13 .
  • Gold marketplace customers can trade silver in the silver marketplace 13 and silver marketplace customers can trade in gold 14 .
  • One community, PQR Enterprise 17 belongs to the gold marketplace network 1 , the private network 3 and the global trading web network 4 ; another community, ABC Big Supplier 18 belongs to the private network 3 .
  • XYZ Gold 14 is a marketplace or community for trading gold.
  • Enterprises belong to this community. Enterprises like PQR Enterprise 17 that have formed a community by themselves belong to the gold marketplace network 1 . These communities are part of the gold marketplace network 1 , and the global trading web network 4 .
  • Small supplier 15 is part of the gold marketplace community.
  • Other enterprises 16 are communities that are part of the gold marketplace community network 1 .
  • XYZ Gold 14 and other gold marketplace entities 15 - 17 indicate that the gold marketplace requires all traffic between enterprises (communities or otherwise) transacting gold trading to be routed through XYZ Gold 14 , for instance, to collect billing and business intelligence information.
  • PQR Enterprise 17 is a community is part of the gold marketplace and also part of local private network with supplier 18 .
  • Small supplier 15 may be an individual small supplier that does not want to form a community by itself and instead registers its metadata, such as users, organizations, services and transformations, in the registry of the gold marketplace.
  • ABC Big Supplier 18 has formed a private network of its own, for instance because it wants to keep its metadata, internal back office systems and transformations hidden from general public access because they were developed at considerable cost.
  • PRQ 17 is a customer of ABC 18 , it participates in the private network 3 .
  • Financial service provider DEF Financial 12 wants to provide financial services to anyone in the global trading web network 4 , such forms a community of its own and registers with the global trading web root 11 .
  • a network of communities makes available a global registry of communities. The global registry permits lookup of the community and determination of one or more routes to that community, or to external connectors through which the electronic commerce documents bound for the community may be routed. Documents routed from one community to another may be routed directly between external connectors for the two communities or indirectly through one or more intermediary communities. Business and security rules for transactions involving the communities also can be defined and maintained in community registries.
  • FIG. 1 illustrates the mixed loyalties of entities and communities that create an impetus for interoperability among electronic commerce platforms.
  • Connector is a general term for applications that communicate with other applications.
  • Connectors may communicate on a peer-to-peer (P2P) basis or on a directed basis through other connectors that function as hubs, gateways, external ports, central connectors, etc.
  • P2P peer-to-peer
  • Connectors that communicate P2P are able to communicate with other connectors that use the same transport/envelope protocols.
  • Connectors that communicate P2P optionally may enlist the assistance of other hub connectors that perform translation services, when trying to communicate with a connector that does not use the same transport/envelope protocol.
  • Connectors that communicate on a directed basis communicate through hub connectors according to routing rules.
  • Routing rules among connectors can be mapped in a directed graph, supporting one or more hub and spoke topologies for one or more transport/envelope protocols.
  • a hub and spoke topology directs communications along spokes to hubs, in one or more tiers. This facilitates centralized services such as billing, business intelligence collection, tracking, auditing, accounting, or others.
  • Multiple hub and spoke organizations may overlay the same connectors to support different transport/envelope protocols and technologies, as suggested by FIG. 2 . For instance, a stronger hub and spoke organization may be required to use Sonic as a transport technology than to use HTTP or HTTPS.
  • communication routes may depend on whether the source and destination are part of the same community.
  • a sub-community which may include the whole community
  • centralized functions may be unneeded and P2P communications permitted among connectors that otherwise are directed to communicate with parent connectors when communicating with destinations in other sub-communities.
  • Connectors may be labeled simple connectors (sometimes simply called connectors), hubs (sometimes called gateways or routers) or central connectors. Alternatively, they may be described functionally. Simple connectors are directed to communicate via hub connectors, except when they are permitted to communicate P2P among connectors in the same sub-community. So-called hubs are used by connectors that are explicitly directed or linked to them. Hubs may serve more than one function and, accordingly, may appear more than once in a route from a source to a destination. Hubs forward electronic commerce documents or messages. Hubs also may translate among transport protocols that support a common envelope protocol. For instance, a hub may translate envelope protocols and also implement a different transport protocol upon transmission than upon receipt.
  • a central connector is a special case of a hub, which can be used by connectors that are not explicitly directed or linked to them.
  • a central connector is useful, for instance, to carry out translation functions when traversing connectors from a source according to routing rules does not lead to any hub that supports the transport/envelope protocol used by the destination.
  • a schema and a process flow provide an overview of security arrangements according to aspects of the present invention.
  • negotiation of security arrangements is carried out by a computer-based process that uses security profiles of sending and receiving services to determine a mutually agreeable security arrangement.
  • this security arrangement is negotiated or potentially updated regularly, without user intervention.
  • This arrangement may be negotiated, updated or checked for validity at a user request or without user intervention whenever messages are exchanged or on some other periodic or occasional basis, such as monthly, weekly, daily, on occurrence of an event that impacts exchange of messages between a particular sender and receiver (e.g., a software component failure or a change in security preferences), when a previously negotiated arrangement fails, or on some other periodic or occasional basis.
  • the schema SecuritySenderReceiverInfo.XSD in the source code appendix, describes some inputs to negotiation of security arrangements.
  • the schema SecurityContract.XSD also in the source code appendix, describes one embodiment of negotiated security arrangements, in a so-called security interoperability contract document (“SCID”).
  • SCID security interoperability contract document
  • the schema SecuritySenderReceiverInfo.XSD in the source code appendix, can be used to validate a plurality input files to negotiation of security arrangements.
  • the machine-readable input files are XML documents.
  • other data structures may be used to store the same information, for instance a tree structure modeled after the XML code.
  • the schema SecuritySenderReceiverInfo.XSD is best understood by loading the file into an integrated development environment (IDE) such as XML Spy TM, which provides several alternative views of the schema, including a documentation generation view. Sender and receiver security interoperability contract document information blocks are defined by this schema.
  • SecuritySenderReceiverInfo.XSD includes several components that are used to define sender and receiver security information.
  • the CommunitySecurityPolicyPreference component states the community preferences to sign the header, encrypt the credential, and credential preferences. It can be used to specify a default value for a whole community or it could be adapted to specify a default value for a collaboration partner (CP).
  • the SAMsgSecurityPolicy component allows specification of signature and encryption preferences and authentication options. Message exchanged between services may have multiple parts. Signature and encryption policies can be applied to the whole message or individual parts. This approach can readily be extended to applying signature and encryption policies to elements within the parts.
  • the PublicKeys component identifies key records for this CP.
  • the ConnectorCapability component provides routing information to a resource that implements part of the security arrangement, such as a connector name. It includes connector capability parameters such as encryption capability, signature capability, an encryption public key party, and signing public key party.
  • Public key party can be the sender's CP, the receiver's CP, or the owner of the connector, depending on whether signing or encryption is involved. If the public key party is not defined, the key of the message sender can be used for signing and the key of the message receiver can be used for encryption.
  • the SecurityContainer component can be used to carry additional objects that are useful for security.
  • the SendingCPSecurityPolicyProfile component includes the sending CP's available credentials information.
  • the CPSendServicesSecurityPolicy and CPRecvServicesSecurityPolicy component include sets of security policies for the sending and receiving services, respectively. The services preferences and overrides can be defined here.
  • the schema SecurityContract.XSD also in the source code appendix, can be used as a model for preparing a machine-readable security interoperability contract document.
  • the machine-readable document is an XML document.
  • other data structures may be used to store the same information, for instance a tree structure modeled after the XML code.
  • This schema defines policies and channels for security policies.
  • a security channel defines resources and routes to resources that carry out security algorithms, such as signature, encryption and authentication algorithms. It also may include non-repudiation and authorization resources.
  • the process flow FIG. 2 can be used to describe negotiation and implementation of security arrangements.
  • the preferences of the sending and receiving services are maintained in a registry 201 .
  • This registry may be accessible to the sending and receiving services, so that either service can compute security arrangements, or it may be available to a security arrangement computing service that is accessible to one or both of the sending and receiving services.
  • the sending and receiving services may maintain their own registries. Or, a protocol may be developed for the sending and receiving services to exchange their security preferences as part of the negotiation of security arrangements.
  • a registry 201 further may maintain information regarding default preferences of a collaboration partner that owns a service or a community to which a collaboration partner belongs, or both.
  • Default preferences may be overridden by service-specific preferences, in general, or certain default preferences may be given precedence over service-specific preferences. Default preferences of collaboration partners may be treated differently than default preferences of the community.
  • Input statements of security arrangement preferences are taken from the registry 201 or another source and acted upon by a security arrangements computing service 202 . In one embodiment, this computing service is a security contract builder.
  • a set of security arrangements are output 203 . These arrangements may be confirmed with the sending and receiving services, may be subject to a veto by the sending or receiving service, or may be trusted by the sending and receiving services.
  • the sending service or another service responsive to the sending service 205 uses the security arrangements 203 to process the document 204 for transmission to the receiving service 209 .
  • the security arrangements will call for obtaining an assertion from a trusted assertion service 206 .
  • the sending and receiving services may agree to use a SAML service to generate authentication assertions.
  • the security arrangement 203 would call for generation of a SAML assertion and the sending service 205 would obtain a SAML assertion from a SAML server 206 .
  • an electronic notarization might be provided by a trusted service 206 .
  • Banks or security authorities might be trusted to generate authentication assertions, in a function analogous to notarization.
  • the security arrangements will call for obtaining public keys used in asymmetrical signing or encryption from a public keys source 208 .
  • the sending and receiving services may agree to use an XKMS service to exchange public keys.
  • the security arrangement 203 would specify the XKMS service address as the source of public keys.
  • the sending service 205 and the receiving service 209 both would access the agreed keys source 208 .
  • the sending service 205 communicates the document 204 through a network 207 to the receiving party 209 .
  • the routing and transport through the network 207 may be part of the security arrangements or, preferably, may be handled by a secure transport infrastructure.
  • the security arrangements 203 may be provided by the computing service 202 to the receiving party 209 or otherwise made accessible to the receiving party, independent of the message carrying the document 204 . Alternatively, the security arrangements 203 may be included with the document 204 according to a prearranged protocol.
  • the prearranged protocol may call for the message header or message part to be signed and/or encrypted using the parties' respective keys.
  • the files SecuritySenderInfo.XML, SecurityReceiverInfo.XML, and ComputeSecurityContract.XML provide an example of sender and receiver preferences and a resulting computed security arrangement.
  • the sender and receiver preferences are stated in XML code conforming to the XML schema explained above.
  • the computed security arrangement is stated in an interoperability security contract document conforming to the SecurityContract.XSD schema in the source code appendix.
  • the sender preferences information includes community preferences and service preferences.
  • the community preferences address security algorithms, preferences to sign the header, encrypt the credential and for selection among available credentials.
  • the community preferences also may rank order the security algorithms or otherwise indicate preference among the security algorithms.
  • a similar set of preferences might be provided for a collaboration partner, either instead of more in addition to preferences for a community.
  • the community has six sets of signature algorithms options in elements named XMLSignatureAlgorithmTemplate and three sets of encryption algorithms options in elements named XMLEncryptionAlgorithmTemplate. These sets of options are templates. More than one template of options can be provided for a particular algorithm. Use of templates simplifies configuration of options and increases the likelihood consistent option sets will be selected by sending and receiving services.
  • the community in this example prefers not to sign headers or encrypt credentials and accepts basic credentials.
  • a community or a collaboration partner may have preferences for any security arrangement options that the service can select, or the community or collaboration partner may have preferences for only some options.
  • Community preferences in a sender's preference file should correspond to community preferences stated elsewhere, such as in a registry entry for community preferences.
  • the file CommunitySecurityTemplatesPreferences.XML is an example of a file used to record some or all of a community's security preferences.
  • the service records in SAMsgSecurityPolicy its preferences for handling message parts, for signature and encryption of the message as a whole, and for authentication. Messages may have several parts. Corresponding to a message part, a service may identify the message part and express a preference for signing or not signing or for encrypting or not encrypting a message part. In this embodiment, a preference for a category of algorithm, such as a general algorithm or in XML-specific algorithm can be selected. In other embodiments, the service might not specify a category of algorithm or it might specify a specific algorithm.
  • the receiver's (buyer's) public key in an X509 format, is use for signature and authentication.
  • Two resources, so-called connectors, are identified for the sending service to use for signing and encryption.
  • the sender's available credentials are identified as basic and X509 credentials.
  • the sending service's security arrangement preferences are rank ordered from one to three under SecurityPolicyTemplatePreference. In this example, the three encryption preferences are all for XML-specific encryption.
  • Receiving party preferences are found in the source code appendix file SecurityReceiverInfo.XML.
  • the elements of the receiving party's preference profile are very similar to those of the sending party, even using the same element types from the schema.
  • Significant differences are found in authentication and authorization, since the logic applicable to authentication and authorization depends on whether you are presenting your credentials or determining whether to accept what is presented. For instance, the SendingCPSecurityProfile of the sending party lists available credentials. This element is not part of the receiving party's preferences. This issue is addressed by the receiving party's CPRecvServicesSecurityPolicy, which identifies AcceptedCredentials.
  • FIG. 3 illustrates reconciling preferences among algorithm types.
  • Stacks 301 and 302 represent sending and receiving preferences.
  • A is the most secure and G the least secure.
  • preference B and D match.
  • a decision rule for choosing between B or D might take into account one or both stacks of preferences. For instance, the receiving service's preference (D) for signature or the sending service's preference (B) for encryption might be selected from among the matches.
  • the second type of preferences is for whether or not to sign or encrypt a part of a message. What to sign or encrypt is addressed by the SAMsgPart elements of SAMsgSecurityPolicy.
  • the message parts in the example are Order and Image.
  • sender and receiver preferences match, for signing and encrypting the Order and only encrypting the Image. Preferences would not match if the receiver wanted the Image signed, as well as the Order. Then, a decision rule would be needed to resolve the mismatch.
  • the available decision rules could include: receiver wins, sender wins, highest requirement wins or lowest requirement wins.
  • One type of preference reconciliation determines whether to apply a security measure. The other type selects among option templates, when the security measure is applied.
  • the security policy section sets out the signature policy, and encryption policy and encryption key information. It also may set out policies regarding authentication, authorization and non-repudiation of origin or receipt.
  • the same signature and encryption policy is applied to all parts of the document.
  • multiple algorithms could be applied to different parts.
  • the algorithm selected for signature, encryption and authentication are abstracted through templates containing options sets, simplifying the selection of algorithms. Selected algorithms are associated with logic and resources, so different services or processes can be used for signing/verifying and encrypting/decrypting different parts of a message.
  • a public key or certificate can be transmitted in the encryption key element of the security policy section.
  • the security channel section describes services or connectors involved in applying security policies.
  • the channel section identifies a source connector that requires assistance in applying a security policy (e.g., the sending service requesting encryption), and a target connector that applies the security policy or acts as an intermediary to logic and resources that apply the security policy.
  • a security policy such as signing, encryption, authentication, authorization or non-repudiation, specific information required to carry out the security policy is provided in the security channel section.
  • the data used to determine security arrangements can be categorized as message and activity related data, CP-service related data, security algorithms related data, routing related data, encryption key related data and configuration data. Some additional detail regarding use of these categories of is described below.
  • Message and activity related data relates to digital signatures, encryption, non-repudiation, and authorization.
  • a receiver may require non-repudiation measures for a sender, amounting to a trusted party verification of the sender's message to receiver.
  • a sender may require non-repudiation measures for a receiver, amounting to a trusted party verification of receipt of sender's message by the receiver.
  • signatures and encryption can be applied on an element basis, to particular items of data, if fine granularity is desired.
  • overrides can be specified for pairs of sending and receiving services. For instance, a pre-existing or proven relationship can be treated differently than an entirely new relationship. Overrides to security policies can be implemented to cautiously reduce (or increase, as warranted) security requirements in particular cases.
  • CP-related data includes authentication and authorization data.
  • Authorization is the process of granting or denying access to a network resource. Authorization to access most computer security systems is a two-step process. The first stage is authentication, which ensures that a principal (user, process, application or service) is who it claims to be. The second stage is authorization, which allows the principal access to various resources based on their identity. Authorization is also called access control. Access control is used to authorize access to website resources. It manages information about users, groups of users, and the roles assigned to users. SAML provides an XML-based means to share information about security events (authentication and authorization) and attributes (e.g. credit rating) in a SOAP message.
  • This SAML data can then be sent to a third-party, and this enables ‘distributed trust’, whereby the user signs on once, but can re-use their authentication or authorization details.
  • the issuing authority decides whether to grant the request by subject services or sender, for access type to resource web service, given the evidence provided by the requestor.
  • the authorization decision allows or denies a subject access to a specific resource.
  • SAML is useful option for web services security, but it requires an initial degree of trust and technical resources. In instances when SAML is unavailable or not preferred, other approaches such as ID/password and a table of privileges associated with an ID can be used.
  • the present invention is not limited by the authorization technology used, but extends more abstractly to selection among presently available or hereafter invented technologies. With either SAML authorization or ID/password technologies, the authorization data can be encrypted and built into the message.
  • Security algorithms related data includes algorithms and configuration options for signature, encryption and non-repudiation.
  • signature algorithms options may include use of XMLDsig, choice of a Canonicalization algorithm, a signature method and a digest algorithm.
  • Encryption/decryption options may include key size, key and method. Default may be inherited by a service, either overriding the services preferences or being overridden. In addition, specific overrides can be specified for CP pairs, as described above. Option templates, also described above, simplify negotiation of security arrangements. Different options will apply to XML and non-XML algorithms, signature algorithms for example.
  • XML signature algorithms e.g., XMLDisg
  • PCKS#7 non-XML algorithms
  • Use of community standard security templates are preferred, to ensure that there is at least one match between preference lists of the respective services.
  • a community may require all CP's or all services operating in the community to support a particular community standard security option set, to assure that messages can be exchanged within the community.
  • Routing related data includes how to access logic and resources that implement authentication/verification, signing/verification, and encryption/decryption. Any type of access information may be used, such as a universal resource name (URN) or universal resource locator (URL).
  • URN universal resource name
  • URL universal resource locator
  • a message may take multiple hops through connectors for translation or other value-added services. Accordingly, multiple route steps may be associated with any action. Security typically will need to be reapplied after any translation or other value-added service.
  • Encryption key related data is generally discussed above.
  • Configuration data includes default (e.g., community or collaboration partner) preferences and credential preferences.
  • FIG. 4 illustrates alternative embodiments for obtaining receiver's information when the sender is local to calculations of the security arrangements.
  • local 431 and remote 432 registries are indicated.
  • the sender is local and the receiver remote.
  • the sender's data is current and complete in the local registry 431 .
  • the sender's information is collected 421 and made available to the logic and resources that compute the security arrangements 411 .
  • the receiver's data may be current and complete, for instance if the receiver is in the same community as the sender and there is a community-wide registry, or if the receiver's information has been recently obtained and locally cached.
  • a process 422 or 423 is invoked to collect the receiver information and make it available to the logic that computes security arrangements.
  • a set of security arrangements 401 result.
  • FIG. 5 illustrates one network of program logic and resources that can be used to implement aspects of the present invention.
  • the logic components of this network include: send side collection 551 , receive side collection 552 , data object manager 541 , routing manager 542 , credential negotiator 531 , template negotiator 532 , connector manager 533 , authentication manager 521 , policy manager 522 , public key manager 523 , algorithm manager 524 , policy builder 511 , channel builder 512 and security arrangements document builder 501 .
  • One embodiment of program logic operative in a community of collaboration partners to generate security arrangements can be described as follows: Collect the receiver security information, including an attribute assertion to authenticate the sender CP. Collect the sender security information. Look into routing block to find all connectors information to implement security measures. Get capability parameters for each connector. Walk through the routing chain to find which connector-pair to use for authentication, signature, and encryption. Get the receiver's service-activity-message object. This may include getting a SAMsgSecurityPolicy object from the receiver. This will have multiple parts and it can have signature and encryption policies for the whole message.
  • SAMsgSecurityPolicy object may include getting a SAMsgSecurityPolicy object from the sender, and match the override options the SAMsgSecurityPolicy object accordingly. (Override decision tables are discussed below.) From the SAMsgSecurityPolicy object, find all algorithms required for this message, and build RequiredAlgorithmList. Get community preference objects for both SenderInfo and ReceiverInfo. This may include getting a CommunitySecurityTemplatesPreference object of the sender, which includes security algorithm templates, and community security policy preferences. It also may include getting a CommunitySecurityTemplatesPreference object of the receiver, if not the same community. If they are in the same community, it may be sufficient to set an object pointer.
  • Decision tables may be used to implement the type of preference reconciliation related to whether to sign or encrypt part of a message. Again, decisions could be biased to accept preference not to sign or to accept the receiver's preference, or just the opposite. Some decision tables that could be used to implement possible decision rules follow:
  • the present invention is readily extended to support signing and encryption at intermediate connectors along a path between a sender and receiver. It is useful to be able to sign and encrypt documents at connectors along a routing path that are not the message originators or final receivers. This may be useful for gateways, routers and central connectors. For gateways, signing and encryption may need to be performed by a gateway if signed/encrypted message data is transformed from one envelope protocol to another. For routers and central connectors, it may be desirable to use a single entry/exit point into the enterprise for external communities. A router or central connector may act as the central security hub and perform or organize security operations on behalf of the entire enterprise. This may simplifies the PKI management and other administrative burdens.
  • This functionality can be configured by setting up the security capabilities of connectors in the enterprise's part of a community.
  • a connector can be configured on an envelope/transport protocol basis to have signing capability or encryption capability and can be linked to signing and encryption capabilities of the collaboration partner at other connectors.
  • gateways and routers you could configure the connector to use the key of the CP owner or the gateway/router connector.
  • One embodiment is a method of dynamically determining security options for exchange of one or more messages between sending and receiving services.
  • This method uses sender and receiver security preferences, which may take the form of machine security profiles for first and second services.
  • the security profiles may identify security options/elements and option subsets that are acceptable to the respective services.
  • the options may include requirements to sign or encrypt one or more parts of the message, signing option subsets corresponding to one or more signing algorithms, encryption option subsets corresponding to one or more encryption algorithms, identification of signing and encryption keys and identification of an authentication algorithm.
  • the dynamic method includes accessing the security profiles and selecting a particular option set that is acceptable to the respective services.
  • this option set can be used to communicate a message between the respective services.
  • Security profiles can be maintained in one or more registries that are accessible to security logic of the first and second services.
  • Default option subsets and/or preferences can be specified in community or collaboration partner security profiles and may be copied into service security profiles.
  • Requirements to sign or encrypt can be applied to the parts of the message or to a message as a whole.
  • Signature and encryption algorithms may be applied to a message as a whole, reducing complexity. Signing and encryption keys may be symmetrical or asymmetrical.
  • Authentication may be carried out by a trusted agent, such as a SAML server, before communicating the message between the respective services.
  • Authentication by a trusted agent may be evidenced by authentication assertion.
  • authentication may include submitting credentials for examination by the receiving service. These credentials may be part of the message or may be transmitted in addition to the message.
  • authorization may be addressed by security arrangements.
  • the security profiles may include identification of at least one authorization algorithm to establish a sending service's privileges. This authorization may be implemented by a trusted agent before communicating the message or by submitting credentials to the service receiving the message.
  • a further aspect of the present invention is taken into account preferences of the respective services among option subsets for signing and/or encryption. Preferences of one or both of the services may be taken into account.
  • Determination of security arrangements may include determining resources to be used by the respective parties to implement any combination of signatures, encryption, authentication, authorization or non-repudiation. Resources, algorithms and option says may be packaged into security channels. A security channel may implement a single aspect of security.

Abstract

The present invention relates to computer-based devices and methods negotiate and implement security arrangements between two or more web services. More particularly, it relates to devices and methods that specify input and output interfaces, computation and generation of a security contract consistent with inputs, and implementation of security in accordance with negotiated security arrangements. Particular aspects of the present invention are described in the claims, specification and drawings.

Description

    RELATED APPLICATIONS
  • This application is related to the commonly owned U.S. Letters patent application Ser. No. 10/199,967, entitled “Electronic Commerce Community Networks and Intra/Inter Community Secure Routing Implementation”, by inventors Raghunath Sapuram, Jayaram Rajan Kasi, Todd Klaus, Christopher Crall, and Joseph Sanfilippo, filed on 19 Jul. 2002 and incorporated herein by reference. This application also is related to the commonly owned U.S. Letters Patent application Ser. No. 10/199,963, entitled “Registry Driven Interoperability and Exchange of Documents”, by inventors Christopher Todd Ingersoll, Jayaram Rajan Kasi, Alexander Holmes, Michael Clark, Ashok Aletty, Sathish Babu K. Senathi, and Helen S. Yuen, filed on 19 Jul. 2002 and incorporated herein by reference.
  • This application is related to two commonly owned U.S. Letters Patent Applications filed the same day as this application, entitled “Exposing Process Flows And Choreography Controllers As Web Services”, by inventors Jayaram Rajan Kasi, Vinkesh Omprakash Mehta, Raghunath Sapuram, and Ram Shankar and “Dynamic Interoperability Contract for Web Services”, by inventors Jayaram Rajan Kasi, Rashmi Murthy, Symon Szu-yuan Chang, Todd Klaus, and Helen Yuen. The two applications filed the same day are hereby incorporated by reference.
  • COPYRIGHT NOTICE
  • A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
  • REFERENCE TO COMPUTER PROGRAM LISTING APPENDIX
  • A computer program listing appendix comprising duplicate copies of a compact disc, named “CM1035,” accompanies this application and is incorporated by reference. The computer program listing appendix includes the following files:
  • SecuritySenderReceiverInfo.XSD 25,351 bytes created Sep.
    (File containing schema for negotiation 17, 2002
    inputs.)
    SecurityContractKeyInfo.XSD 15,532 bytes created Sep.
    (File containing schema for keys used 17, 2002
    for security.)
    SecurityContract.XSD 15,298 bytes created Sep.
    (File containing schema for security contract 17, 2002
    output from negotiation.)
    CommunitySecurityTemplatesInfo.XML  9,065 bytes created Aug.
    (File containing schema for negotiation 29, 2002
    inputs.)
    SecuritySenderInfo.XML 13,302 bytes created Sep.
    (File containing sender info in example.) 11, 2002
    SecurityReceiverInfo.XML 17,221 bytes created Sep.
    (File containing sender info in example.) 12, 2002
    ComputeSecurityContract.XML  4,689 bytes created Sep.
    (File containing computed security contract 12, 2002
    in example.)
  • BACKGROUND OF THE INVENTION
  • The present invention relates to computer-based devices and methods to negotiate and implement security arrangements between two or more Web Services. More particularly, it relates to devices and methods that specify input and output interfaces, compute and generate a security contract consistent with inputs, and implement security in accordance with negotiated security arrangements. Particular aspects of the present invention are described in the claims, specification and drawings.
  • Business-to-business (B2B) and application-to-application (A2A) electronic commerce are replacing former protocols for electronic data interchange (EDI). As businesses strive to improve their efficiency with B2B and A2A systems, a number of incompatible platforms and competing standards have emerged. Among compatible standards, gaps remain to be filled. For instance, the industry has defined what a simple web service is. Standards related to simple web service include UDDI, WSDL, XSDL and SOAP. However, these standards do not fully meet the security, reliability, manageability, and choreography requirements for practical B2B and A2A electronic commerce. Security in particular presents numerous options and configuration issues. Collaborative web services and their security needs are expected to evolve as non-web businesses do. There is no any comprehensive or unified device or method that dynamically resolves and updates security options and configurations as web services evolve.
  • There are a number of industry initiatives to extend standards applicable to B2B and A2A electronic commerce. Choreography efforts include ebXML/BPSS from OASIS, WSFL from IBM, and XLANG from Microsoft. Conversation efforts include ebXML/TRP from OASIS and Microsoft's WS-routing. The dominant security effort is WS-security from IBM and Microsoft, there is also a complementary security effort in OASIS called SAML. For reliability, there are proposals from Microsoft, ebXML/TRP from OASIS, and HTTPR from IBM. W3C is addressing standardization in all of these areas. Key industry players have formed a rival consortium called WSI. However, they have not addressed the dynamic security negotiation issue.
  • Accordingly, an opportunity arises to develop methods and devices that dynamically resolve security option and configuration issues for trading partners.
  • SUMMARY OF THE INVENTION
  • The present invention relates to computer-based devices and methods negotiate and implement security arrangements between two or more web services. More particularly, it relates to devices and methods that specify input and output interfaces, computation and generation of a security contract consistent with inputs, and implementation of security in accordance with negotiated security arrangements. Particular aspects of the present invention are described in the claims, specification and drawings.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates communities and networks of communities, which are one environment in which computer-assisted, dynamic negotiation of security arrangements is useful.
  • FIG. 2 depicts negotiation and implementation of security arrangements.
  • FIG. 3 illustrates reconciling preferences among algorithm types.
  • FIG. 4 illustrates alternative embodiments for obtaining receiver's information when the sender is local to calculations of the security arrangements.
  • FIG. 5 illustrates one network of program logic and resources that can be used to implement aspects of the present invention.
  • DETAILED DESCRIPTION
  • The following detailed description is made with reference to the figures. Preferred embodiments are described to illustrate the present invention, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations on the description that follows.
  • FIG. 1 illustrates communities and networks of communities, which are one environment in which computer-assisted, dynamic negotiation of security arrangements is useful. Among these communities, a community maintains a local registry that includes information such as users, companies, services and connectors that are part of the community. The community can be a marketplace, an enterprise or a sub enterprise. Communities can belong to one or more community networks. Typically, communities and networks have some common business interest. Interoperation is between member communities in one or more community networks. The networks include a gold marketplace network 1, a precious metal marketplace network 2, a private network 3 and a global trading web network 4. In this illustration, the gold marketplace network 1 and the precious metal marketplace network 2 are contained within the global trading web network 4. The precious metals marketplace network 2 includes gold and silver marketplaces 14, 13. Gold marketplace customers can trade silver in the silver marketplace 13 and silver marketplace customers can trade in gold 14. One community, PQR Enterprise 17 belongs to the gold marketplace network 1, the private network 3 and the global trading web network 4; another community, ABC Big Supplier 18 belongs to the private network 3. In this illustration, XYZ Gold 14 is a marketplace or community for trading gold. Enterprises belong to this community. Enterprises like PQR Enterprise 17 that have formed a community by themselves belong to the gold marketplace network 1. These communities are part of the gold marketplace network 1, and the global trading web network 4. Small supplier 15 is part of the gold marketplace community. Other enterprises 16 are communities that are part of the gold marketplace community network 1. The connections between XYZ Gold 14 and other gold marketplace entities 15-17 indicate that the gold marketplace requires all traffic between enterprises (communities or otherwise) transacting gold trading to be routed through XYZ Gold 14, for instance, to collect billing and business intelligence information. PQR Enterprise 17 is a community is part of the gold marketplace and also part of local private network with supplier 18. Small supplier 15 may be an individual small supplier that does not want to form a community by itself and instead registers its metadata, such as users, organizations, services and transformations, in the registry of the gold marketplace. On the other hand, ABC Big Supplier 18 has formed a private network of its own, for instance because it wants to keep its metadata, internal back office systems and transformations hidden from general public access because they were developed at considerable cost. Because PRQ 17 is a customer of ABC 18, it participates in the private network 3. Financial service provider DEF Financial 12 wants to provide financial services to anyone in the global trading web network 4, such forms a community of its own and registers with the global trading web root 11. A network of communities makes available a global registry of communities. The global registry permits lookup of the community and determination of one or more routes to that community, or to external connectors through which the electronic commerce documents bound for the community may be routed. Documents routed from one community to another may be routed directly between external connectors for the two communities or indirectly through one or more intermediary communities. Business and security rules for transactions involving the communities also can be defined and maintained in community registries. In general, FIG. 1 illustrates the mixed loyalties of entities and communities that create an impetus for interoperability among electronic commerce platforms.
  • Connector is a general term for applications that communicate with other applications. Connectors may communicate on a peer-to-peer (P2P) basis or on a directed basis through other connectors that function as hubs, gateways, external ports, central connectors, etc. Connectors that communicate P2P are able to communicate with other connectors that use the same transport/envelope protocols. Connectors that communicate P2P optionally may enlist the assistance of other hub connectors that perform translation services, when trying to communicate with a connector that does not use the same transport/envelope protocol. Connectors that communicate on a directed basis communicate through hub connectors according to routing rules. Routing rules among connectors can be mapped in a directed graph, supporting one or more hub and spoke topologies for one or more transport/envelope protocols. A hub and spoke topology directs communications along spokes to hubs, in one or more tiers. This facilitates centralized services such as billing, business intelligence collection, tracking, auditing, accounting, or others. Multiple hub and spoke organizations may overlay the same connectors to support different transport/envelope protocols and technologies, as suggested by FIG. 2. For instance, a stronger hub and spoke organization may be required to use Sonic as a transport technology than to use HTTP or HTTPS. Optionally, communication routes may depend on whether the source and destination are part of the same community. Within a sub-community (which may include the whole community), centralized functions may be unneeded and P2P communications permitted among connectors that otherwise are directed to communicate with parent connectors when communicating with destinations in other sub-communities.
  • Connectors may be labeled simple connectors (sometimes simply called connectors), hubs (sometimes called gateways or routers) or central connectors. Alternatively, they may be described functionally. Simple connectors are directed to communicate via hub connectors, except when they are permitted to communicate P2P among connectors in the same sub-community. So-called hubs are used by connectors that are explicitly directed or linked to them. Hubs may serve more than one function and, accordingly, may appear more than once in a route from a source to a destination. Hubs forward electronic commerce documents or messages. Hubs also may translate among transport protocols that support a common envelope protocol. For instance, a hub may translate envelope protocols and also implement a different transport protocol upon transmission than upon receipt. A central connector is a special case of a hub, which can be used by connectors that are not explicitly directed or linked to them. A central connector is useful, for instance, to carry out translation functions when traversing connectors from a source according to routing rules does not lead to any hub that supports the transport/envelope protocol used by the destination.
  • A schema and a process flow provide an overview of security arrangements according to aspects of the present invention. In this context, negotiation of security arrangements is carried out by a computer-based process that uses security profiles of sending and receiving services to determine a mutually agreeable security arrangement. Preferably, this security arrangement is negotiated or potentially updated regularly, without user intervention. This arrangement may be negotiated, updated or checked for validity at a user request or without user intervention whenever messages are exchanged or on some other periodic or occasional basis, such as monthly, weekly, daily, on occurrence of an event that impacts exchange of messages between a particular sender and receiver (e.g., a software component failure or a change in security preferences), when a previously negotiated arrangement fails, or on some other periodic or occasional basis. The schema SecuritySenderReceiverInfo.XSD, in the source code appendix, describes some inputs to negotiation of security arrangements. The schema SecurityContract.XSD, also in the source code appendix, describes one embodiment of negotiated security arrangements, in a so-called security interoperability contract document (“SCID”). The process flow FIG. 1 can be used to describe negotiation and implementation of security arrangements.
  • The schema SecuritySenderReceiverInfo.XSD, in the source code appendix, can be used to validate a plurality input files to negotiation of security arrangements. In this embodiment, the machine-readable input files are XML documents. In other embodiments, other data structures may be used to store the same information, for instance a tree structure modeled after the XML code. The schema SecuritySenderReceiverInfo.XSD is best understood by loading the file into an integrated development environment (IDE) such as XML Spy TM, which provides several alternative views of the schema, including a documentation generation view. Sender and receiver security interoperability contract document information blocks are defined by this schema. Viewed in Spy's schema design view, SecuritySenderReceiverInfo.XSD includes several components that are used to define sender and receiver security information. The CommunitySecurityPolicyPreference component states the community preferences to sign the header, encrypt the credential, and credential preferences. It can be used to specify a default value for a whole community or it could be adapted to specify a default value for a collaboration partner (CP). The SAMsgSecurityPolicy component allows specification of signature and encryption preferences and authentication options. Message exchanged between services may have multiple parts. Signature and encryption policies can be applied to the whole message or individual parts. This approach can readily be extended to applying signature and encryption policies to elements within the parts. The PublicKeys component identifies key records for this CP. The ConnectorCapability component provides routing information to a resource that implements part of the security arrangement, such as a connector name. It includes connector capability parameters such as encryption capability, signature capability, an encryption public key party, and signing public key party. Public key party can be the sender's CP, the receiver's CP, or the owner of the connector, depending on whether signing or encryption is involved. If the public key party is not defined, the key of the message sender can be used for signing and the key of the message receiver can be used for encryption. The SecurityContainer component can be used to carry additional objects that are useful for security. The SendingCPSecurityPolicyProfile component includes the sending CP's available credentials information. The CPSendServicesSecurityPolicy and CPRecvServicesSecurityPolicy component include sets of security policies for the sending and receiving services, respectively. The services preferences and overrides can be defined here.
  • The schema SecurityContract.XSD, also in the source code appendix, can be used as a model for preparing a machine-readable security interoperability contract document. In this embodiment, the machine-readable document is an XML document. In other embodiments, other data structures may be used to store the same information, for instance a tree structure modeled after the XML code. This schema defines policies and channels for security policies. A security channel defines resources and routes to resources that carry out security algorithms, such as signature, encryption and authentication algorithms. It also may include non-repudiation and authorization resources.
  • The process flow FIG. 2 can be used to describe negotiation and implementation of security arrangements. In one embodiment, the preferences of the sending and receiving services are maintained in a registry 201. This registry may be accessible to the sending and receiving services, so that either service can compute security arrangements, or it may be available to a security arrangement computing service that is accessible to one or both of the sending and receiving services. The sending and receiving services may maintain their own registries. Or, a protocol may be developed for the sending and receiving services to exchange their security preferences as part of the negotiation of security arrangements. A registry 201 further may maintain information regarding default preferences of a collaboration partner that owns a service or a community to which a collaboration partner belongs, or both. Default preferences may be overridden by service-specific preferences, in general, or certain default preferences may be given precedence over service-specific preferences. Default preferences of collaboration partners may be treated differently than default preferences of the community. Input statements of security arrangement preferences are taken from the registry 201 or another source and acted upon by a security arrangements computing service 202. In one embodiment, this computing service is a security contract builder. A set of security arrangements are output 203. These arrangements may be confirmed with the sending and receiving services, may be subject to a veto by the sending or receiving service, or may be trusted by the sending and receiving services. The sending service or another service responsive to the sending service 205 uses the security arrangements 203 to process the document 204 for transmission to the receiving service 209. In some circumstances, the security arrangements will call for obtaining an assertion from a trusted assertion service 206. For instance, the sending and receiving services may agree to use a SAML service to generate authentication assertions. The security arrangement 203 would call for generation of a SAML assertion and the sending service 205 would obtain a SAML assertion from a SAML server 206. In another embodiment, an electronic notarization might be provided by a trusted service 206. Banks or security authorities might be trusted to generate authentication assertions, in a function analogous to notarization. In some circumstances, the security arrangements will call for obtaining public keys used in asymmetrical signing or encryption from a public keys source 208. For instance, the sending and receiving services may agree to use an XKMS service to exchange public keys. The security arrangement 203 would specify the XKMS service address as the source of public keys. The sending service 205 and the receiving service 209 both would access the agreed keys source 208. In accordance with the security arrangements 203 the sending service 205 communicates the document 204 through a network 207 to the receiving party 209. The routing and transport through the network 207 may be part of the security arrangements or, preferably, may be handled by a secure transport infrastructure. The security arrangements 203 may be provided by the computing service 202 to the receiving party 209 or otherwise made accessible to the receiving party, independent of the message carrying the document 204. Alternatively, the security arrangements 203 may be included with the document 204 according to a prearranged protocol. For instance, it may be part of the message header or it may be a separate part of the message. The prearranged protocol may call for the message header or message part to be signed and/or encrypted using the parties' respective keys. With this process flow and schemas above in mind, an example from the source code appendix may be explained.
  • The files SecuritySenderInfo.XML, SecurityReceiverInfo.XML, and ComputeSecurityContract.XML provide an example of sender and receiver preferences and a resulting computed security arrangement. The sender and receiver preferences are stated in XML code conforming to the XML schema explained above. The computed security arrangement is stated in an interoperability security contract document conforming to the SecurityContract.XSD schema in the source code appendix.
  • In this example, the sender preferences information includes community preferences and service preferences. The community preferences address security algorithms, preferences to sign the header, encrypt the credential and for selection among available credentials. The community preferences also may rank order the security algorithms or otherwise indicate preference among the security algorithms. A similar set of preferences might be provided for a collaboration partner, either instead of more in addition to preferences for a community. In this example, the community has six sets of signature algorithms options in elements named XMLSignatureAlgorithmTemplate and three sets of encryption algorithms options in elements named XMLEncryptionAlgorithmTemplate. These sets of options are templates. More than one template of options can be provided for a particular algorithm. Use of templates simplifies configuration of options and increases the likelihood consistent option sets will be selected by sending and receiving services. The community in this example prefers not to sign headers or encrypt credentials and accepts basic credentials. In general, a community or a collaboration partner may have preferences for any security arrangement options that the service can select, or the community or collaboration partner may have preferences for only some options. Community preferences in a sender's preference file should correspond to community preferences stated elsewhere, such as in a registry entry for community preferences. The file CommunitySecurityTemplatesPreferences.XML is an example of a file used to record some or all of a community's security preferences.
  • The service (sending service in this example) records in SAMsgSecurityPolicy its preferences for handling message parts, for signature and encryption of the message as a whole, and for authentication. Messages may have several parts. Corresponding to a message part, a service may identify the message part and express a preference for signing or not signing or for encrypting or not encrypting a message part. In this embodiment, a preference for a category of algorithm, such as a general algorithm or in XML-specific algorithm can be selected. In other embodiments, the service might not specify a category of algorithm or it might specify a specific algorithm.
  • Other arrangements for security are also covered by this example. The receiver's (buyer's) public key, in an X509 format, is use for signature and authentication. Two resources, so-called connectors, are identified for the sending service to use for signing and encryption. The sender's available credentials are identified as basic and X509 credentials. The sending service's security arrangement preferences are rank ordered from one to three under SecurityPolicyTemplatePreference. In this example, the three encryption preferences are all for XML-specific encryption. These and other details of this example are found in the source code appendix file SecuritySenderInfo.XML.
  • Receiving party preferences are found in the source code appendix file SecurityReceiverInfo.XML. In general, the elements of the receiving party's preference profile are very similar to those of the sending party, even using the same element types from the schema. Significant differences are found in authentication and authorization, since the logic applicable to authentication and authorization depends on whether you are presenting your credentials or determining whether to accept what is presented. For instance, the SendingCPSecurityProfile of the sending party lists available credentials. This element is not part of the receiving party's preferences. This issue is addressed by the receiving party's CPRecvServicesSecurityPolicy, which identifies AcceptedCredentials.
  • In this example, two types of preferences are stated that the security arrangements logic reconciles. One type of preferences is among algorithm templates. The element SecurityPolicyTemplatePreference appears twice in each of the sending and receiving services' preferences, setting forth community and service-specific preferences among algorithms. FIG. 3 illustrates reconciling preferences among algorithm types. Stacks 301 and 302 represent sending and receiving preferences. Suppose A is the most secure and G the least secure. In the two preference stacks 301, 302, preference B and D match. A decision rule for choosing between B or D might take into account one or both stacks of preferences. For instance, the receiving service's preference (D) for signature or the sending service's preference (B) for encryption might be selected from among the matches. Taking both preferences into account, the most secure (B) or the least secure (D) might be selected. In another embodiment, the respective services might weight or score their preferences and a combined weighting or score may be used to take into account both preferences. The second type of preferences is for whether or not to sign or encrypt a part of a message. What to sign or encrypt is addressed by the SAMsgPart elements of SAMsgSecurityPolicy. The message parts in the example are Order and Image. In this example, sender and receiver preferences match, for signing and encrypting the Order and only encrypting the Image. Preferences would not match if the receiver wanted the Image signed, as well as the Order. Then, a decision rule would be needed to resolve the mismatch. The available decision rules could include: receiver wins, sender wins, highest requirement wins or lowest requirement wins. One type of preference reconciliation determines whether to apply a security measure. The other type selects among option templates, when the security measure is applied.
  • A set of computed security arrangements for this example appear in ComputeSecurityContract.XML, which is partially reproduced below:
  • <SecurityContractICD ... >
     <SecurityPolicies>
      <SignaturePolicies>
       <XMLDsigPolicy PolicyId=“P-XMLSignatureRSA-MD5-C14N”>
       <SignaturePolicyAlgorithm>...</SignaturePolicyAlgorithm>
        <SignatureAlg...>MD5withRSA</SignatureAlg...>
        <HashFunction>MD5</HashFunction>
        <Canonical ...>...14n-20001026</Canonical ...>
        <Transform>...#RoutingSignatureT...</Transform>
       </XMLDsigPolicy>
      </SignaturePolicies>
      <EncryptionPolicies>
       <XMLEncryptionPolicy PolicyId=“P-XMLEncrypt3DES-RSA-
       2048”>
     <EncryptionPolicyAlgorithm>http://www.w3.org/2001/04/xmlenc#
    </EncryptionPolicyAlgorithm>
        <EncryptionMethod>http://www.w3.org/2001/04/xmlenc#3des-
    cbc</EncryptionMethod>
        <KeySize>2048</KeySize>
     <KeyEncryptionMethod>http://www.w3.org/2001/04/xmlenc#rsa-
    1_5</KeyEncryptionMethod>
       </XMLEncryptionPolicy>
      </EncryptionPolicies>
      <EncryptionKeyInfo KeyOwner=“x-
    ccns:commerceone.com:CollaborationParty::sellParty”>
       <PublicKeyID>DefaultTestCert</PublicKeyID>
       <X509Data>      <X509Certificate>LS0tLS1... ==
       </X509Certificate>
       </X509Data>
      </EncryptionKeyInfo>
     </SecurityPolicies>
     <SecurityChannel channelId=“CHANNEL1” sourceConnector=“x-
    ccns:cup.commerceone.com:connector::centerSell” targetConnector=“x-
    ccns:cup.commerceone.com:connector::centerSell”>
      <Confidential AlgorithmId=“P-XMLEncrypt3DES-RSA-2048”>
       <PublicKeyName KeyOwner=“x-
    ccns:commerceone.com:CollaborationParty::sellParty”>DefaultTestCert
    </PublicKeyName>
       <MessagePart PartName=“Order” isOptional=“false”/>
       <MessagePart PartName=“Image” isOptional=“false”/>
      </Confidential>
     </SecurityChannel>
     <SecurityChannel channelId=“CHANNEL2” sourceConnector=“x-
    ccns:cup.commerceone.com:connector::buy” targetConnector=“x-
    ccns:cup.commerceone.com:connector::sell”>
      <Integrity AlgorithmId=“P-XMLSignatureRSA-MD5-C14N”>
       <PublicKeyName
    KeyOwner=“OwnerA”>BuyerPublicKey</PublicKeyName>
       <MessagePart PartName=“Order” isOptional=“false”/>
      </Integrity>
     </SecurityChannel>
    </SecurityContractICD>

    This set of security arrangements has two major sections for security policy and security channels. In this example, there is one security policy applicable to the entire message and multiple security channels to implement parts of the security policy. The security policy section sets out the signature policy, and encryption policy and encryption key information. It also may set out policies regarding authentication, authorization and non-repudiation of origin or receipt. In this embodiment, the same signature and encryption policy is applied to all parts of the document. In other embodiments, multiple algorithms could be applied to different parts. The algorithm selected for signature, encryption and authentication are abstracted through templates containing options sets, simplifying the selection of algorithms. Selected algorithms are associated with logic and resources, so different services or processes can be used for signing/verifying and encrypting/decrypting different parts of a message. A public key or certificate can be transmitted in the encryption key element of the security policy section. The security channel section describes services or connectors involved in applying security policies. For a particular policy, the channel section identifies a source connector that requires assistance in applying a security policy (e.g., the sending service requesting encryption), and a target connector that applies the security policy or acts as an intermediary to logic and resources that apply the security policy. For a particular security policy, such as signing, encryption, authentication, authorization or non-repudiation, specific information required to carry out the security policy is provided in the security channel section.
  • The data used to determine security arrangements can be categorized as message and activity related data, CP-service related data, security algorithms related data, routing related data, encryption key related data and configuration data. Some additional detail regarding use of these categories of is described below. Message and activity related data relates to digital signatures, encryption, non-repudiation, and authorization. For non-repudiation, a receiver may require non-repudiation measures for a sender, amounting to a trusted party verification of the sender's message to receiver. Similarly, a sender may require non-repudiation measures for a receiver, amounting to a trusted party verification of receipt of sender's message by the receiver. Beyond the description above, it should be mentioned that signatures and encryption can be applied on an element basis, to particular items of data, if fine granularity is desired. In addition, overrides can be specified for pairs of sending and receiving services. For instance, a pre-existing or proven relationship can be treated differently than an entirely new relationship. Overrides to security policies can be implemented to cautiously reduce (or increase, as warranted) security requirements in particular cases.
  • CP-related data includes authentication and authorization data. Authorization is the process of granting or denying access to a network resource. Authorization to access most computer security systems is a two-step process. The first stage is authentication, which ensures that a principal (user, process, application or service) is who it claims to be. The second stage is authorization, which allows the principal access to various resources based on their identity. Authorization is also called access control. Access control is used to authorize access to website resources. It manages information about users, groups of users, and the roles assigned to users. SAML provides an XML-based means to share information about security events (authentication and authorization) and attributes (e.g. credit rating) in a SOAP message. This SAML data can then be sent to a third-party, and this enables ‘distributed trust’, whereby the user signs on once, but can re-use their authentication or authorization details. With SAML or a similar trusted party technology, the issuing authority decides whether to grant the request by subject services or sender, for access type to resource web service, given the evidence provided by the requestor. The authorization decision allows or denies a subject access to a specific resource. SAML is useful option for web services security, but it requires an initial degree of trust and technical resources. In instances when SAML is unavailable or not preferred, other approaches such as ID/password and a table of privileges associated with an ID can be used. The present invention is not limited by the authorization technology used, but extends more abstractly to selection among presently available or hereafter invented technologies. With either SAML authorization or ID/password technologies, the authorization data can be encrypted and built into the message.
  • Security algorithms related data includes algorithms and configuration options for signature, encryption and non-repudiation. As the schema illustrates, signature algorithms options (XML or non-XML) may include use of XMLDsig, choice of a Canonicalization algorithm, a signature method and a digest algorithm. Encryption/decryption options (XML or non-XML) may include key size, key and method. Default may be inherited by a service, either overriding the services preferences or being overridden. In addition, specific overrides can be specified for CP pairs, as described above. Option templates, also described above, simplify negotiation of security arrangements. Different options will apply to XML and non-XML algorithms, signature algorithms for example. XML signature algorithms, e.g., XMLDisg, my offer options for method, Canonicalization, transform and digest, while non-XML algorithms, e.g., PCKS#7, may have options for signature and digest methods, only. Use of community standard security templates are preferred, to ensure that there is at least one match between preference lists of the respective services. A community may require all CP's or all services operating in the community to support a particular community standard security option set, to assure that messages can be exchanged within the community.
  • Routing related data includes how to access logic and resources that implement authentication/verification, signing/verification, and encryption/decryption. Any type of access information may be used, such as a universal resource name (URN) or universal resource locator (URL). As discussed in one of the prior applications referred to above, a message may take multiple hops through connectors for translation or other value-added services. Accordingly, multiple route steps may be associated with any action. Security typically will need to be reapplied after any translation or other value-added service.
  • Encryption key related data is generally discussed above.
  • Configuration data includes default (e.g., community or collaboration partner) preferences and credential preferences.
  • FIG. 4 illustrates alternative embodiments for obtaining receiver's information when the sender is local to calculations of the security arrangements. In the figure, local 431 and remote 432 registries are indicated. In this example, the sender is local and the receiver remote. The sender's data is current and complete in the local registry 431. The sender's information is collected 421 and made available to the logic and resources that compute the security arrangements 411. The receiver's data may be current and complete, for instance if the receiver is in the same community as the sender and there is a community-wide registry, or if the receiver's information has been recently obtained and locally cached. Depending on where the receiver's information can be found, 431 or 432, a process 422 or 423 is invoked to collect the receiver information and make it available to the logic that computes security arrangements. A set of security arrangements 401 result.
  • FIG. 5 illustrates one network of program logic and resources that can be used to implement aspects of the present invention. The logic components of this network include: send side collection 551, receive side collection 552, data object manager 541, routing manager 542, credential negotiator 531, template negotiator 532, connector manager 533, authentication manager 521, policy manager 522, public key manager 523, algorithm manager 524, policy builder 511, channel builder 512 and security arrangements document builder 501.
  • One embodiment of program logic operative in a community of collaboration partners to generate security arrangements can be described as follows: Collect the receiver security information, including an attribute assertion to authenticate the sender CP. Collect the sender security information. Look into routing block to find all connectors information to implement security measures. Get capability parameters for each connector. Walk through the routing chain to find which connector-pair to use for authentication, signature, and encryption. Get the recever's service-activity-message object. This may include getting a SAMsgSecurityPolicy object from the receiver. This will have multiple parts and it can have signature and encryption policies for the whole message. It also may include getting a SAMsgSecurityPolicy object from the sender, and match the override options the SAMsgSecurityPolicy object accordingly. (Override decision tables are discussed below.) From the SAMsgSecurityPolicy object, find all algorithms required for this message, and build RequiredAlgorithmList. Get community preference objects for both SenderInfo and ReceiverInfo. This may include getting a CommunitySecurityTemplatesPreference object of the sender, which includes security algorithm templates, and community security policy preferences. It also may include getting a CommunitySecurityTemplatesPreference object of the receiver, if not the same community. If they are in the same community, it may be sufficient to set an object pointer. Get CP-Service objects for both sender and receiver services and get CP objects for corresponding communities. This may include building the CPSecurityPolicyPreference of the sender and receiver. Based on the sender and receiver preferences and the decision rules in a RequiredAlgorithmList, select from the preference lists, and build a RequiredTemplateObjectList. If the services' respective preference list do not match on any algorithm, community defaults may generate a match. Get a ServiceAuthentication object for the receiver service. This will have one or more authentication method specified, including accepted credentials and authentication mode. Match the credential from ServiceAuthentication object and available credentials from CPSecurityPolicyPreference of the sender. If there is more than one match, then get the one that matches CredentialPreference from CPSecurityPolicyPreference of the receiver, or from CommunitySecurityTemplatesPreference corresponding to the receiver. Get the value of SignMessageHeader and EncryptCredential from either the CPSecurityPolicyPreference of the receiver or from CommunitySecurityTemplatesPreference object of the receiver. If no value is specified in either place, set it to a default such as false or true. Using the available sender's credential selected by the receiver, the authentication mode specified in the ServiceAuthentication object for the Receiver the SignMessageHeader Boolean attribute, and the EncryptCredential to build the authentication algorithm. Base on the connector's PublicKeyCapability to get the proper key. This may include getting the encryption key of the sender, if an encryption is required, and getting signature key ID of the receiver, if a signature is required. Get the authentication key ID of the receiver, if an X509 authentication is required. Build the policy section of the security arrangements. Find the connector for the channel section and build the channel section of the security arrangements.
  • Decision tables may be used to implement the type of preference reconciliation related to whether to sign or encrypt part of a message. Again, decisions could be biased to accept preference not to sign or to accept the receiver's preference, or just the opposite. Some decision tables that could be used to implement possible decision rules follow:
  • Sender Preference
    Signature Signature
    Required Optional No Signature
    Receiver Signature Sign Sign Error
    Preference Required
    Signature Sign Don't Sign Don't Sign
    Optional
    No Signature Error Don't Sign Don't Sign
  • Sender
    Encryption Encryption
    Required Optional No Encryption
    Receiver Encryption Encrypt Encrypt Error
    Required
    Encryption Encrypt Don't Don't Encrypt
    Optional Encrypt
    No Encryption Error Don't Don't Encrypt
    Encrypt
  • Sender
    Signature Signature
    Required Optional No Signature
    Receiver Signature Sign Sign Sign
    Required
    Signature Sign Don't Sign Don't Sign
    Optional
    No Signature Don't Sign Don't Sign Don't Sign
  • Sender
    Encryption Encryption
    Required Optional No Encryption
    Receiver Encryption Encrypt Encrypt Encrypt
    Required
    Encryption Encrypt Don't Encrypt Don't Encrypt
    Optional
    No Don't Don't Encrypt Don't Encrypt
    Encryption Encrypt
  • The present invention is readily extended to support signing and encryption at intermediate connectors along a path between a sender and receiver. It is useful to be able to sign and encrypt documents at connectors along a routing path that are not the message originators or final receivers. This may be useful for gateways, routers and central connectors. For gateways, signing and encryption may need to be performed by a gateway if signed/encrypted message data is transformed from one envelope protocol to another. For routers and central connectors, it may be desirable to use a single entry/exit point into the enterprise for external communities. A router or central connector may act as the central security hub and perform or organize security operations on behalf of the entire enterprise. This may simplifies the PKI management and other administrative burdens. This functionality can be configured by setting up the security capabilities of connectors in the enterprise's part of a community. A connector can be configured on an envelope/transport protocol basis to have signing capability or encryption capability and can be linked to signing and encryption capabilities of the collaboration partner at other connectors. In the case of gateways and routers, you could configure the connector to use the key of the CP owner or the gateway/router connector.
  • From the preceding description, it will be apparent to those of skill in the art that a wide variety of systems and methods can be constructed from aspects and components of the present invention. One embodiment is a method of dynamically determining security options for exchange of one or more messages between sending and receiving services. This method uses sender and receiver security preferences, which may take the form of machine security profiles for first and second services. The security profiles may identify security options/elements and option subsets that are acceptable to the respective services. The options may include requirements to sign or encrypt one or more parts of the message, signing option subsets corresponding to one or more signing algorithms, encryption option subsets corresponding to one or more encryption algorithms, identification of signing and encryption keys and identification of an authentication algorithm. The dynamic method includes accessing the security profiles and selecting a particular option set that is acceptable to the respective services. Optionally, this option set can be used to communicate a message between the respective services. Several options and aspects of the present invention can be added to this embodiment. Security profiles can be maintained in one or more registries that are accessible to security logic of the first and second services. Default option subsets and/or preferences can be specified in community or collaboration partner security profiles and may be copied into service security profiles. Requirements to sign or encrypt can be applied to the parts of the message or to a message as a whole. Signature and encryption algorithms may be applied to a message as a whole, reducing complexity. Signing and encryption keys may be symmetrical or asymmetrical. Authentication may be carried out by a trusted agent, such as a SAML server, before communicating the message between the respective services. Authentication by a trusted agent may be evidenced by authentication assertion. Alternatively, authentication may include submitting credentials for examination by the receiving service. These credentials may be part of the message or may be transmitted in addition to the message. In addition to authentication, authorization may be addressed by security arrangements. The security profiles may include identification of at least one authorization algorithm to establish a sending service's privileges. This authorization may be implemented by a trusted agent before communicating the message or by submitting credentials to the service receiving the message. A further aspect of the present invention is taken into account preferences of the respective services among option subsets for signing and/or encryption. Preferences of one or both of the services may be taken into account. Any of the decision rules discussed above may be applied, including receiver wins, sender wins, most secure wins, least secure wins or a weighted factoring of both services' preferences. Determination of security arrangements may include determining resources to be used by the respective parties to implement any combination of signatures, encryption, authentication, authorization or non-repudiation. Resources, algorithms and option says may be packaged into security channels. A security channel may implement a single aspect of security.
  • While the present invention is disclosed by reference to the preferred embodiments and examples detailed above, it is understood that these examples are intended in an illustrative rather than in a limiting sense. Computer-assisted processing is implicated in the described embodiments. Accordingly, the present invention may be embodied in methods for computer-assisted processing, systems including logic to implement the methods, media impressed with logic to carry out the methods, data streams impressed with logic to carry out the methods, or computer-accessible processing services. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the invention and the scope of the following claims.

Claims (19)

1-31. (canceled)
32. A method of dynamically determining security options for exchange of at least one message between services, comprising the steps of:
providing a computer-readable security option profile data structure stored in memory for a first service;
obtaining a computer-readable security option profile data structure for a second service;
wherein the security option profiles include
preference sets, divided into community preferences and service preferences, applicable to communities of collaboration partners and individual collaboration partners, respectively, each preference set including
algorithm preferences for selecting among security arrangement algorithms;
security arrangement preferences for selecting among security arrangements; and
rules for categorizing, prioritizing and comparing preference sets;
receiving a message at the first service from the second service; and
employing the rules to determine security algorithms and arrangements between the first and second services.
33. The method of claim 32, wherein community preferences override service preferences.
34. The method of claim 32, wherein preferences can apply to one or more portions of a message.
35. The method of claim 32, wherein preferences can be categorical or specific.
36. The method of claim 32, wherein algorithm preferences include signature algorithm preferences.
37. The method of claim 32, wherein algorithm preferences include encryption algorithm preferences.
38. The method of claim 32, wherein algorithm preferences include authentication algorithm preferences.
39. The method of claim 32, wherein security arrangement preferences include signature arrangement preferences.
40. The method of claim 32, wherein security arrangement preferences include encryption arrangement preferences.
41. The method of claim 32, wherein security arrangement preferences include authentication arrangement preferences.
42. The method of claim 32, wherein one or more steps are carried out by a third service provider.
43. The method of claim 32, wherein one or more steps are carried out by a trusted party service provider.
44. The method of claim 32, wherein the rules include an algorithm for determining preferences among competing standards.
45. The method of claim 32, wherein the rules include weighting factors.
46. The method of claim 32, wherein the rules include weighting factors favoring the service receiving the message.
47. The method of claim 32, wherein the rules include weighting factors favoring the service sending the message.
48. The method of claim 32, wherein the rules include weighting factors favoring the community of the service receiving the message.
49. The method of claim 32, wherein the rules include weighting factors favoring the community of the service sending the message.
US10/246,276 2002-09-18 2002-09-18 Dynamic negotiation of security arrangements between web services Expired - Fee Related US7444522B1 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US10/246,276 US7444522B1 (en) 2002-09-18 2002-09-18 Dynamic negotiation of security arrangements between web services
AU2003263904A AU2003263904B2 (en) 2002-09-18 2003-08-19 Dynamic negotiation of security arrangements between web services
JP2004537673A JP2005539453A (en) 2002-09-18 2003-08-19 Dynamic negotiation of security configuration between web services
EP03797854A EP1540479A4 (en) 2002-09-18 2003-08-19 Dynamic negotiation of security arrangements between web services
CNB038251655A CN100342347C (en) 2002-09-18 2003-08-19 Dynamic negotiation of security arrangements between web services
KR1020057004614A KR100970771B1 (en) 2002-09-18 2003-08-19 Dynamic negotiation of security arrangements between web services??? ??
PCT/US2003/025894 WO2004027618A1 (en) 2002-09-18 2003-08-19 Dynamic negotiation of security arrangements between web services
JP2011177761A JP4892640B2 (en) 2002-09-18 2011-07-28 Dynamic negotiation of security configuration between web services

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/246,276 US7444522B1 (en) 2002-09-18 2002-09-18 Dynamic negotiation of security arrangements between web services

Publications (2)

Publication Number Publication Date
US20080256364A1 true US20080256364A1 (en) 2008-10-16
US7444522B1 US7444522B1 (en) 2008-10-28

Family

ID=32028951

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/246,276 Expired - Fee Related US7444522B1 (en) 2002-09-18 2002-09-18 Dynamic negotiation of security arrangements between web services

Country Status (7)

Country Link
US (1) US7444522B1 (en)
EP (1) EP1540479A4 (en)
JP (2) JP2005539453A (en)
KR (1) KR100970771B1 (en)
CN (1) CN100342347C (en)
AU (1) AU2003263904B2 (en)
WO (1) WO2004027618A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050120121A1 (en) * 2001-03-30 2005-06-02 Microsoft Corporation Service routing and web integration in a distributed, multi-site user authentication system
US20050204041A1 (en) * 2004-03-10 2005-09-15 Microsoft Corporation Cross-domain authentication
US20080141336A1 (en) * 2006-12-08 2008-06-12 Jochen Haller Secure execution environments for process models
US20090012987A1 (en) * 2007-07-05 2009-01-08 Kaminsky David L Method and system for delivering role-appropriate policies
US20090187988A1 (en) * 2008-01-18 2009-07-23 Microsoft Corporation Cross-network reputation for online services
US20090204808A1 (en) * 2002-05-15 2009-08-13 Microsoft Corporation Session Key Security Protocol
US7685631B1 (en) 2003-02-05 2010-03-23 Microsoft Corporation Authentication of a server by a client to prevent fraudulent user interfaces
US20100146582A1 (en) * 2008-12-04 2010-06-10 Dell Products L.P. Encryption management in an information handling system
WO2013048828A1 (en) * 2011-09-30 2013-04-04 Comprehend Systems, Inc. Systems and methods for generating schemas that represent multiple data sources
US8924431B2 (en) 2011-09-30 2014-12-30 Comprehend Systems, Inc. Pluggable domain-specific typing systems and methods of use
US20160043868A1 (en) * 2014-08-05 2016-02-11 Frank Oliver Hoffmann End-to-end tamper protection in presence of cloud integration

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7451107B1 (en) * 2000-01-28 2008-11-11 Supply Chain Connect, Llc Business-to-business electronic commerce clearinghouse
US8561161B2 (en) * 2002-12-31 2013-10-15 International Business Machines Corporation Method and system for authentication in a heterogeneous federated environment
US20060010251A1 (en) * 2004-06-16 2006-01-12 Nokia Corporation Global community naming authority
JP4455418B2 (en) * 2005-06-13 2010-04-21 キヤノン株式会社 Communication parameter setting method and communication apparatus
US20060294383A1 (en) * 2005-06-28 2006-12-28 Paula Austel Secure data communications in web services
US20070276948A1 (en) * 2006-05-24 2007-11-29 Sap Ag System and method for automated configuration and deployment of applications
US8122500B2 (en) * 2006-06-23 2012-02-21 International Business Machines Corporation Tracking the security enforcement in a grid system
US20080208806A1 (en) * 2007-02-28 2008-08-28 Microsoft Corporation Techniques for a web services data access layer
US20090099882A1 (en) * 2007-10-15 2009-04-16 Sap Ag Enhanced Security Framework for Composite Applications
US8396806B2 (en) * 2007-10-30 2013-03-12 Red Hat, Inc. End user license agreements associated with messages
US8572691B2 (en) * 2008-07-17 2013-10-29 International Business Machines Corporation Selecting a web service from a service registry based on audit and compliance qualities
CN101325483B (en) * 2008-07-28 2011-06-15 中国电信股份有限公司 Method and apparatus for updating symmetrical cryptographic key, symmetrical ciphering method and symmetrical deciphering method
US8732094B2 (en) 2010-07-30 2014-05-20 Hewlett-Packard Development Company, L.P. Enforcement of security requirements for a business model
JP5490157B2 (en) * 2012-02-02 2014-05-14 株式会社エヌ・ティ・ティ・データ Profile generation apparatus and profile generation method
JP6066586B2 (en) * 2012-05-22 2017-01-25 キヤノン株式会社 Information processing system, control method thereof, and program thereof
US9009817B1 (en) 2013-03-12 2015-04-14 Open Invention Network, Llc Virtual smart card to perform security-critical operations
US9032505B1 (en) 2013-03-15 2015-05-12 Wells Fargo Bank, N.A. Creating secure connections between distributed computing devices
US10432592B2 (en) * 2015-05-10 2019-10-01 Citrix Systems, Inc. Password encryption for hybrid cloud services
US9471404B1 (en) 2015-10-07 2016-10-18 International Business Machines Corporation Enriching API registry using big data analytics

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5157726A (en) * 1991-12-19 1992-10-20 Xerox Corporation Document copy authentication
US5159630A (en) * 1991-05-29 1992-10-27 International Communication Systems Corporation Facsimile message encryption system
US5557798A (en) * 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5784566A (en) * 1996-01-11 1998-07-21 Oracle Corporation System and method for negotiating security services and algorithms for communication across a computer network
US5790677A (en) * 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
US5935248A (en) * 1995-10-19 1999-08-10 Fujitsu Limited Security level control apparatus and method for a network securing communications between parties without presetting the security level
US6049785A (en) * 1993-12-16 2000-04-11 Open Market, Inc. Open network payment system for providing for authentication of payment orders based on a confirmation electronic mail message
US6148290A (en) * 1998-09-04 2000-11-14 International Business Machines Corporation Service contract for managing service systems
US6226746B1 (en) * 1998-03-20 2001-05-01 Sun Microsystems, Inc. Stack-based system and method to combine security requirements of methods
US6389533B1 (en) * 1999-02-05 2002-05-14 Intel Corporation Anonymity server
US20030074579A1 (en) * 2001-10-16 2003-04-17 Microsoft Corporation Virtual distributed security system
US20030208505A1 (en) * 2002-05-03 2003-11-06 Ward Mullins Dynamic class inheritance and distributed caching with object relational mapping and cartesian model support in a database manipulation and mapping system
US6671695B2 (en) * 2001-06-18 2003-12-30 The Procter & Gamble Company Dynamic group generation and management
US6732101B1 (en) * 2000-06-15 2004-05-04 Zix Corporation Secure message forwarding system detecting user's preferences including security preferences
US7219223B1 (en) * 2002-02-08 2007-05-15 Cisco Technology, Inc. Method and apparatus for providing data from a service to a client based on encryption capabilities of the client

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5005200A (en) 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5311438A (en) 1992-01-31 1994-05-10 Andersen Consulting Integrated manufacturing system
US5224166A (en) 1992-08-11 1993-06-29 International Business Machines Corporation System for seamless processing of encrypted and non-encrypted data and instructions
US5539828A (en) * 1994-05-31 1996-07-23 Intel Corporation Apparatus and method for providing secured communications
US5812669A (en) 1995-07-19 1998-09-22 Jenkins; Lew Method and system for providing secure EDI over an open network
US5757915A (en) * 1995-08-25 1998-05-26 Intel Corporation Parameterized hash functions for access control
US6115744A (en) 1996-07-30 2000-09-05 Bea Systems, Inc. Client object API and gateway to enable OLTP via the internet
US6072942A (en) 1996-09-18 2000-06-06 Secure Computing Corporation System and method of electronic mail filtering using interconnected nodes
US6425119B1 (en) 1996-10-09 2002-07-23 At&T Corp Method to produce application oriented languages
US5941945A (en) 1997-06-18 1999-08-24 International Business Machines Corporation Interest-based collaborative framework
ES2175936T3 (en) * 1998-01-16 2002-11-16 Macrovision Corp SYSTEM AND METHOD TO AUTHENTICATE HOMOLOGICAL COMPONENTS.
US6393442B1 (en) 1998-05-08 2002-05-21 International Business Machines Corporation Document format transforations for converting plurality of documents which are consistent with each other
US6269380B1 (en) 1998-08-31 2001-07-31 Xerox Corporation Property based mechanism for flexibility supporting front-end and back-end components having different communication protocols
US6125391A (en) 1998-10-16 2000-09-26 Commerce One, Inc. Market makers using documents for commerce in trading partner networks
US6463460B1 (en) 1999-04-23 2002-10-08 The United States Of America As Represented By The Secretary Of The Navy Interactive communication system permitting increased collaboration between users
FI108373B (en) * 1998-12-16 2002-01-15 Sonera Smarttrust Oy Procedures and systems for realizing a digital signature
US6538673B1 (en) 1999-08-23 2003-03-25 Divine Technology Ventures Method for extracting digests, reformatting, and automatic monitoring of structured online documents based on visual programming of document tree navigation and transformation
US6434628B1 (en) 1999-08-31 2002-08-13 Accenture Llp Common interface for handling exception interface name with additional prefix and suffix for handling exceptions in environment services patterns
AU1450501A (en) 1999-11-02 2001-05-14 Commerce One Operations Inc Commerce community schema for the global trading web
US6636889B1 (en) 2000-01-04 2003-10-21 International Business Machines Corporation System and method for client replication of collaboration space
DE10024347B4 (en) * 2000-05-17 2007-02-22 Fujitsu Limited, Kawasaki Security service layer
JP2001325172A (en) * 2000-05-17 2001-11-22 Fujitsu Ltd Communication setting management system
GB0027280D0 (en) * 2000-11-08 2000-12-27 Malcolm Peter An information management system
JP2002261839A (en) * 2001-02-28 2002-09-13 Fujitsu Ltd System for managing communication security and its program
JP4390405B2 (en) * 2001-05-31 2009-12-24 富士通株式会社 Computer system, service layer, policy cache function unit, and policy management device
US20030046583A1 (en) 2001-08-30 2003-03-06 Honeywell International Inc. Automated configuration of security software suites

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557798A (en) * 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5159630A (en) * 1991-05-29 1992-10-27 International Communication Systems Corporation Facsimile message encryption system
US5157726A (en) * 1991-12-19 1992-10-20 Xerox Corporation Document copy authentication
US6049785A (en) * 1993-12-16 2000-04-11 Open Market, Inc. Open network payment system for providing for authentication of payment orders based on a confirmation electronic mail message
US5790677A (en) * 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
US5935248A (en) * 1995-10-19 1999-08-10 Fujitsu Limited Security level control apparatus and method for a network securing communications between parties without presetting the security level
US5784566A (en) * 1996-01-11 1998-07-21 Oracle Corporation System and method for negotiating security services and algorithms for communication across a computer network
US6226746B1 (en) * 1998-03-20 2001-05-01 Sun Microsystems, Inc. Stack-based system and method to combine security requirements of methods
US6148290A (en) * 1998-09-04 2000-11-14 International Business Machines Corporation Service contract for managing service systems
US6389533B1 (en) * 1999-02-05 2002-05-14 Intel Corporation Anonymity server
US6732101B1 (en) * 2000-06-15 2004-05-04 Zix Corporation Secure message forwarding system detecting user's preferences including security preferences
US6671695B2 (en) * 2001-06-18 2003-12-30 The Procter & Gamble Company Dynamic group generation and management
US20030074579A1 (en) * 2001-10-16 2003-04-17 Microsoft Corporation Virtual distributed security system
US7219223B1 (en) * 2002-02-08 2007-05-15 Cisco Technology, Inc. Method and apparatus for providing data from a service to a client based on encryption capabilities of the client
US20030208505A1 (en) * 2002-05-03 2003-11-06 Ward Mullins Dynamic class inheritance and distributed caching with object relational mapping and cartesian model support in a database manipulation and mapping system

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050120121A1 (en) * 2001-03-30 2005-06-02 Microsoft Corporation Service routing and web integration in a distributed, multi-site user authentication system
US7810136B2 (en) 2001-03-30 2010-10-05 Microsoft Corporation Service routing and web integration in a distributed, multi-site user authentication system
US7971240B2 (en) 2002-05-15 2011-06-28 Microsoft Corporation Session key security protocol
US20090204808A1 (en) * 2002-05-15 2009-08-13 Microsoft Corporation Session Key Security Protocol
US7685631B1 (en) 2003-02-05 2010-03-23 Microsoft Corporation Authentication of a server by a client to prevent fraudulent user interfaces
US8776199B2 (en) 2003-02-05 2014-07-08 Microsoft Corporation Authentication of a server by a client to prevent fraudulent user interfaces
US7636941B2 (en) * 2004-03-10 2009-12-22 Microsoft Corporation Cross-domain authentication
US8689311B2 (en) 2004-03-10 2014-04-01 Microsoft Corporation Cross-domain authentication
US7950055B2 (en) 2004-03-10 2011-05-24 Microsoft Corporation Cross-domain authentication
US20050204041A1 (en) * 2004-03-10 2005-09-15 Microsoft Corporation Cross-domain authentication
US9111276B2 (en) * 2006-12-08 2015-08-18 Sap Se Secure execution environments for process models
US20080141336A1 (en) * 2006-12-08 2008-06-12 Jochen Haller Secure execution environments for process models
US20090012987A1 (en) * 2007-07-05 2009-01-08 Kaminsky David L Method and system for delivering role-appropriate policies
US8001582B2 (en) 2008-01-18 2011-08-16 Microsoft Corporation Cross-network reputation for online services
US8484700B2 (en) 2008-01-18 2013-07-09 Microsoft Corporation Cross-network reputation for online services
US20090187988A1 (en) * 2008-01-18 2009-07-23 Microsoft Corporation Cross-network reputation for online services
US20100146582A1 (en) * 2008-12-04 2010-06-10 Dell Products L.P. Encryption management in an information handling system
WO2013048828A1 (en) * 2011-09-30 2013-04-04 Comprehend Systems, Inc. Systems and methods for generating schemas that represent multiple data sources
US8924431B2 (en) 2011-09-30 2014-12-30 Comprehend Systems, Inc. Pluggable domain-specific typing systems and methods of use
US9020981B2 (en) 2011-09-30 2015-04-28 Comprehend Systems, Inc. Systems and methods for generating schemas that represent multiple data sources
US9607018B2 (en) 2011-09-30 2017-03-28 Comprehend Systems, Inc. Pluggable domain-specific typing systems and methods of use
US9811543B2 (en) 2011-09-30 2017-11-07 Comprehend Systems, Inc. Systems and methods for generating schemas that represent multiple data sources
US10114879B2 (en) 2011-09-30 2018-10-30 Comprehend Systems, Inc. Systems and methods for generating pluggable domain-specific data types
US10901961B2 (en) 2011-09-30 2021-01-26 Saama Technologies, Inc. Systems and methods for generating schemas that represent multiple data sources
US20160043868A1 (en) * 2014-08-05 2016-02-11 Frank Oliver Hoffmann End-to-end tamper protection in presence of cloud integration
US9906367B2 (en) * 2014-08-05 2018-02-27 Sap Se End-to-end tamper protection in presence of cloud integration

Also Published As

Publication number Publication date
US7444522B1 (en) 2008-10-28
JP2011238289A (en) 2011-11-24
JP4892640B2 (en) 2012-03-07
JP2005539453A (en) 2005-12-22
KR20050057416A (en) 2005-06-16
CN100342347C (en) 2007-10-10
EP1540479A1 (en) 2005-06-15
AU2003263904B2 (en) 2009-04-23
CN1695123A (en) 2005-11-09
EP1540479A4 (en) 2010-12-08
WO2004027618A1 (en) 2004-04-01
AU2003263904A1 (en) 2004-04-08
KR100970771B1 (en) 2010-07-16

Similar Documents

Publication Publication Date Title
US7444522B1 (en) Dynamic negotiation of security arrangements between web services
KR101003557B1 (en) Electronic commerce community networks and intra/inter community secure routing implementation
Boritz et al. Security in XML-based financial reporting services on the Internet
US7467399B2 (en) Context-sensitive confidentiality within federated environments
US8719562B2 (en) Secure service network and user gateway
US7949871B2 (en) Method for creating virtual service connections to provide a secure network
US6073242A (en) Electronic authority server
JP2005517348A (en) A secure electronic messaging system that requires a key search to derive a decryption key
EP1540874A2 (en) Dynamic interoperability contract for web services
Chang et al. Managing security policy in a large distributed web services environment
INCIDENTAL et al. Security in a Web Services World: A Proposed Architecture and Roadmap
AU2014203495B2 (en) Electronic commerce community networks and intra/inter community secure routing implementation
AU2012203328B2 (en) Electronic commerce community networks and intra/inter community secure routing implementation
An Security AND Privacy White Paper
Kim et al. Trusted Information Sharing Model in Collaborative Systems
Sharma et al. Web Services and Interoperability: Security Challenges
Sharon Boeyen et al. Liberty Trust Models Guidelines
Venezuela et al. Liberty ID-WSF Security and Privacy Overview
Wesnarat Identity Management im Liberty Alliance Project

Legal Events

Date Code Title Description
AS Assignment

Owner name: COMMERCE ONE OPERATIONS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHANG, SYMON SZU-YUAN;SANFILIPPO, JOSEPH S.;KASI, JAYARAM RAJAN;AND OTHERS;REEL/FRAME:013615/0470;SIGNING DATES FROM 20021112 TO 20021212

AS Assignment

Owner name: JGR ACQUISTION, INC., DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COMMERCE ONE OPERATIONS, INC.;REEL/FRAME:015494/0720

Effective date: 20041208

Owner name: JGR ACQUISTION, INC.,DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COMMERCE ONE OPERATIONS, INC.;REEL/FRAME:015494/0720

Effective date: 20041208

Owner name: JGR ACQUISITION, INC., DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COMMERCE ONE OPERATIONS, INC.;REEL/FRAME:015494/0720

Effective date: 20041208

AS Assignment

Owner name: OPEN INVENTION NETWORK, LLC, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JGR ACQUISITION, INC.;REEL/FRAME:017519/0977

Effective date: 20051114

Owner name: OPEN INVENTION NETWORK, LLC,NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JGR ACQUISITION, INC.;REEL/FRAME:017519/0977

Effective date: 20051114

AS Assignment

Owner name: WELLS FARGO FOOTHILL, INC., AS AGENT, MASSACHUSETT

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:PERFECT COMMERCE, INC.;PERFECT COMMERCE OPERATIONS, INC.;COMMERCE ONE, LLC;AND OTHERS;REEL/FRAME:017468/0615

Effective date: 20060331

Owner name: WELLS FARGO FOOTHILL, INC., AS AGENT,MASSACHUSETTS

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:PERFECT COMMERCE, INC.;PERFECT COMMERCE OPERATIONS, INC.;COMMERCE ONE, LLC;AND OTHERS;REEL/FRAME:017468/0615

Effective date: 20060331

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: PERFECT COMMERCE HOLDINGS, LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:CORMINE, LLC;REEL/FRAME:042446/0156

Effective date: 20091215

Owner name: CORMINE, LLC, VIRGINIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WELLS FARGO FOOTHILL, INC.;REEL/FRAME:042446/0085

Effective date: 20070727

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20201028