Orbeon Page Theme and Menu Items Based on User Role

Orbeon xForms when deployed within a webapp container like Tomcat can be accessed at http://localhost:8080/orbeon/.  Here you will get the pre-packaged orbeon samples which are all included in the apps directory.  Orbeon uses a combination of xml, xsl, xpl and xhtml files when displaying this web application of samples.  If you like the theme (style) applied to the web pages, but want to personalize to your web applications including the menu of applications, you need to have an understanding of what components are used within orbeon.  Below is some documentation on how I used the pre-packed files and modified them to display various orbeon resource apps based on a logged in user's role.  The files that you will need to investigate and understand are apps-list.xml, theme-examples.xl, model.xpl, web.xml  and xhtml files located within your orbeon resource apps.

Console Menu Links/Navigation Components

Apps-list.xml - out of the box lists all the orbeon samples in the left navigation menu when you view orbeon web app in web browser.  Modify this file and comment out Orbeon samples and add your applications. 

How is apps-list.xml used?  

The apps-list.xml file is imported into theme-plain.xsl and used to create the menu list within our web console.  In order to display only those resources the logged in user has access to, apps-list.xml was modified to include a ‘role’ attribute on the sections element and the applications element.  The section element is the heading within the menu and the application element is the actual web application resource underneath each heading.  User roles are placed within the role attribute separated by a space.  If a user is authorized to have access to an application within our web console, then the user’s role must be placed within this role attribute within apps-list.xml.

Theme-examples.xsl and {YourApplicationName}.xhtml - Theme-examples.xsl provides the formatting for all xhtml files within our console.  If you wish to apply a different theme, you can place a theme.xsl file with your required format at the root of each application located under the resources/apps directory.  Currently, the only application in our list of orbeon resource applications that uses a modified theme (theme.xsl) is the java-authentication application that comes with Orbeon.  You can use Orbeon's theme-plain.xsl as a starting point and modify it to suit your needs.  Since the user is not logged in at this point, no menu items should be displayed.  If you want to alter how the login screen appears, modifications to this theme.xsl and/or the appropriate xhtml file is required. 

Before an application's xhtml file is presented to the user, the file is sent to epilogue.xpl if the xhtml file contains a model element (<model>).  If the xhtml file does not contain a model element, then the file is just presented to the user.  The epilogue.xpl file is located in each applications page-flow.xml file.  The epiloque.xpl file processes the xhtml file.  The xForms processor converts orbeon extensions into html elements.  The epilogue.xpl file calls the theme-plain.xsl file, or your theme.xsl file, and the processed xhtml file is passed as the data input to the theme-examples.xsl.  Therefore, to access the processed xhtml file within the xsl, you traverse the html DOM with /html:head being the root node.  If you view the source code of one of your web pages, this is what is accessible to the xsl file. 

So how do we get the user's role accessible to the theme-examples.xsl file?

Within each one of our xhtml files, the users credentials are stored within an instance.  This is explained further in the Access Control section which follows shortly.

                              <xforms:instance id="security" xmlns="">

                                          <xi:include href="input:data"/>

                              </xforms:instance>

                  OR

                              <xforms:instance id="userInfo" xmlns="">

                                          <xi:include href="input:data"/>

                              </xforms:instance>

When the form loads and authentication matches a user within our Apache DS LDAP, <xi:include /> is replaced with the login information:

<xforms:instance id=”security’>

  <request-security>
    <auth-type>FORM</auth-type>
    <secure>true</secure>
    <remote-user>scott</remote-user>
    <user-principal>scott</user-principal>
    <role>user</role>
  </request-security>

</xforms:security>

Since the xsl file does not have access to instance data, the user’s role is sent to an xforms output control immediately under the body of the xhtml file.  The style color is set to white so the control’s value is blended in with the background of the form and is not visible to the user.  If you attempt to set the relevancy of the control to false, the value will not be available to the form and therefore not available to the xsl file so that is why we just blend the role with the background color.  The xforms output control has an attribute name set to id.  The value of the attribute is set to role.

<xforms:output id="role" style="color:white" ref="instance('security')/role" />

When the xhtml is processed, the xforms output control is converted to a span html element.  This attribute is available within the span html element. 

<span id="role" class="xforms-control xforms-output" style="color:white">officer</span>

Since the theme-examples.xsl has access to the html document structure, an xsl variable called role is created with its value set to the xpath expression locating the span element with an attribute named id. 

<xsl:variable name="role" select="/xhtml:html/xhtml:body//xhtml:span[@id = 'role']" />

