orbeon authorization evaluation

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

orbeon authorization evaluation

koenvdk
Hi,

I've been experimenting with the authorization mechanisms in Orbeon, as they are very important for our project. I tried a thorough evaluation of most authorization features.

To avoid any interference from outside, I started yesterday with two locally-run out-of the-box versions of Orbeon PE: the stable and the nightly build. I tried to do the minmimum configuration possible so as to get things working, and did the exact same things on both versions. I started with turning security on by changing the web.xml to protect some resources (see bottom of mail for full configuration changes). This functions normally in both versions, as is to be expected of any webapp. (of course, I also added users and roles in tomcat to test this, see bottom)

Then I turned to the properties-file, and turned on container-based authentication, declaring the necessary roles. Again, see bottom for all (2) the property changes that were made.

What I immediately noticed: in the stable version it becomes impossible under this configuration to create new forms; when you click new, you get an empty drop-down list for the application (and this without touching the default * * * config for form-builder-permissions). Even with various attempts at configuring form-builder-permissions or even form-runner-roles, I can't get this to work.
In the nightly build, however; this was fixed! Form builder permissions worked with a minimal config in web.xml, properties-local and form-builder-permissions, which I also included at the bottom.

Some minor beauty mistakes perhaps: you don't immediately get to see all your apps when going to the form builder summary, if you have access to a finite number of them; you have to use search options and select the other apps to see their forms. Also, the summary "betrays" how many total forms there really are, even when you do not have access to all of them ("search returned 3 of 8 items").


So, the fact that form-builder-permissions are not working in the stable leads me to believe there is something wrong with the stable. Is this so, or is there a config that I forgot? I would very much like to see a stable in which this was fixed!



Something that did not work in either configuration, stable nor nightly, was the use of the variable $fr-roles in xpath expressions to determine visibility or read-onlyness of controls (like $fr-roles='admin'). I tried many expressions, and, using count, discovered $fr-roles is an empty list.
I finally found a work-around, being the function xxforms:is-user-in-role('admin'), which works in both stable and nightly.

If that function works, am I correct to presume that there is something wrong in orbeon concerning the initialisation of the $fr-roles variable? or am I still forgetting to configure something? This fix is less urgent as we luckily have the work-around  to use.


I was not able to test the new form-level permissions because I was using out-of-the-box Orbeon with exist. I may evaluate these later. (although I think I tried it out many weeks ago on mysql using a previous nightly, and it seemed to work - fingers crossed! )



To conclude; my question repeated: Am I missing some configuration for my container-based security? If so, I really really want to know :-). Or are there really bugs in Orbeon, and if so, when will they be fixed in the next stable release?



Thank you for any response,


Koen Vanderkimpen



ADDON 1: web.xml additions


        <security-constraint>
        <web-resource-collection>
            <web-resource-name>Everything</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>*</role-name>
        </auth-constraint>
    </security-constraint>
        <security-constraint>
        <web-resource-collection>
            <web-resource-name>Admin-only form</web-resource-name>
                        <url-pattern>/fr/admin</url-pattern>
            <url-pattern>/fr/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>
        <security-constraint>
        <web-resource-collection>
            <web-resource-name>No-anonymous form</web-resource-name>
                        <url-pattern>/fr/test/test1</url-pattern>
            <url-pattern>/fr/test/test1/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
                        <role-name>user</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/java-authentication/login</form-login-page>
            <form-error-page>/java-authentication/login-error</form-error-page>
        </form-login-config>
    </login-config>
    <security-role>
        <role-name>admin</role-name>
    </security-role>
        <security-role>
        <role-name>user</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon-user</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon-admin</role-name>
    </security-role>
        <security-role>
        <role-name>*</role-name>
    </security-role>


ADDON 2: properties-local.xml


<property as="xs:string" name="oxf.fr.authentication.method"                       value="container"/>
<property as="xs:string" name="oxf.fr.authentication.container.roles"              value="orbeon admin user orbeon-admin orbeon-user"/>        


ADDON 3: tomcat-users.xml


  <role rolename="admin-gui"/>
  <role rolename="manager-gui"/>
  <role rolename="admin"/>
  <role rolename="manager"/>
  <role rolename="orbeon-admin"/>
  <role rolename="orbeon-user"/>

<user username="koen" password="koen" roles="admin-gui,manager-gui,admin,manager,orbeon-admin,orbeon-user,orbeon,admin" />
<user username="koen2" password="koen2" roles="orbeon-user,orbeon,user"/>
<user username="koen3" password="koen3" roles="anonymous,admin"/>


