[Architecture] UI Permission Model-On the table for discussion
dimuthul at wso2.com
Mon Sep 14 22:33:32 EDT 2009
On Mon, Sep 14, 2009 at 9:23 PM, Senaka Fernando <senaka at wso2.com> wrote:
> Hi Dimuthu,
> Just a few questions,
> 1) UI permissions are treated as a resource in registry. The root of all UI
>> permissions is the following.
> Why UI? If these are only permissions, wouldn't it be better to call this,
> /system/permissions? The permission model spans to UI + Admin services as
> you explain below under #4.
I used the word "ui" because these permissions eventually control how user
interacts with the UI and effectively is a subset of the system permissions.
So considering your suggestions, we can define the root as follows.
>> And permission resources can be observed as follows in the registry.
>> Details : "d" has a high security sensitivity than "a". Basic rule is when
>> a role is given permission to access "d", it can access all lower-security
>> sensitivity resources on the same path such as - /ui/a/b/c.
>> This hierarchical model gives levels of access to each role.
>> 2) Permission is a tuple (user/resource/action) in WSO2 Carbon. So our UI
>> permissions are a tuple in the following nature.
>> The action for UI permission is "execute" (?? any suggestions for a better
>> label ???). So when querying for a permission the following is how it should
>> be done.
>> "/ui/login/manage-security", "execute");
>> 3) By default only the following permissions are available on start-up.
>> All other permissions must be added by the relevent component authors on
>> their bundle start-up.
>> 4) Bundle authors are given the freedom for defining granularity of
>> Please note the three permission spaces.
>> - Actual permission. Let's call this "Permission space"
>> - How does the permission map to the UI ? Let's call this "UI space"
>> - How does the permission map to Admin service ? Let's call this
>> "Admin space"
>> Yes, this is related to what I was talking about above.
>> 4.1) We do not impose any restrictions as "every method must have a
>> permission", because this is an UNnecessary evil - definitely not a
>> necessary evil. Most admin services do not need to control access on per
>> method basis. Why? Out of the 81+ components available in the components
>> directory, only very few require fine grain permissions - 2 or 3 bundles
>> maximally (service-mgt component and one bundle from Tyrell, if IIRC). So to
>> facilitate the fine grain permissions all other bundles do not need to pay
>> the penalty by imposing strict restrictions.
>> 4.2) Fine grained permissions must be added explicitely by the bundle and
>> checked explicitely by the admin service and UI, because the meaning is only
>> known to the bundle.
>> An EXAMPLE
>> Let's illustrate fine grained permissions using service-mgt bundle as an
>> example. (Please Note : The following permissions are taken just to show how
>> the model will work and NOT the actual permissions).
> Could this hierarchy be something like
> /SOME_ROOT_CONTEXT/COMPONENT_NAME/PERMISSIONS (Where SOME_ROOT_CONTEXT would
> be /ui, or /system/permissions, and COMPONENT_NAME = service-mgt), as a
> convention to avoid overlappings?
Yes, only if the component author is defining permissions that are highly
specific to the component. So for service-mgt is the answer is definitely
I would like to add a rule-of-thumb as "define new permissions only if you
cannot reuse the existing permissions". For example I would like to have a
single "/SOME_ROOT_CONTEXT/login/monitor-system" instead of having all 81
components defining their own "monitor-system" pemission.
>> /ui/login/service-mgt/qos ------------------------------------ can
>> configure qos on all services
>> /ui/login/service-mgt/statistics --------------------------- can view
>> statistics of all services
>> /ui/login/service-mgt/servicename/qos -------------- service specific qos
>> /ui/login/service-mgt/servicename/statistics ----- service specific
>> The mapping among our three permission spaces occur as follows.
>> -On the service-mgt bundle start-up first two permissions will be added.
>> And service specific permissions will be added on service additions.
>> (Permission space)
>> -Then on service-mgt portal (UI space),
>> - Permissions are explicitly checked before displaying any
>> -Then in the Admin Services (Admin service space),
>> - The permissions are checked before authorizing users to proceed.
>> This can be automated if the permissions and the admin service methods have
>> strict 1-to-1 or 1-to-n mapping.
>> But if the bundle requires only a single permission (eg.
>> manage-configuration) then the framework will do the mapping automatically.
>> The Carbon framework will use parameters in the component.xml and
>> services.xml, like it does now.
>> Thank you,
>> Dimuthu L
>> Architecture mailing list
>> Architecture at wso2.org
> Architecture mailing list
> Architecture at wso2.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Architecture