On 02/11/12 16:00, Markus KARG wrote:
> Sergey,
>
> thank you for your comments.
>
> I wonder how a client shall find out whether or not to show / hide
> particular GUI items (e. g. menu items directly related to the access rights
> of the current user) if the client cannot find out the access rights by pure
> http means. Is your proposed solution really to _not_ use pure http means
> but build a particular application-specific protocol ontop? If yes, what
> good for is OPTIONS then?
To be honest I'm not sure how one can write a practical application by
depending on the list of verbs returned with OPTIONS
> I mean, if it reports a method that the current
> user must never invoke?
I just think it would overload OPTIONS.
IMHO the better approach is to offer a user/role-specific view, example,
a user logs in, and the server picks up say admins.jsp to present a
view. It is only the issue with monolitic UI frontends, isnt it ?
Also, IMHO, enforcing RBAC with @RolesAllowed is the most basic
approach, a number if options exist to enforce the method-level
authorization. Thus it seems to me it is out of scope for JAX-RS, given
that the 'responsibility' of the spec is to promote the ideas that can
lead to interoperable applications being created
I also recall seeing some initiative for getting this early client-side
authorization done, sorry, can not find the link.
Thanks, Sergey
>
> Thanks
> Markus
>
>> The idea of "(4) The JAX-RS's automatically provided "Allow" header for
>> an OPTIONS request will omit any HTTP methods which would be not
>> executed following the sense of (3) when requested with the same
>> security credentials as the OPTIONS call (i. e. either unauthenticated
>> or authenticated as the same user)." does not work.
>>
>> It really the server side issue, making sure the authenticated client
>> is properly authorized, so I'm not sure what Options is to do with it,
>> I can already hear the security experts saying this would allow a
>> rogue client to use this mechanism to expose the info the client does
>> not need to know.
>>
>> Now, in UI frontends, it it handy sometimes to block certain actions
>> based on the client's identity. This still can be resolved by offering
>> client specific views (presented after the initial login) and in cases
>> when the UI is to rigid, it is a completely out-of-scope activity for
>> JAX-RS anyway.
>>
>> I'm -1 on it
>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com