Policy Enforcement Point (PEP)¶
The interactions executed inside one zone are checked by and enforced in the scope of a PEP assigned for that zone. The approach is similar for the zones that consist of geographically dispersed locations: each PEP (or sub-PEP) is responsible for its geographical unit or layer. Being the single point of contact of a zone, the PEP is primarily responsible for checking incoming and outgoing requests. In the second instance, depending on security settings and application requirements, PEP might serve as an inter-zone communication gateway, as well.
Summary: This endpoint is used by PEPs to POST new requests to other PEPs. Inputs to this endpoint are contextual parameters that establish the request, application and target specific settings. The response of this action is the data record that contains request id and data structure describing status parameters or other PEP requirements.
|200||Body of the original request||[ byte ]|
Summary: Applications can POST new requests to this endpoint. Inputs to this endpoint are contextual parameters that establish the request, application and target specific settings. For this specification, the applications rely on common SUNFISH functionalities and components. The response of this action is the original response of the target service (synchronous use case).
|body||body||Body of the original request||No||[ byte ]|
|SUNFISH-issuer||header||References the application that issued the request. This field may include the data required to perform application authenticati on, in the form of authenticati on token.||No||string|
|SUNFISH-service||header||Machine-read able description of endpoint including at least an identifier of the service. With the service id, the PEP can resolve other required attributes.||Yes||string|
Machine-read able description of the target endpoint and request data. The PEP at least requires the parameters method, port, path and protocol. If additional attributes are registered in the SUNFISH federation, the PEP can retrieve these attributes from a correspondin
PIP. Furthermore, this field may include validity constraints on a request (not-valid-b efore, not valid-after) .
|SUNFISH-request-parameters||header||The parameters related to the request, including its priority, SLA requirements , call-back URI. This field includes other request meta-data that may extend or override the definitions provided in centralized administrati ve console. These include request type, application- specific policies or obligations to be applied beyond the ones defined in the central console, or parameters related to data-masking policies. The scope of applicable and allowed definitions provided in this variable depends on an extent of delegation policies, as determined in centralized console.||No||string|
|SUNFISH-request-data||header||This field encapsulates the original header data and the original query string as issued by the application.||Yes||string|
|SUNFISH-signature||header||This parameter is used to ensure integrity and authenticity of the source message for applications which require a higher degree of security. It contains signed request and fields, according to predefined schema||No||string|
|200||The same response as provided by the target service||[ byte ]|