Altering The Presentation Of A Service Depending On Identity

Work Completed By: Terence Rich Whitehead


There is a clear link between identity and the contextual access concept put forward as part of our New Wave Applications strategy, the idea being that information and services should be tailored to the person using them, based on our understanding of their interests, needs, clearance and physical context.
This project is concerned with showing how an individual service can be presented in different ways depending on the identity of the person who is accessing it. For example:

• An individual may choose to organise or categorise the information form a service in a particular way.
• An individual may only require a subset of a service.
• An individual may only be interested in the information from a service that is directly related to themselves.

Show how a web service (can be WCC originated or from another source) – can be altered and presented in different ways when used by at least three different identities.


Details of where code, web pages etc can be found.


Details of the work carried out.

The first stage of the project was to understand how services can be presented to a user depending on who they are. What they are allowed to access and how a services are presented to individual users.

The second stage was to investigate any products that my already be available that may go someway to meeting the basic requirements.

The third and final stage was to implement a product that was already available, customise an existing product or produce an outline design for a system that would go someway to meeting the requirements.

Understanding the problem

Modelling a user consists on what they are allowed to do in combination the roles they for fill. Users will have one or more roles. Using WCC as an example offering a range of services to a broad user community that can range from a member of the public to a chief executive with each having one or more roles. It is therefore important that any system has the minimum granularity to model a mix of user roles, services and access control. This model could be complicated still further if full auditing of user access was required.
For this project a small sample of typical roles that may be found within WCC:-

  • Councillor
  • Employee
  • Highways
  • Human Resource
  • IT
  • Manager
  • Parks and Leisure
  • Press Office
  • Public

For an example an employee could work in IT as a manager, therefore having four distinct roles (Public, Employee, IT and Manager).

Each role for these roles a user has would have a range of services that they should have access to in order for them to carryout there role. Therefore each role should relate to one or more services. For example an employee would require access to a word processor but an employee in HR would require access to a word processor and HR systems.

The simple diagram below shows some of the entities that need to be modelled and their relationships.


Fig 1 – Simple framework schema

Database Table Details

Table Description
Users This represents the users identity via an unique email address and their name. In a real would this table would have more attributes or even link to additional user related tables.
Roles A key word to represent a role, again a the real would this table would have included such attributes as a description etc.
Services A keyword used to group a range of services.
Sub_Services Applications that come together to provide a service (group). For example a range of office services may consist of a word processor, a spreadsheet, an email client etc.
Role_Services This table combines roles with the services they require.
User_Roles Each user is assigned one or more roles.

This represents basic view on what would be required to model users and the services offered to them.

Other requirements of any system should be as follows :-

  • Web based
  • Ability to invoke web services
  • Ability to handle different logons to various services
  • Users to customise what services they wished to receive.
  • Users able to customise how services are presented.

Investigation of Products

After may hours research no single product was identified that looked like it would get anywhere near meeting the requirements identified above. However, a few products did look interesting and warranted further investigation.

