Damon described very well how things should be done: defining roles at the container level to authorize each page, then detect the roles within the application (typically with the Request Security generator and <p:choose> in pipelines) to determine if different actions must be taken depending on the roles. We have used that approach successfully in real-life projects.
A very simple example of this is an application that has different users allowed to access different customers stored in a SQL database. You will typically get the username from the Request Security generator, and feed that username to a SQL query to access a "user" table joined with a "customer" table (how you do this is entirely up to you when you design you db schema).
In addition, an administrator role may allow a user to access all products. In this case, you may have to run two different SQL queries, one for the administrators that lists all products, one for non-administrators that list only specific products based on their username. You would do something like this in XPL:
<p:processor uri="oxf/processor/request-security">
<p:input name="config">
<config><role>admin</role></config>
</p:input>
<p:output name="data" id="request-security"/>
</p:processor><p:choose href="#request-security">
<p:when test="/request-security/role = 'admin'">
<!-- Execute query here to get data for administrators -->
...
</p:when>
<p:otherwise>
<!-- Execute query here to get data for non-administrators -->
...
</p:otherwise>
</p:choose>It may be a good idea to extend the WAC to check for roles. Using XACLM for the WAC configuration may be going a little too far, but we have to think about the implications of this!
-Erik
> This is pretty much what I am working on at the moment too. Here are some
> comments.
>
> Container level:
> ==========
>
> - I have got a JNDIRealm in the tomcat context.xml that authenticates the
> users from LDAP using credentials from the form based logins.
> - I am using the 'userRoleName' in the jndirealm to map an orgunit
> attribute to a Tomcat role. This gives me one set of roles.
> - Allow all named roles access into the root.
> <url-pattern>/</url-pattern>
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> - I am planning an additional set of application specific groups
> 'Myapp.Administrators' in the LDAP directory. These groups will be used to
> provision the administrator role using the rolebase and rolesearch in
> JNDIRealm.
> - Optionally restrict url access based on the user being in the right
> orgunit OR having administrator rights.
> <url-pattern>/orgunit1/*</url-pattern>
> <auth-constraint>
> <role-name>administrator</role-name>
> <role-name>orgunit1</role-name>
> </auth-constraint>
>
> Application level:
> ============
>
> If necessary do more fine-grained security in the application.
> - In OXF you can use the request-security generator to get at the container
> roles.
> - Use the ldap processor to add extra roles that couldn't be done at
> container level to the users sessions.
> - Within all model.xpl and action.xpl files redirect users manually to the
> login page if they are not in the right role.
> - Within views you can use <xsl:if test="{role select}"/> in the view to
> show/hide/grey-out action links.
>
>
>>My question is this, what is the most graceful way to check that they are
>>logged in and have the correct permissions to be there on each page that
>>required it?
>
>
> Perhaps the web application controller could have some simple role-based
> security added to it.. Something allow the lines of..
>
> <page id="myid" path-info="/photo.html" model="oxf:/photo.xpl"
> view="oxf:/photo.xhtml" deny="guest">
> <action when="/form/action = 'delete'" action="oxf:/action.xpl"
> grant="administrator"/>
> </page>
>
> This way we don't need code in the model.xpl or action to check the users
> permissions.
>
> Addendum:
> ========
>
> Going quite a lot further down the application level security track gets you
> too the idea of OXF xacl extensions to some of the main processors.
> http://www.trl.ibm.com/projects/xml/xss4j/docs/xacl-readme.html
>
> <policy>
> <xacl>
> <object href="/"/>
> <rule>
> <acl>
> <subject>
> <group>my group</group>
> </subject>
> <action name="read" permission="grant"/>
> </acl>
> </rule>
> </xacl>
> </policy>
>
> The processor extensions could be:
> - input -> Policy xml containing xacl elements.
> - input -> Security principal/info (username + list of groups the user
> belongs to)
> - input -> A piece of xml that the xacl references (probably by id rather
> than href?).
> - output -> The original piece of xml marked up with grant/deny attributes.
>
> Here is an interesting use case for these processor extensions:
>
> - A controller.xml file contains a list of all the pages in an application
> and the actions associated with each page.
> - An ldap user object contains a list of all groups a user belongs too.
> - A policy document contains acls for each page and action, etc.
>
> <p:processor uri="oxf/processor/identity">
> <p:input name="data">
> <controller>
> <page id="1">
> <action id="a1.1" />
> </page>
> <page id="2"/>
> </controller>
> </p:input>
> <p:input name="associated-policy" href="" />
> <p:input name="associated-status" href="" />
> <p:input name="associated-context" href="" />
> <p:output name="data" id="output"/>
> </p:processor>
>
> - Output should contain a sitemap document that only contains pages/actions
> the user has access too.
> - Use the output and an xslt to generate the application menu and action
> list..
>
> Regards,
> Damon.
_______________________________________________ oxf-users mailing list [EMAIL PROTECTED] http://mail.orbeon.com/mailman/listinfo/oxf-users