ADDON 4: form-builder-permissions.xml        

<role name="orbeon-admin" app="*" form="*"/>
<role name="orbeon-user" app="test" form="*"/>
<role name="admin" app="test" form="*"/>
<role name="admin" app="admin" form="*"/>
<role name="orbeon" app="orbeon" form="*"/>

Connect: Twitter








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: orbeon authorization evaluation

Erik Bruchez
Administrator
Koen,

First, thanks for the thorough evaluation!

Definitely it sounds like something is broken with $fr-roles and I entered an issue to fix for 4.0:


Now with regards to the stable build, it is quite possible that there is an issue as well, because the code handling permissions has been almost entirely rewritten. It is quite possible that nobody has found that issue with the stable build.

-Erik

On Thu, Jun 21, 2012 at 2:43 AM, <[hidden email]> wrote:
Hi,

I've been experimenting with the authorization mechanisms in Orbeon, as they are very important for our project. I tried a thorough evaluation of most authorization features.

To avoid any interference from outside, I started yesterday with two locally-run out-of the-box versions of Orbeon PE: the stable and the nightly build. I tried to do the minmimum configuration possible so as to get things working, and did the exact same things on both versions. I started with turning security on by changing the web.xml to protect some resources (see bottom of mail for full configuration changes). This functions normally in both versions, as is to be expected of any webapp. (of course, I also added users and roles in tomcat to test this, see bottom)

Then I turned to the properties-file, and turned on container-based authentication, declaring the necessary roles. Again, see bottom for all (2) the property changes that were made.

What I immediately noticed: in the stable version it becomes impossible under this configuration to create new forms; when you click new, you get an empty drop-down list for the application (and this without touching the default * * * config for form-builder-permissions). Even with various attempts at configuring form-builder-permissions or even form-runner-roles, I can't get this to work.
In the nightly build, however; this was fixed! Form builder permissions worked with a minimal config in web.xml, properties-local and form-builder-permissions, which I also included at the bottom.

Some minor beauty mistakes perhaps: you don't immediately get to see all your apps when going to the form builder summary, if you have access to a finite number of them; you have to use search options and select the other apps to see their forms. Also, the summary "betrays" how many total forms there really are, even when you do not have access to all of them ("search returned 3 of 8 items").


So, the fact that form-builder-permissions are not working in the stable leads me to believe there is something wrong with the stable. Is this so, or is there a config that I forgot? I would very much like to see a stable in which this was fixed!



Something that did not work in either configuration, stable nor nightly, was the use of the variable $fr-roles in xpath expressions to determine visibility or read-onlyness of controls (like $fr-roles='admin'). I tried many expressions, and, using count, discovered $fr-roles is an empty list.
I finally found a work-around, being the function xxforms:is-user-in-role('admin'), which works in both stable and nightly.

If that function works, am I correct to presume that there is something wrong in orbeon concerning the initialisation of the $fr-roles variable? or am I still forgetting to configure something? This fix is less urgent as we luckily have the work-around  to use.


I was not able to test the new form-level permissions because I was using out-of-the-box Orbeon with exist. I may evaluate these later. (although I think I tried it out many weeks ago on mysql using a previous nightly, and it seemed to work - fingers crossed! )



To conclude; my question repeated: Am I missing some configuration for my container-based security? If so, I really really want to know :-). Or are there really bugs in Orbeon, and if so, when will they be fixed in the next stable release?



Thank you for any response,


Koen Vanderkimpen



ADDON 1: web.xml additions


        <security-constraint>
        <web-resource-collection>
            <web-resource-name>Everything</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>*</role-name>
        </auth-constraint>
    </security-constraint>
        <security-constraint>
        <web-resource-collection>
            <web-resource-name>Admin-only form</web-resource-name>
                        <url-pattern>/fr/admin</url-pattern>
            <url-pattern>/fr/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>
        <security-constraint>
        <web-resource-collection>
            <web-resource-name>No-anonymous form</web-resource-name>
                        <url-pattern>/fr/test/test1</url-pattern>
            <url-pattern>/fr/test/test1/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
                        <role-name>user</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/java-authentication/login</form-login-page>
            <form-error-page>/java-authentication/login-error</form-error-page>
        </form-login-config>
    </login-config>
    <security-role>
        <role-name>admin</role-name>
    </security-role>
        <security-role>
        <role-name>user</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon-user</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon-admin</role-name>
    </security-role>
        <security-role>
        <role-name>*</role-name>
    </security-role>


