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.
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
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.
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 - 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.
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.