Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Ws security #9

Open
wants to merge 17 commits into
base: master
Choose a base branch
from
Open

[WIP] Ws security #9

wants to merge 17 commits into from

Conversation

goetas
Copy link
Member

@goetas goetas commented Dec 16, 2016

Fixes #2

  • basics
  • response handling
  • client configuration
  • tests
  • documentation

@goetas goetas changed the title Ws security [WIP] Ws security Dec 16, 2016
Ref: http://stackoverflow.com/questions/5726127/adding-soap-implicit-headers-to-wsdl

From a conceptual point of view, WSDL is not supposed to define headers. WSDL is only for defining the functional aspects of a service, like operations, messages, binding and endpoints. Messages and bindings define how the payload of messages should be encoded and formatted.

The headers of SOAP messages however do not belong to the payload. They are typically used for configuring non-functional properties of a SOAP processor. Security is such a non-functional property. The functional aspect of the payload is not affected. It is only assured that the communication is secured and the WS tool stack, not the service implementation, should take care of that.

So the missing piece is now a standard that allows for attaching some non-functional requirements to WSDL services, so that code generators can automatically derive which headers need to be sent and/or understand in order to fulfill the non-functional property as desired -- without having to manually deal with header fields. This standard exists and is called WS-Policy. A policy contains typically a set of alternatives that expose a set of requirements that both, provider and consumer should be able to fulfill. When two services are supposed to interact with each other, both policies are taken and a so called "effective policy" is calculated. It defines the common non-functional requirements. Using this information, provider and consumer can configure themselves to add required headers, like the WS-Security headers. WS-SecurityPolicy also defines a set of policies that can be used. WS-PolicyAttachment defines how such policies can be attached to a WSDL.

There are code generators that can deal with WS-Policies, e.g. Metro or Axis2
@goetas
Copy link
Member Author

goetas commented Jan 20, 2019

If somebody is interested in sponsoring this feature I can continue to work on it.

Pricing can be agreed (compatible with west-european hourly rates).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add WS-Security support
1 participant