ADDON 2: properties-local.xml


<property as="xs:string" name="oxf.fr.authentication.method"                       value="container"/>
<property as="xs:string" name="oxf.fr.authentication.container.roles"              value="orbeon admin user orbeon-admin orbeon-user"/>        


ADDON 3: tomcat-users.xml


  <role rolename="admin-gui"/>
  <role rolename="manager-gui"/>
  <role rolename="admin"/>
  <role rolename="manager"/>
  <role rolename="orbeon-admin"/>
  <role rolename="orbeon-user"/>

<user username="koen" password="koen" roles="admin-gui,manager-gui,admin,manager,orbeon-admin,orbeon-user,orbeon,admin" />
<user username="koen2" password="koen2" roles="orbeon-user,orbeon,user"/>
<user username="koen3" password="koen3" roles="anonymous,admin"/>


ADDON 4: form-builder-permissions.xml        

<role name="orbeon-admin" app="*" form="*"/>
<role name="orbeon-user" app="test" form="*"/>
<role name="admin" app="test" form="*"/>
<role name="admin" app="admin" form="*"/>
<role name="orbeon" app="orbeon" form="*"/>

Connect: Twitter








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: orbeon authorization evaluation

Erik Bruchez
Administrator
Koen,

This bug is now fixed!

-Erik

On Fri, Jun 22, 2012 at 11:14 PM, Erik Bruchez <[hidden email]> wrote:
Koen,

First, thanks for the thorough evaluation!

Definitely it sounds like something is broken with $fr-roles and I entered an issue to fix for 4.0:


Now with regards to the stable build, it is quite possible that there is an issue as well, because the code handling permissions has been almost entirely rewritten. It is quite possible that nobody has found that issue with the stable build.

-Erik


On Thu, Jun 21, 2012 at 2:43 AM, <[hidden email]> wrote:
Hi,

I've been experimenting with the authorization mechanisms in Orbeon, as they are very important for our project. I tried a thorough evaluation of most authorization features.

To avoid any interference from outside, I started yesterday with two locally-run out-of the-box versions of Orbeon PE: the stable and the nightly build. I tried to do the minmimum configuration possible so as to get things working, and did the exact same things on both versions. I started with turning security on by changing the web.xml to protect some resources (see bottom of mail for full configuration changes). This functions normally in both versions, as is to be expected of any webapp. (of course, I also added users and roles in tomcat to test this, see bottom)

Then I turned to the properties-file, and turned on container-based authentication, declaring the necessary roles. Again, see bottom for all (2) the property changes that were made.

What I immediately noticed: in the stable version it becomes impossible under this configuration to create new forms; when you click new, you get an empty drop-down list for the application (and this without touching the default * * * config for form-builder-permissions). Even with various attempts at configuring form-builder-permissions or even form-runner-roles, I can't get this to work.
In the nightly build, however; this was fixed! Form builder permissions worked with a minimal config in web.xml, properties-local and form-builder-permissions, which I also included at the bottom.

Some minor beauty mistakes perhaps: you don't immediately get to see all your apps when going to the form builder summary, if you have access to a finite number of them; you have to use search options and select the other apps to see their forms. Also, the summary "betrays" how many total forms there really are, even when you do not have access to all of them ("search returned 3 of 8 items").


So, the fact that form-builder-permissions are not working in the stable leads me to believe there is something wrong with the stable. Is this so, or is there a config that I forgot? I would very much like to see a stable in which this was fixed!



Something that did not work in either configuration, stable nor nightly, was the use of the variable $fr-roles in xpath expressions to determine visibility or read-onlyness of controls (like $fr-roles='admin'). I tried many expressions, and, using count, discovered $fr-roles is an empty list.
I finally found a work-around, being the function xxforms:is-user-in-role('admin'), which works in both stable and nightly.

If that function works, am I correct to presume that there is something wrong in orbeon concerning the initialisation of the $fr-roles variable? or am I still forgetting to configure something? This fix is less urgent as we luckily have the work-around  to use.


I was not able to test the new form-level permissions because I was using out-of-the-box Orbeon with exist. I may evaluate these later. (although I think I tried it out many weeks ago on mysql using a previous nightly, and it seemed to work - fingers crossed! )



