[Architecture] UI Permission Model-On the table for discussion

[Dimuthu Leelarathne]

Hi,

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

/system/ui/permission/



>> And permission resources can be observed as follows in the registry.
>>
>> /ui/a/b/c/d
>> /ui/a/x
>> /ui/a/y
>>
>> 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.
>>
>> realm.getAuthorizationManager().isUserAuthorized("Saman",
>> "/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.
>> /ui/login
>> /ui/login/monitor-system/manage-configuration
>> /ui/login/monitor-system/manage-security
>>
>> 4) Bundle authors are given the freedom for defining granularity of
>> permissions.
>>
>> 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
yes.

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.

Thank you,
Dimuthu L



>
>> /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
>> statistics
>>
>> 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
>>    links/buttons/graphs.
>>
>>
>> -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.
>>
>
> +1.
>
> Thanks,
> Senaka.
>
>>
>> WDYT?
>>
>> Thank you,
>> Dimuthu L
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture at wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> _______________________________________________
> Architecture mailing list
> Architecture at wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.wso2.org/pipermail/architecture/attachments/20090915/ae152136/attachment.html>