Product Description Comment
MindTouch ( Primarily a CMS and collaborative tool but has the capabilities to invoke web services via ‘extensions’. Encountered problems installing. Problems accessing remote services (RSS Feeds).
Saurus CMS - Another CMS and collaborative tool again having the capabilities of invoking web services via its SSO tool ( Unfortunately this product failed to install.
Mochaui ( A framework that provides a desktop environment from within a web browser. For an example then visit ( Interesting product that could have potential to deliver a virtual desktop. See screen shot below.

Fig 2 - Mochaui


MindTouch Based on a deki but with the ability to invoke web services via extensions. Some are included as the standard install or the user/administrator can create their own extensions. I theory it should be possible to invoke such things as Google apps, but there appears to be one key ingredient missing and that is the ability to access individual user accounts for remote web services. With some development work and with a impending release of an improved MySQL extension it could be possible. At present Mindtouch does handle multiple groups.

Accessing simple web services such as RSS feeds was problematic, more than likely down to firewall problems. However, the way these RSS feed were accessed appeared to be via the web server and not direct from the browser. Accessing all services via a central server has the potential to place large volumes of data traffic on the server which really should be avoided.


Saurus looks in interesting product particularly in the way it handles user roles. Problems were encountered in installing the product as it requires the Zend Framework. Due to the short time scales it was not possible to install and investigate the potential of Saurus.


Mochaui can be customised to present various web services. It can also be used as a front end to systems offering the control of content and access based on their user role.


As no systems were found that met the basic requirements of this project it was decided to design a simple framework that could handle content and access based on users and their roles. To achieve the requirement to allow the user to select what sub services they require required an additional table to allow the user to opt out of a sub service.

Available services are presented to the user via a web browser as a simple web based desktop. Once logged in the user is presented with their own applications based on the services they are allowed to use. For this demonstration system several service groups were created :-

  • Internet – Simple internet applications as an example a web browser accessing external web sites.
  • Intranet – Simple intranet application as an example accessing internal web sites.
  • App_admin – A set of administration tools as used by an administrator
  • Myconfig – A users configuration tools where they can opt in and out of applications or set passwords for remote web services.
  • Office – A set of office tools as an example using some of the Google apps.
  • etc

Fig 3 – Simple user web based desktop

I was felt that whilst this implementation proved that the basic design of the framework worked, the presentation of the virtual desktop was dull and inspirational. What was needed something with more user appeal. The project then took a brief look at what could be achieved in using iframes, something that allowed users to move, resize and iconise windows just as on a normal desktop. To produce the software to achieve this would take many weeks. Fortunately there are others out there with similar ideas and a rather interesting virtual desktop framework was found in Mochaui.

Mochaui is an user interface based on mootools that offered a far better way of achieving a virtual desktop. However, the product would require some customisation to meet the projects requirements. It took a day to map Mochaui onto the user identity framework. It may have not been the most elegant bit of coding but it successfully demonstrated that both Mochaui and the identity framework could work together. Most web applications will work within Mochaui however; one noticeable exception was discovered in Google docs. Google docs can be invoked but the page is forced to run outside an iframe (iframe busting code) which results in the page been displayed in a new tab or browser window!


Fig 5 – Mochaui Login

A small amount of time was also spent exploring what could be achieved with MindTouch as the product handled multiple roles and could employ extensions to access web services. It was with the access to external web services that problems found mainly due to the presence of a proxy at WCC. ON the face of it, it looks like MindTouch accesses web services directly and forwards the content to the browser and not directly from the browser itself. Accessing web services form the browser would be better in meeting the objectives of this project as it reduces the load on the server.


Describe the degree to which the work was successful in addressing the project description. Include reasons why or why not.

The project was successful although no products were identified that could readily meet the projects goal. What the project did achieve was the outline design of a framework that could have the potential to meet the requirements of delivering services to a user based on their role and also be customisable by the user.

The designed of a framework

This project has produced a framework for the presentation of web services based on a users identity. The framework was designed to be installed as a central resource purely for the identification of users, any service accessed by the users having been correctly identified is to be invoked directly from the users browser thus reducing the number of calls to a central server.

Two simple login services return the services that the user is allowed to use and the sub services they have opted to receive. In this development the data returned as a simple text stream, Ideally this should be returned as an XML stream which if structured correctly would remove the requirement for a second Ajax call. The reason this was not implemented for this development was simply a case limited development time.

If XML was used to pass information to the browser then a theoretical structure would take something along the example shown below:-

<?xml version="1.0" encoding="UTF-8"?>
        <name>Terence Rich Whitehead</name>

Fig 6 - Suggested Desktop XML Structure

The structure consists of three main node types:-

  • User – This comprises of basic user identification
  • Services – This node groups contains all the services and sub-services that are available to the user. It also contains details of how the service is accessed etc.
  • Desktop – This is a representation of the users preferred desktop, background colours etc.

Neither of the two demonstration systems contains user configurable desktops due to the short development timescales of the project. However, it would very simple to include this information in the users profile held in the central database.

How It Works

The whole process is very straight forward. The user logs via the central server using a user id. The demonstration framework did not include a password at the login phase. However, it can be implemented very easy by adding an additional field to the users database table that contains a hashed password.

If the account details are not recognised the user is only granted public access, if they are recognised then their user profile is dynamically created from information held in the central database. The users profile is then passed back to the calling browser which then interprets the response and displays the custom desktop to the user. Below is a flowchart of the data flows, note this diagram is based on the demonstration system. If the data was returned as an XML stream then only one call to the central server would be required.


Fig 7 - Dataflow

The Database

The full database schema for a database that provided a virtual desktop based on a users id their roles is shown below. Both the demonstration systems use this schema except for the user_desktop table. The user_desktop table holds the users customised desktop.


Fig 8 – Database Schema

This schema is very much the same as the one at the beginning of the document except for three addition tables.

  • user_optout – Contains a list of sub-services that the user has chosen to opt-out of.
  • user_passwords – User dependent account names and password that a user requires to access some sub-services.
  • user_desktop – Not implemented, but provides user property name/value pairs that can be used by users to customise their virtual desktop.

There is however one major problem with the user_passwords table as at present both the user and password fields are stored as unencrypted data, in a live system this would not be acceptable. One way around this could be to use an encryption algorithm on these fields based on the user’s id (email) and main password. The only problem would be when a user changes their main password their sub-service passwords would be invalid. The only thing that could be done is when a user changes their main password their sub-service passwords are re-encrypted.

To aid the querying of data from the database relating to a user and the services available to them the following database view was required.

select distinct 
  `roles`.`user_roles`.`email` AS `email`,
  `roles`.`user_roles`.`role` AS `role`,
  `roles`.`role_services`.`role` AS `role01`,
  `roles`.`role_services`.`service` AS `service` 
from `roles`.`user_roles` 
  join `roles`.`role_services` 
  (`roles`.`user_roles`.`role` like `roles`.`role_services`.`role`)

Fig 9 – SQL for User Services View


Fig 9 – Sample data from user services view


A series of administration pages were created to enable the maintenance of users, roles and services.


Fig 10 – Administration Via the Mocha desktop

Implemented framework into Mochaui

An attempt was made to map Mochaui onto the framework. The methods and coding was not the most elegant but it proved the principle. If this project was to go any further then this area would need a lot of refining in order to provide a slick implementation.

Centralised System

One of the problems with the implementation of this project is that the delivery of services is centralised. Whilst this makes administration easy it is not best practice to have such a key resource on a single server or in one location. If the framework could be designed to be hosted on a network of trusted machines then the overall reliability would be infinitely more reliable.

Security Considerations

Although the demonstration system produced controlled what services were placed on the users virtual desktop it does not offer control for the point of entry for any service. For example if a user knows the URL for a service there is no way that this framework can stop someone accessing a service if the service itself does not have any security controls. This underlines the need for all services to have their own access controls.

Service Delivery

Some debate arouse over this project about how service should be presented to the user. As an example this project used a browser with a virtual desktop to deliver a service. Is this the way we should be delivering services or should we be looking for something different and what would the user community expect? Added to this variety of devices that can be used to access services, do we just cater for standard PC web browsers or look to mobile devices, set top boxes, the Wii etc.

What next

If the outcome of this project is seen as a step in the right direction then one thing that may be of use is to try and implement all the functionality of the framework as a set of services using SOAP.


What immediate impact could the output of this R&D work have on the organisation – could it provide benefits without compromising our strategic approach?

The outcome of this project has produced no short term benefits for WCC. What it has demonstrated is that web services can be delivered to users based on their roles. It also demonstrates that a user can have some control of how these services are presented.

The framework designed in this project does not offer a totally secure system as it only presents services to users. What it does not control is the point of entry to those services. Perhaps what should be investigated is an architecture that provides such a security model.


How the work carried out fits with our strategic direction or how it should contribute to our strategic thinking.

What this project demonstrates is that services can be delivered to users via a web browser which means there is no reliability on a particular operating system. Also no great computing power required at the desktop and the use of cheaper operating systems means the cost of ownership can be reduced.


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License