To conclude; my question repeated: Am I missing some configuration for my container-based security? If so, I really really want to know :-). Or are there really bugs in Orbeon, and if so, when will they be fixed in the next stable release?



Thank you for any response,


Koen Vanderkimpen



ADDON 1: web.xml additions


        <security-constraint>
        <web-resource-collection>
            <web-resource-name>Everything</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>*</role-name>
        </auth-constraint>
    </security-constraint>
        <security-constraint>
        <web-resource-collection>
            <web-resource-name>Admin-only form</web-resource-name>
                        <url-pattern>/fr/admin</url-pattern>
            <url-pattern>/fr/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>
        <security-constraint>
        <web-resource-collection>
            <web-resource-name>No-anonymous form</web-resource-name>
                        <url-pattern>/fr/test/test1</url-pattern>
            <url-pattern>/fr/test/test1/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
                        <role-name>user</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/java-authentication/login</form-login-page>
            <form-error-page>/java-authentication/login-error</form-error-page>
        </form-login-config>
    </login-config>
    <security-role>
        <role-name>admin</role-name>
    </security-role>
        <security-role>
        <role-name>user</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon-user</role-name>
    </security-role>
        <security-role>
        <role-name>orbeon-admin</role-name>
    </security-role>
        <security-role>
        <role-name>*</role-name>
    </security-role>


ADDON 2: properties-local.xml


<property as="xs:string" name="oxf.fr.authentication.method"                       value="container"/>
<property as="xs:string" name="oxf.fr.authentication.container.roles"              value="orbeon admin user orbeon-admin orbeon-user"/>        


ADDON 3: tomcat-users.xml


  <role rolename="admin-gui"/>
  <role rolename="manager-gui"/>
  <role rolename="admin"/>
  <role rolename="manager"/>
  <role rolename="orbeon-admin"/>
  <role rolename="orbeon-user"/>

<user username="koen" password="koen" roles="admin-gui,manager-gui,admin,manager,orbeon-admin,orbeon-user,orbeon,admin" />
<user username="koen2" password="koen2" roles="orbeon-user,orbeon,user"/>
<user username="koen3" password="koen3" roles="anonymous,admin"/>


ADDON 4: form-builder-permissions.xml        

<role name="orbeon-admin" app="*" form="*"/>
<role name="orbeon-user" app="test" form="*"/>
<role name="admin" app="test" form="*"/>
<role name="admin" app="admin" form="*"/>
<role name="orbeon" app="orbeon" form="*"/>

Connect: Twitter








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: orbeon authorization evaluation

koenvdk
Thanks!

I will test this again sooner or later. Probably on your next stable release.
Any idea when that will be yet? :-)



Koen Vanderkimpen

Connect: Twitter




From:        Erik Bruchez <[hidden email]>
To:        [hidden email]
Date:        29/06/2012 21:10
Subject:        [ops-users] Re: orbeon authorization evaluation
Sent by:        [hidden email]





Koen,

This bug is now fixed!

-Erik

On Fri, Jun 22, 2012 at 11:14 PM, Erik Bruchez <ebruchez@...> wrote:
Koen,

First, thanks for the thorough evaluation!

Definitely it sounds like something is broken with $fr-roles and I entered an issue to fix for 4.0:

https://github.com/orbeon/orbeon-forms/issues/328

Now with regards to the stable build, it is quite possible that there is an issue as well, because the code handling permissions has been almost entirely rewritten. It is quite possible that nobody has found that issue with the stable build.

-Erik


On Thu, Jun 21, 2012 at 2:43 AM, <Koen.Vanderkimpen@...> wrote:
Hi,

I've been experimenting with the authorization mechanisms in Orbeon, as they are very important for our project. I tried a thorough evaluation of most authorization features.


To avoid any interference from outside, I started yesterday with two locally-run out-of the-box versions of Orbeon PE: the stable and the nightly build. I tried to do the minmimum configuration possible so as to get things working, and did the exact same things on both versions. I started with turning security on by changing the web.xml to protect some resources (see bottom of mail for full configuration changes). This functions normally in both versions, as is to be expected of any webapp. (of course, I also added users and roles in tomcat to test this, see bottom)


Then I turned to the properties-file, and turned on container-based authentication, declaring the necessary roles. Again, see bottom for all (2) the property changes that were made.


What I immediately noticed: in the stable version it becomes impossible under this configuration to create new forms; when you click new, you get an empty drop-down list for the application (and this without touching the default * * * config for form-builder-permissions). Even with various attempts at configuring form-builder-permissions or even form-runner-roles, I can't get this to work.