This variable is then used within the left content (list of applications) section of the xsl file to control which ‘Sections’ and ‘Applications’ are displayed to the user based on their role.  The xpath expression within this part of the xsl was modified to include an xpath contains() function which looks at the role attribute we defined within the apps-list.xml file.

<xsl:for-each select="$applications/*/section[contains(@role, $role)]">

And

<xsl:for-each select="application[contains(@role, $role)]">

So, depending on who logs in, we display only those resources available to them based on their role.

Application Access Control

Model.xpl - The model.xpl is called for each xhtml file and is defined within the page-flow.xml.  The model.xpl file is located at the root of each application. 

<page path-info="/home/" model="model.xpl" view="view.xhtml"/>

Within the model.xpl file is the orbeon request-security processor.  The request security processor extracts information about the currently logged user from the client request (Tomcat). Its configuration contains a list of roles the application developer is interested in. Only those roles will be listed in the processor's output if the role is present.

<p:processor name="oxf:request-security">

        <p:input name="config">

            <config>

                <role>da</role>

                  <role>vendor</role>

            </config>

        </p:input>

        <p:output name="data" ref="data" debug="xxxxx"/>

    </p:processor>

The output of the processor is stored within the security or userInfo instance within each xhtml file as described in the theme-examples.xsl narrative.

Web.xml - Access control to the applications is provided by adding three sections to the web.xml file:

•  In <security-constraint> you define which role (with <role-name>) is required to access which part of the application (with <url-pattern>). 
•   In <login-config> you define how the user will authenticate himself. In other words, what method is used to get the user name and password. This can be done either with a form in an HTML page or with standard HTTP authentication. The names of those methods are: FORM and BASIC. In the example below, the form mechanism is demonstrated
• In <security-role> the security roles used in <security-constraint> section are declared

<security-constraint>

        <web-resource-collection>

            <web-resource-name>User Access</web-resource-name>

            <url-pattern>/java-authentication/</url-pattern>

                              <url-pattern>/home/</url-pattern>

                  </web-resource-collection>

        <auth-constraint>

                              <role-name>vendor</role-name>

            <role-name>da</role-name>

                              <role-name>it</role-name>

                              <role-name>officer</role-name>

                              <role-name>supervisor</role-name>

                              <role-name>idcenter</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>vendor</role-name>

                  <role-name>it</role-name>

                  <role-name>da</role-name>

                  <role-name>officer</role-name>

                  <role-name>supervisor</role-name>

                  <role-name>idcenter</role-name>

    </security-role>

The user information is retrieved through j_security_check from Tomcat using JNDI Realm with user information and roles stored in Intalio Embedded Apache DS LDAP.  If the user is not authenticated, the page is not displayed. 

Configuration Summary

The displaying and/or hiding of menu items in the navigation bar is not intended to be security, but rather to clean up the user interface so applications a user does not have authorization for do not clutter up the screen and/or confuse the user. 

The log-in form with Tomcat Form Based Authentication using JNDI Realm (Apache DS LDAP) are to provide access control to our resource applications.  So if a user writes down a URL they see from another users web browser, even if they do not see the menu link based on their assigned role, they will be displayed with an access denied error page if their credentials/role does not match with the web.xml configuration file.

This information is provided by BTM Software Solutions.

Intalio with Orbeon XML Validation Service

I recently created an XML validation service using Orbeon to validate XML sent into a business process. The Intalio business process retrieves the XML from eXist XML database and then I call a REST service. The REST service is actually an orbeon webapp that consists of an XPL file with several processors (validation processor and xsl processor) included within the XPL file.  If the XML is valid, the REST service sends back an empty error message and the process proceeds.  If the XML is invalid, the validation processor marks the element that is invalid with an error element <v:error> with some descriptive information.  Before sending back the message to Intalio I transform the validation XML output to only include information about the error.  The XML error message contains information about the XML document, the parent node of each error so user knows which element(s) contains the error, the value of that node(s) and the message contained within the <v:error> element(s) sent back from the Validation processor.  The Intalio process then sends an HTML formatted email to the user.

Example of email:

Message: The complaint you submitted has the following errors. Please correct these errors and then resubmit your complaint.

OTN: R04-12345

Officer: Police Officer1

Department: X Regional Police Department

Defendant: Kitty Meow

PersonSexCode: XN Error the value is not a member of the enumeration: ("U"/"F"/"M")

This solution was developed by BTM Software Solutions.  Our web-site address is http://BTMSoftwareSolutions.com for more information.