Fine grained access control

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Fine grained access control

Thomas Menke
I have created a portal application that - if you want to boil it down
to that - manages XForms. It has portlets for seeing all the available
templates, the instances, creating instances and so on. It already works
nicely with Lotus Forms and now I want to add Orbeon support. I've
already implemented my own persistence layer and I am optimistic than it
won't be too much of a problem for me to write my own proxy portlet
which shows forms for editing and creating form instances depending on
data it gets by inter portlet communication.

Now coming to the access control: From the IPC and session, my portlet
knows exactly which instance and which form is accessed and can deny
access based on this data and the currently logged in user. But I am
thinking of xpath based access control. So even within one instance
different privileges can be assigned to different users. How can I do that?

If the persistence layer would know which user it is accessing data for,
then the persistence layer could censor information that a user must not
see and discard information upon saving that a user must not be able to
change. But unfortunately the persistence layer does not know that. One
idea would be to play with the UUID of the persistence layer. After all
these are 128 bits that can passed through from the proxy to the form
runner and back to the persistence API that leave more than enough room
to include the current user id and temporary another key that maps to
the actual UUID. On the hand that sound like an awful hack...

Any suggestions?

Thomas


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Fine grained access control

Erik Bruchez
Administrator
Thomas,

On Tue, Jun 12, 2012 at 3:47 AM, Thomas Menke <[hidden email]> wrote:

> I have created a portal application that - if you want to boil it down to
> that - manages XForms. It has portlets for seeing all the available
> templates, the instances, creating instances and so on. It already works
> nicely with Lotus Forms and now I want to add Orbeon support. I've already
> implemented my own persistence layer and I am optimistic than it won't be
> too much of a problem for me to write my own proxy portlet which shows forms
> for editing and creating form instances depending on data it gets by inter
> portlet communication.
>
> Now coming to the access control: From the IPC and session, my portlet knows
> exactly which instance and which form is accessed and can deny access based
> on this data and the currently logged in user. But I am thinking of xpath
> based access control. So even within one instance different privileges can
> be assigned to different users. How can I do that?
>
> If the persistence layer would know which user it is accessing data for,
> then the persistence layer could censor information that a user must not see
> and discard information upon saving that a user must not be able to change.
> But unfortunately the persistence layer does not know that. One idea would
> be to play with the UUID of the persistence layer. After all these are 128
> bits that can passed through from the proxy to the form runner and back to
> the persistence API that leave more than enough room to include the current
> user id and temporary another key that maps to the actual UUID. On the hand
> that sound like an awful hack...
>
> Any suggestions?
At this point Orbeon Forms should pass two headers through to the
persistence layer:

- Orbeon-Username
- Orbeon-Roles

These are set within Orbeon Forms either from the container APIs or
from incoming headers.

Would that help?

-Erik


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: Fine grained access control

koenvdk
Interesting,

Those headers, do they by any chance need to be in the response from the persistance api? Because nog having this info might be the cause of a lot of problems I am facing with security right now.



Koen Vanderkimpen

Connect: Twitter





From:        Erik Bruchez <[hidden email]>
To:        [hidden email]
Date:        19/06/2012 07:21
Subject:        [ops-users] Re: Fine grained access control
Sent by:        [hidden email]





Thomas,

On Tue, Jun 12, 2012 at 3:47 AM, Thomas Menke <[hidden email]> wrote:
> I have created a portal application that - if you want to boil it down to
> that - manages XForms. It has portlets for seeing all the available
> templates, the instances, creating instances and so on. It already works
> nicely with Lotus Forms and now I want to add Orbeon support. I've already
> implemented my own persistence layer and I am optimistic than it won't be
> too much of a problem for me to write my own proxy portlet which shows forms
> for editing and creating form instances depending on data it gets by inter
> portlet communication.
>
> Now coming to the access control: From the IPC and session, my portlet knows
> exactly which instance and which form is accessed and can deny access based
> on this data and the currently logged in user. But I am thinking of xpath
> based access control. So even within one instance different privileges can
> be assigned to different users. How can I do that?
>
> If the persistence layer would know which user it is accessing data for,
> then the persistence layer could censor information that a user must not see
> and discard information upon saving that a user must not be able to change.
> But unfortunately the persistence layer does not know that. One idea would
> be to play with the UUID of the persistence layer. After all these are 128
> bits that can passed through from the proxy to the form runner and back to
> the persistence API that leave more than enough room to include the current
> user id and temporary another key that maps to the actual UUID. On the hand
> that sound like an awful hack...
>
> Any suggestions?

At this point Orbeon Forms should pass two headers through to the
persistence layer:

- Orbeon-Username
- Orbeon-Roles

These are set within Orbeon Forms either from the container APIs or
from incoming headers.

Would that help?

-Erik

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe:
[hidden email]
For general help:
[hidden email]
OW2 mailing lists service home page:
http://www.ow2.org/wws








Overeenkomstig de bepalingen inzake de vertegenwoordiging van de vzw in haar statuten, kan enkel de gedelegeerde bestuurder, de algemeen directeur of zijn uitdrukkelijke lasthebber verbintenissen aangaan namens Smals.
Indien dit bericht niet voor u bestemd is, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen.

Conformément aux dispositions relatives à la représentation de l'asbl dans ses statuts, seul l'administrateur délégué, le directeur général ou son mandataire exprès est habilité à souscrire des engagements au nom de Smals.
Si ce message ne vous est pas destiné, nous vous prions de nous le signaler immédiatement et de détruire le message.

According to the provisions regarding representation of the non profit association in its bylaws, only the chief executive officer, the general manager or his explicit agent can enter into engagements on behalf of Smals.
If you are not the addressee of this message, we kindly ask you to signal this to us immediately and to delete the message.





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: Fine grained access control

Thomas Menke
In reply to this post by Erik Bruchez
On 06/19/2012 07:20 AM, Erik Bruchez wrote:

>
> At this point Orbeon Forms should pass two headers through to the
> persistence layer:
>
> - Orbeon-Username
> - Orbeon-Roles
>
> These are set within Orbeon Forms either from the container APIs or
> from incoming headers.
>
> Would that help?
Oh yes, this would help a great deal. And searching for Orbeon-Username
got me this:

http://wiki.orbeon.com/forms/doc/developer-guide/form-runner/access-control#TOC-Accessing-the-username-and-roles

With this description I am confident to get it working. Thanks :-).

>
> -Erik

Thomas


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Fine grained access control

sumit_kumar
In reply to this post by Thomas Menke
thanks for these updates. these are very helpful.

sip telephone service