...
All permission checks that occur within the Enterprise Store happen happens against a key, which is dynamically evaluated given the context of the permission check.
For example, the diagram above defines an ASSET_CREATE permission key, which is mapped as follows:
...
At the time of the permission check the ASSET_CREATE key is resolved to a permission string, which maps is mapped to a permission in the WSO2 permission tree.
...
A static permission is always mapped to a permission string, and is not evaluated based on the current context prior to a permission check. The context consists of the page and asset type been accessed by a given user.
Example:
At any given time, if you check the permission for the lifecycle permission (/_system/governance/permission/admin/manage/resources/govern/lifecycles), it will not change based on the asset type.
...
A dynamic permission is a permission that is always evaluated at runtime. It is a function callback that can return a String, which represents a permission or a Boolean value indicating whether a permission was evaluated successfully or not.
Example:
| Code Block |
|---|
Permissions.ASSET_CREATE = function(ctx) {
if (!ctx.type) {
throw 'Unable to resolve type to determine the ASSET_CREATE permission';
}
return '/permission/admin/manage/resources/govern/' + ctx.type + '/add';
}; |
In the above example, the permission that the ASSET_CREATE key evaluates, changes based on the asset type.
Permission API
In order to assist extension developers in securing their resources, the permission API exposes a number of methods to check access rights of a given user.