Endpoint Reference

From OpenLiberty.org Wiki

EndpointReference

An ID-WSF Endpoint Reference is a reference to a service instance. It contains the address, security tokens, and other metadata necessary for interacting with the identified service instance. EPRs are created as the result of a Discovery Service query, in a security token as a bootstrapped EPR, or sent by WSF Services publishing ReplyTo or FaultTo code in header blocks.

• The ClientLib EndpointReference class will model all required and optional attributes and elements using the OpenSAML xml-tooling libraries for conversion from XML to objects

• The ClientLib will support the security mechanisms outlined in the Liberty ID-WSF Security Mechanisms Core for authentication and message level security. To start the ClientLib will support:
  1. urn: liberty: security: 2003-02: TLS: null
  2. urn: liberty: security: 2005-02: TLS: Bearer
  3. urn: liberty: security: 2006-08: TLS: SAMLV2

• A WSP should place security tokens in order of preference. The EPR may be suited for choosing the best fit with the WSC ClientLib User's available mechanisms.

notes, and attributes and elements of note

• notOnOrAfter attribute: indicates expiration time of the EPR, no finer than milliseconds. If this is not specified or if 1970-0101T00: 00: 00Z is specified the ClientLib will assume 24 hours. It might be good to provide a way for a ClientLib User to change this default behavior.

• abstract - human readable description of the service
• (MUST) wsa:Address - contains the actual address of the referenced endpoint
• (MUST) wsa:Metadata
  • (MUST) ProviderId
  • Security Context - Which contains the id of the security mechanism used and a security token. An EPR may have more than one mutually exclusive Security Contexts. A Security Context may contain one or more security mechanism or security token, but each token must apply to all mechanisms.
    • Must easily indicate when the WSC MUST obtain a security token from another provider. (urn: liberty: disco: tokenref: ObtainFromIDP as the URI in the "ref" attribute of the token)
    • A Token may reference a token from another SecurityContext by indicating this reference in its "ref" attribute
  • Actions - Must be modeled for a ClientLib User
    • wsa:Action element(s) MUST match the URIs defined for actions for a particular service. In the case that there are no action elements, it is assumed that the EPR provides access to all specified actions for a particular service type.
    • in the case of Discovery Service the Actions that would be relevant to a WSC would be:
      1. urn:liberty:disco:2006-08:Query
      2. urn:liberty:disco:2006-08:QueryResponse
  • (MUST) Framework Version - one or more
  • (MUST) Service Type - one or more
  • Options - Must be modeled for a ClientLib User. ((DISCOVERY SERVICE CLIENT: The ClientLib must deal with the situation where there is an Option value of urn: liberty: disco: 2006-08: options: security-response-x5092118 which indicates that the service authenticates its response messages with X.509. ))

Questions

Please confirm:

• if no wsa:Action elements are present, then the EPR indicates that ALL Actions are supported
• if wsa:Actions are present, the EPR indicates that the service supports only those listed
• Are there wsa:Actions that would be listed in an EPR that would not be used by a WSC? -- an example would be a discovery service where only Query and QueryResponse are relevant to the WSC, but there are a host of WSP Actions.
• The WSC ClientLib must essentially act as a passthrough for services that are not defined in the ClientLib

Does the ClientLib need to understand anything about wsa:Action other than how to allow for them to be set for a query and to pass them on to the ClientLib User?

An example of <Option> elements defined by a service type? (besides the x509)

Can a security token contain a ref attribute that points to a security token in an entirely separate EPR? If so, is the limit of scope the same SOAP message?