Access Cycle is the core of Passage runtime protection.

It has plain flow-like architecture and can be altered and extended in each point of the flow.

Invocation

Product appeals to Access Cycle when wants to be sure a feature is not going to be used without proper license coverage.

On each such appeal, Access Cycle

  • reads, how exactly the product wants this feature to be protected
  • looks for available licenses,
  • evaluates, how these licenses fit the runtime and
  • finally checks, if the feature protection demand is covered by a license.
Requirements gathering: how the product wants to be protected

Licensing requirement - a formal statement with simple meaning like this feature must not work without license.

Requirements are supplied by the product under licensing.

Access Cycle gathers requirements available at the product runtime by means of an requirement gathering interface.

Implementations for this interface can be multiple and are provided for Access Cycle by its configuration.

Thus, to supply requirements of your own source, just implement the interface and mention it in Access Cycle Configuration.

Grants mining: what licenses the user has

Grant - particle of a license that states: this feature can be used if this condition is fulfilled .

Condition - grant's restriction, formalized demand for runtime environment or user data, like hwdisk.serial='123456YU' or location='Greece' or root.name='SecurityTools'.

Grants are supplied by a product license.

Access Cycle mines grants with the dedicated mining interface.

There can be many miners registered at the product runtime; Access Cycle Configuration is responsible for conveying them to Access Cycle.

Thus, to support some new type of condition you should implement several connected interfaces and supply them to Access Cycle through its configuration.

Permission emitting: which grants get their conditions fulfilled

Permission - runtime unit with short TTL which reads: for the moment, we are treating this condition as fulfilled and thus this grant allows to use this feature .

Permissions are supplied by Access Cycle: it evaluates all the grants' conditions against appropriate runtime environment (for instance hardware or user data) to detect whether it is fulfilled or not. Each grant with successfully evaluated condition begets a permission for the feature to be used.

Access Cycle evaluates a condition with the set of interfaces responsible for condition text parsing to tokens, token evaluation against runtime environment, combination of results for all tokens, etc.

Lots of condition types can be supported simultaneously.

To add your own type of condition and thereby empower a license to check yet unsupported runtime aspects, you need to cover condition evaluation with necessary interfaces and extend Access Cycle Configuration correspondingly.

Requirements against permissions examining: each requirement must be covered with a permission

Here product demands (restrictive part) meet licenses (permissive part) to find out whether there are enough permissions for all the demands.

Access Cycle checks if the emitted permissions are enough to satisfy all the gathered requirements by the examination interface.

Many implementations can be supplied at the same time; and if you like to append more restrictive logic to the whole cycle, implement the interface and supply it through Access Cycle Configuration.

According to the examination the final decision is made: where the feature can be used or not. Examination certificate is leased to convey all the details of the solution.

For successfully examined feature a usage grant can be acquired.