The call statement (<instance-policy-binding>)

The call statement lets you configure request message delivery and response message forwarding events when the specific server entity method implementation is called. The call statement is used in the entity section of the server entity.

Syntax

<call-policy-binding> ::=

"call" [<direction>] [<instance-method>] "="

<policy-list> ";"

<direction> ::= "in"|"out"

<instance-method> ::=

<full-method-name> ["(" <arg-name> {"," <arg-name> "}"]

["[" <src-sid> "," <dst-sid> "]"]

Elements

<direction>

Specifies the direction of a message. Permissible values:

  • in – request-message
  • out – response-message

    The in value is used by default.

<instance-method>

Full name of the method implementation and optional list of arguments. The names of arguments must be consistent with the names from the IDL description of the method.

If the method is not specified, the binding rule is applied to all methods in the entity

.

<full-method-name>

Full name of the method implementation. It has the following format:

ComponentInstance.ImplementationName.MethodName

<arg-name>

Name of the argument.

<src-sid>

Name of the argument containing the identifier of the security context of the message sender-entity. This argument is implicitly defined and is passed in each interaction event of the entity. The argument name is arbitrarily defined. By this name, the argument can be passed to security policies in the list of arguments.

<dst-sid>

Name of the argument containing the identifier of the security context of the message recipient-entity. This argument is implicitly defined and is passed in each interaction event of the entity. The argument name is arbitrarily defined. By this name, the argument can be passed to security policies in the list of arguments.

<policy-list>

List of security policies that will be applied to an event.

Example

/* Policies applied to the request-message that is passed in the repo.entry.get method. When making a decision, policies can analyze the contents of the passed message (or its component). In the provided example, the "filter_key" policy limits the amount of keys ("key") that the client can call.

*/

call in repo.entry.get (key, passwd)

= filter_key { prefix : "local-" } (key),

check_passwd (key, passwd);


/* Policies applied to the response-message that is returned in the repo.entry.get method. In the provided example, the "check_secret_info" policy can block forwarding of the response message to the client based on the message content.

*/

call out repo.entry.get (value, checksum)

= check_secret_info (value);

Configuration of events using the call statement is shown in the example of interaction between two entities – see the figure below.

kos_sdk_securitycfg_instance

Configuring request message delivery and response message forwarding events using the call statement

Page top