XWiki/Auth Integration

Authorisation

By default XWiki stores documents, document rights, user information and group information in its own database. Documents exist in a space such that 'space'.'page' translates into a URL path 'space'/'page'. Spaces may not be nested, but pages may have parents (which manifest in 'breadcrumbs') allowing for arbitrarily deep hierarchies of pages.

A space is essentially an administrative zone, for which there can be users or groups with rights for that space only. Rights may be attributed to users or groups at a document, space or wiki level. There are several rights; admin, view, edit, comment, delete, undelete, register, programming.

The integration with the OpenSolaris auth application means that there is an external (to XWiki) repository of user information, meaning that users WILL NOT be stored in the XWiki database. It is given that spaces and documents MUST exist in the xwiki database. There MUST also be a relationship between the auth app collectives and XWiki spaces.

The integration is the implementation of 3 Java interfaces that XWiki uses to determine information about authentication, rights and groups. There are at least two implementation possibilities;

1) Rights are attributed to groups, which act as roles, allowing for the mapping of auth app roles (a tuple of member, collective and standing within the collective) to XWiki groups by the implementation of the XWikiGroupService interface. Groups themselves WILL NOT be stored in the XWiki database; they will be constructed by the new XWikiGroupService implementation based on the auth app information, however the rights associated with those groups WILL be stored in the xwiki database.

In this case the relationship between spaces and collectives is that for every collective, there is one or more groups with associated rights, for example, the JKStat Project collective has wiki pages in the space "project_jkstat". There are groups "project_jkstat_contributors" and "project_jkstat_leaders" with "edit" and "admin" rights respectively. These groups are contrived by the XWikiGroupService implementation, which holds a cached set of all such groups derived from the auth app's information. Group membership is determined by a user's role in the collective - contributors are members of project_jkstat_contributors, leaders are members of project_jkstat_leaders.

 Advantages;

• managing permissions for groups (read 'roles') and anointing users with group (role) membership is an established access control practice which simplifies the management of permissions
• existing XWiki rights administration pages may be used, giving the greatest possible flexibility in manipulating permissions for groups - different spaces may have differing rights for leaders, contributors and participants
• collective/space rights may be administered by collective leaders, distributing the effort
• since right are stored in the xwiki database, there is no need to use a new implementation of the XWikiRightsService - only the XWikiAuthService and XWikiGroupService need to be implemented

 Disadvantages;

• flexibility means permissions can be changed, with the possibility of mistakes
• rights must be administered each time a new collective is added (there is a possibility that this might be automated to set 'default' permissions)

2) Rights are attributed to users based on the standing in the collective represented by the space which is being accessed, and the collective TYPE of that collective. These rights will NOT be stored in the xwiki database and as such the existing rights administration pages are defunct. Note that the use of collective type here is crucial -- having required levels for each right for each collective would mean that information must be stored somewhere, probably a database. The auth app, by design, will not store this information, and the xwiki database knows nothing of collectives or collective types, so some form of synchronisation between the two would be required. By contrast, collective types will seldom (if ever) change, so the required level information may be stored in a configuration file, at the cost of reduced flexibility.

Using the same example as above, the edit right is granted to the user wishing to edit porject_jkstat space pages based on the user's standing in the JKStat Project collective AND the required standing for that access level of the 'Project' collective type. So, assuming some scale of standing between 0 and 100, if the user's standing is 50 and the required level for edit rights in a project collective type is 40, the user can edit the page. By extension there would be required levels for the other rights, e.g. 60 for admin, but those may vary by collective type. The community type's edit level may be 20, for example. In the case where every user is to be granted edit rights, such as the documentation 'howtos' use case, all users will be of a suitable level in the Documentation Howtos Community. To put it another way, every user would be a leader in the Documentation Howtos Community.

Advantages;

• it is a very simple model
• no rights administration is required in XWiki; only by manipulation in the auth app of the user's standing in a collective may access be granted or denied
• since groups are not used, only the XWikiAuthService and XWikiRightService interfaces need to be implemented

 Disadvantages;

• it is not flexible

Authentication

Whatever authorisation scheme is implemented, authentication is a common element. The auth app model is such that to enable single sign on across OpenSolaris websites, the authentication must be performed by the auth application which will issue a cookie for the opensolaris.org domain. Sites external to the opensolaris.org domain may use the returned cookie payload to set their own cookies, but it is the opensolaris.org cookie which is checked by the auth app when authentication is deemed necessary.