In the nightly build, however; this was fixed! Form builder permissions worked with a minimal config in web.xml, properties-local and form-builder-permissions, which I also included at the bottom.


Some minor beauty mistakes perhaps: you don't immediately get to see all your apps when going to the form builder summary, if you have access to a finite number of them; you have to use search options and select the other apps to see their forms. Also, the summary "betrays" how many total forms there really are, even when you do not have access to all of them ("search returned 3 of 8 items").



So, the fact that form-builder-permissions are not working in the stable leads me to believe there is something wrong with the stable. Is this so, or is there a config that I forgot? I would very much like to see a stable in which this was fixed!




Something that did not work in either configuration, stable nor nightly, was the use of the variable $fr-roles in xpath expressions to determine visibility or read-onlyness of controls (like $fr-roles='admin'). I tried many expressions, and, using count, discovered $fr-roles is an empty list.

I finally found a work-around, being the function xxforms:is-user-in-role('admin'), which works in both stable and nightly.


If that function works, am I correct to presume that there is something wrong in orbeon concerning the initialisation of the $fr-roles variable? or am I still forgetting to configure something? This fix is less urgent as we luckily have the work-around  to use.



I was not able to test the new form-level permissions because I was using out-of-the-box Orbeon with exist. I may evaluate these later. (although I think I tried it out many weeks ago on mysql using a previous nightly, and it seemed to work - fingers crossed! )




To conclude; my question repeated: Am I missing some configuration for my container-based security? If so, I really really want to know :-). Or are there really bugs in Orbeon, and if so, when will they be fixed in the next stable release?




Thank you for any response,



Koen Vanderkimpen




ADDON 1: web.xml additions



        <security-constraint>

        <web-resource-collection>

            <web-resource-name>Everything</web-resource-name>

            <url-pattern>/*</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <role-name>*</role-name>

        </auth-constraint>

    </security-constraint>

        <security-constraint>

        <web-resource-collection>

            <web-resource-name>Admin-only form</web-resource-name>

                        <url-pattern>/fr/admin</url-pattern>

            <url-pattern>/fr/admin/*</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <role-name>admin</role-name>

        </auth-constraint>

    </security-constraint>

        <security-constraint>

        <web-resource-collection>

            <web-resource-name>No-anonymous form</web-resource-name>

                        <url-pattern>/fr/test/test1</url-pattern>

            <url-pattern>/fr/test/test1/*</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <role-name>admin</role-name>

                        <role-name>user</role-name>

        </auth-constraint>

    </security-constraint>

    <login-config>

        <auth-method>FORM</auth-method>

        <form-login-config>

            <form-login-page>/java-authentication/login</form-login-page>

            <form-error-page>/java-authentication/login-error</form-error-page>

        </form-login-config>

    </login-config>

    <security-role>

        <role-name>admin</role-name>

    </security-role>

        <security-role>

        <role-name>user</role-name>

    </security-role>

        <security-role>

        <role-name>orbeon</role-name>

    </security-role>

        <security-role>

        <role-name>orbeon-user</role-name>

    </security-role>

        <security-role>

        <role-name>orbeon-admin</role-name>

    </security-role>

        <security-role>

        <role-name>*</role-name>

    </security-role>



ADDON 2: properties-local.xml


<property as="xs:string" name="oxf.fr.authentication.method"                       value="container"/>

<property as="xs:string" name="oxf.fr.authentication.container.roles"              value="orbeon admin user orbeon-admin orbeon-user"/>        



ADDON 3: tomcat-users.xml



  <role rolename="admin-gui"/>

  <role rolename="manager-gui"/>

  <role rolename="admin"/>

  <role rolename="manager"/>

  <role rolename="orbeon-admin"/>

  <role rolename="orbeon-user"/>


<user username="koen" password="koen" roles="admin-gui,manager-gui,admin,manager,orbeon-admin,orbeon-user,orbeon,admin" />

<user username="koen2" password="koen2" roles="orbeon-user,orbeon,user"/>

<user username="koen3" password="koen3" roles="anonymous,admin"/>



ADDON 4: form-builder-permissions.xml        


<role name="orbeon-admin" app="*" form="*"/>

<role name="orbeon-user" app="test" form="*"/>

<role name="admin" app="test" form="*"/>

<role name="admin" app="admin" form="*"/>

<role name="orbeon" app="orbeon" form="*"/>

Connect:







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:
[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