Abstract: Example embodiments provide for a rule-based wizard type tool for generating secure policy documents. Wizard pages present a user with general Web Service security options or questions at a user interface, which abstracts the user from any specific code, e.g., XML code, used for creating a Web Service policy document. Based on user input selecting general criteria, security rules are accessed and evaluated for automatically making choices on behalf of the user for creating a secure policy document. Other embodiments also provide for presenting the user with an easily understandable visual representation of selected criteria of a policy document in, e.g., a tree like structure that shows relationships between various elements of the criteria.

Abstract: Example embodiments provide for a rule-based wizard type tool for generating secure policy documents. Wizard pages present a user with general Web Service security options or questions at a user interface, which abstracts the user from any specific code, e.g., XML code, used for creating a Web Service policy document. Based on user input selecting general criteria, security rules are accessed and evaluated for automatically making choices on behalf of the user for creating a secure policy document. Other embodiments also provide for presenting the user with an easily understandable visual representation of selected criteria of a policy document in, e.g., a tree like structure that shows relationships between various elements of the criteria.

Abstract: Example embodiments provide for processing policies that include policy assertions associated with incoming or outgoing messages of an application in a distributed system, without having to have code within the application for executing the policy assertions. When a message is received by a Web service engine, a policy document associated with an application may be accessed for identifying objects corresponding to policy assertions within the policy document. The objects identified can then be used to generate assertion handlers, which are software entities that include executable code configured to determine if messages can satisfy requirements described by the policy assertions.

Abstract: A mechanism for performing role-based authorization of the one or more services using security tokens associated with received service request messages. This role-based authentication is performed regardless of the type of security token associated with the received service request messages. Upon receiving a service request message over the network for a particular service offered by the service providing computing system, the service providing computing system accesses a security token associated with the received service request message. Then, the computing system identifies one or more roles that include the identity associated with the security token, and correlates the roles with the security token. These correlated roles are then used to authorize the requested service. This mechanism is performed regardless of the type of the security token.

Abstract: Within a distributed system, e.g., Web service environment, the present invention provides a way for identifying policies mapped to messages associated with an application, without having to have code within the application for determining what policies should apply to the messages. A centralized Web service engine is provided that receives incoming and outgoing messages associated with an application. The messages have associated with them destination endpoint identifiers and request-reply properties, which the Web service engine can access. The Web service engine can then use at least the identifiers and properties for scanning policy message files corresponding to the applications in order to identify what policies, if any, should be applied to the messages.

Abstract: The present invention provides for maintaining security context during a communication session between applications, without having to have executable code in either application for obtaining or generating a security context token (SCT) used to secure the communication. On a service side, a configuration file is provided that can be configured to indicate that automatic issuance of a SCT is enabled, thereby allowing a Web service engine to generate the SCT upon request. On the client side, when a message is sent from the client application to the service application, a policy engine accesses a policy that includes assertions indicating that a SCT is required for messages destined for the Web service application. As such, the policy engine requests and receives the SCT, which it uses to secure the message.

Abstract: A message handling computing system that provides security across even transport-independent communication mechanisms, and which allows for convenient extension of security to different security token types, and may provide end-to-end security across different transport protocols. The message handling computing system includes a message handling component configured to send and receive network messages having security tokens. The message handling component interfaces with an expandable and contractible set of security token managers through a standardized application program interface. Each security manager is capable of providing security services for messages that correspond to security tokens of a particular type. A security token plug-in component registers new security token managers with the message handling component.

Abstract: A sending computer system relays a message or a processing request through one or more configurable routers prior to the message or request reaching an ultimate destination. A client at the sending computer system can indicate a routing preference for the message or request, and a module can supplement or override the routing preference by adding or deleting a router from a router list contained within the message or request. This change can be done based on router data, as well as based on content within the message. One or more intermediate routers along the routing path can perform a similar function as the module. The ultimate destination, or receiving computer system, verifies that it is the appropriate recipient of the message or request, and then accepts the data associated with the message or request. This has application to many types of messaging systems, including simple object access protocols.

Abstract: A sending computer system generates a message and creates one or more security tokens to encrypt portions of the message. The computer system includes in the message a markup language identifier for the one or more security tokens used for encryption, and includes identification of the value type used to create the tokens. The computer system then serializes at least the portion of the message that identifies the one or more security tokens, without serializing other portions of the message that aid relaying of the message to a receiving computer system. A receiving computer system deserializes at least the portion of the message that identifies the one or more security tokens, and then uses deserialized token data to decrypt encrypted portions of the message. Each created security token can be made with customized data and fields, and can be made with a customized value type.