"Show notes" for this episode…

Episode 007 - The User & Group Service

Synopsis

All MoReq2010 compliant records systems must have users. James and Jon review how these are managed through the user and group service, which may be implemented either as a standalone service or as a wrapper for a directory service. They discuss how placing users into groups allows their access to the records system to be more easily managed.

Featuring

James Lappin and Jon Garde

When recorded

January 2012

Running time

69 minutes

Main topics discussed

The user and group service is the first service to be described in detail in the MoReq2010 specification
The specification was organised so that readers understood what users were before they went on to read about other services
Nearly all the functional requirements in MoReq2010 refer to functions performed by an “authorised user”
Together with the role service MoReq2010 explains early on what authorisation means
Users are the hub of a records system: they perform the actions in the records system and the purpose of the records system is for their benefit
The two sides of being a user are:

What functions did a particular user historically perform, and
What functions is a particular user allowed to perform on a particular entity.

To manage and preserve records a records system must hold information (records) about the record in the form of an event history
The users are proactive actors in the system performing functions which generate events
The management of users and groups is not unique to a records system – it is a universal problem
In authoring MoReq2010 it was important to reuse existing services for managing users and groups, rather than forcing suppliers to reinvent this area of information technology
The concepts of restricting access controls by user and logging what actions a user performs exist in almost every system
It is unlikely within an organisation that the records system would be the natural place for creating users and groups across the corporate network
The business system that is most often utilised to provide organisations with centralised management and control of users and groups is called a “directory service”
Directory services date back to the X.500 service (ISO 9594) that was developed in the late 1980s and early 1990s
Rather than mandating that the user and group service in MoReq2010 must allow the creation and modification of users and groups, the specification allows this service to wrap a directory service (for example, like Microsoft Active Directory or any LDAP directory, etc.)
The users and groups are updated in the directory service using whatever functionality the directory service provides
However, MoReq2010 requires that the user and group service provide some additional functionality not normally found in directory services
Corporate directories contain a database of information about the users and groups in an organisation
(A user can belong to several groups)
However, corporate directories rarely manage historical information well – the information they contain is transient
Therefore a MoReq2010 records system cannot rely on the corporate directory to manage information about users and groups – old entries and information in the directory service may have been deleted or removed
The problem faced in developing the specification was how to reconcile the need to keep historical information about users and groups with the desire not to reinvent the directory service just for records systems
This problem was resolved by developing requirements that required that the historical information be kept by the user and group service but without requiring that the user and group service be used to manipulate users and groups
For example, compare the record service to the user and group service:

R6.5.3 The MCRS [i.e. the record service] must allow an authorised user to modify the Title, Description and Scope Notes of an active aggregation…
R3.4.10 The MCRS [i.e. the user and group service] must support a process for updating the Title and Description of an active group…

Note that the record service does not require that this be done by an authorised user from within the MCRS – it can be performed externally – however the MCRS must make a record of the change (in the event history of the entity)
The MoReq2010 functional requirements do not specify where information is held
If the user and group information is being held in a directory service then either the directory service must be able to keep a record of all changes to user and group information or there must be an additional layer provided by a wrapper that tracks changes to information in the directory
Some directory services may be able to be configured to keep historical information about such changes (e.g. in a log file)
Another way of doing this is to use the records system to mirror the information in a corporate directory
MoReq2010 does not require that all of the information be mirrored – it is only necessary for the user and group service to keep the information that it needs in relation to the records that it holds
Not every user may be accessing the records system
The MCRS only needs to know about users that access the records system and only about changes to those users at the point at which they do access the records system
For example, if the name of a user changes (e.g. a change to a maiden name on marriage) then it is only necessary to record the change of name on the next occasion the user accesses the record service (i.e. it may not be necessary to record the change immediately)
One issue that is sometimes encountered within corporate directories is when administrators delete entries and recreate them
This has the effect of generating a new identifier for a user within the directory service
For this reason directory service identifiers can be unreliable – a single user may have more than one corporate identifier through time – MoReq2010 therefore requires that users also have a MoReq2010 system identifier (UUID) which should be immutable (all corporate entries for the same person should point to the same MoReq2010 system identifier)
MoReq2010 entities including users and groups should use their own identifiers and not rely entirely on external identifiers
Extranets are becoming popular where organisations want to collaborate with other users who are not in the internal corporate directory service
In the past this might have meant entering the external users into the internal directory service
Some organisations favour a token system where the extranet has a trust relationship with another external directory – the external users are not transferred into the internal corporate directory
This scenario has been progressively realised over the last decade with organisations interested initially in publishing to the web from an internal records system, then collaborating with other organisations, and most recently in making records public through the open data initiative
Some of the technical realisation of these increasingly complex trust relationships is too low level for MoReq2010 to be able to specify with generic criteria
However, it is interesting that the modular architecture of MoReq2010 does help to resolve this situation by allowing a records system to have and respond to multiple user and group services
A MoReq2010 compliant records system may be set up to recognise users registered in the corporate directory through one user and group service and external users through one or more separate user and group services
The external users may use different methods of authentication - for example, OAuth, Facebook account, etc.
MoReq2010 does not require that all users and groups belong to the same user and group service – a single MCRS may have users from different user and group services
This may be a simpler approach for some organisations than registering external users in the internal directory or establishing wide trust networks
There are different aspects to groups in MoReq2010:

They represent interesting metadata about users
They can be used to manage access control for the users in that group
Groups can be used to represent positions within an organisation

The most important of these is the management of access controls – rather than micromanage a business system it is best practice to assign access controls at the group level – users can then be moved into or out of these groups and by so doing inherit different levels of access to the records system
Where it is the user’s group membership that allows a user to perform functions on an entity through the assignment of access controls it is necessary to keep track historically of what groups a user was a member of at an historical moment in time
MoReq2010 does not acknowledge group hierarchies – it only records (all) the groups that a user belongs to
For example, a corporate user might belong to a section, inside a branch, inside a division – the MCRS would only track that the user was a member of these three groups – not the implied hierarchical/organisational relationship between these groups
Groups in MoReq2010 are not necessarily hierarchical – for example, all users who sign in through Google could constitute a particular group
There is no system metadata kept by MoReq2010 about which groups are parent groups and which are child groups – this information could be added as contextual metadata if required
Users and groups are entities like classes, aggregations and records – they have a system identifier (UUID) and a title and description, plus other necessary system metadata plus an event history and they are either active or destroyed (residual)
Users and groups are managed as entities in the same way as other entity types
For example, if a user entity is created but the user never accesses the records system then that user entity can be deleted – however, once the user has performed functions in the records system then the user entity can never be deleted – only destroyed leaving a residual entity
This is the same with groups – for example, if the organisation’s textile department was dissolved and integrated into its manufacturing department, there should remain a residual textile group in the MCRS to show that the textile department once existed

From the postbag

Jens Hübel from OpenText asked two questions via email which were answered during the postbag session of this podcast (a third question from Jens will be addressed in the next podcast). The text of these questions was not read out in full during the podcast - so the full text of the questions and notes on the responses are listed below:

“1. User Group Service in my opinion is one area where the modularisation model of MoReq2010 makes a lot of sense to me. Many organisations already have a corporate directory and avoiding all the duplication of user related information really would be beneficial. Let’s say I have a corporate directory (CD) and two MoReq compliant systems A and B. Let us assume CD implements the User Group Service and is administered in a way to fulfil its requirements. Now system A wants to export records and system B imports them. Is it then a valid scenario if the exported XML of A just references the user ids (which are unique)? B could just import those and CD is always the instance resolving them to provide information like user names or group members. I couldn’t find any scenario like this described in detail. The XML examples even that they are not “exported in full” always contain the users and group information. Keep in mind that a large organisation may have 10.000s of users and groups which I do not want to be part of every export.”

MoReq2010 provides an export that will contain all of the information about a set of entities – it exports and imports in full
There is no assumption made by the export process that some of the information exported may be shared with other records systems
The future import module for MoReq2010 will allow for the mapping of entities as they are imported – in case they are already known about by the importing records system (for example, they may have been imported previously)
The importing system will have a level of configurable control over the process
Export in MoReq2010 is defined fairly simply, while import is more complex with a range of different possible use cases, but also gives more options
MoReq2010 allows entities that have been previously imported to be matched up this is because all entities have a Universally Unique Identifier (UUID)
The system of entity identifiers used is not unique within a given instance of MoReq2010 but is unique universally across the world
MoReq2010 insists on the form of identification used by entities in an MCRS to ensure this
Back to Jens question – all users and groups that are imported will not necessarily be recreated
Two MCRS solutions may also use the same user and group service – and know that they are both using exactly the same user and group service
Finally, there is some control over export in that the user exporting the entities can choose which entities to export
For example, if the user and group service is exported then all users and groups will be exported in full
Otherwise, for example, if only entities in the record service are exported then related users and groups will be exported as placeholders, rather than being exported in full
A placeholder is a small amount of information not all of the information about an entity
On import placeholders may be matched to entities that have previously been exported in full
MoReq2010 does not allow partial entities to be exported – they must be either exported in full or as placeholders

“2. Corporate directories are widely configurable and probably can be administered in a way that fulfill many of the compliance requirements (forbid a full deletion, deactivate instead of destroy). While am sure that you also can add custom metadata to many of them things will become tricky, if those require a specific semantic. For example look at the FirstUsed property. I assume many existing system do not have such a property and having it automatically set if the user id is somewhere used in an ACL s usually is not in scope of the directory but of the business application. These little details make it hard to bring the ideas of MoReq2010 to reality. Is there really such a strong need on such a property? Wouldn’t a much more common property active/inactive be sufficient for 90% of the use cases and allow to reuse existing systems instead of implementing a new service that does 90% what Active Directory can do today?”

The first used property (see M14.4.32 First Used Timestamp) distinguishes between those entities that can be freely deleted and those which must be destroyed and where the records system must retain a residual entity
Jens question asks, is it an effective substitute for the first used property simply to configure the corporate directory not to delete anything at all?
The first issue is that the corporate directory may contain many users and groups that are not used by the record service – if the corporate directory as a whole is exported then the export may contain many entities that are not relevant to the records system or the records management context
For this reason, MoReq2010 describes a potential user and group service as a “wrapper” around a corporate directory service that keeps some additional information, such as the UUID of the entity and the first used property
The wrapper service may simply store these values as custom metadata within the directory service

There are some functional requirements for users and groups that are necessary but may require some effort to implement successfully, these are:

R3.4.7 The MCRS must be able to generate a report for an authorised user listing the active groups that a nominated user entity belonged to at a specified historical date and time.

This is difficult to achieve in a business system – to trace retrospectively what groups a user belonged to at a particular point in time
But it is vital to trace why things may have happened in the records system the way they did

R3.4.13 The MCRS must be able to generate a report for an authorised user listing the users that were active and belonged to a nominated group at a specified historical date and time.

This is the corollary function that allows group membership to be traced
These requirements will be hard for suppliers to implement in their products
But these functions are needed by organisations – especially whenever there is an enquiry into a particular incident
A few functions like these can be found throughout MoReq2010 but they are important and necessary for proper records management
This is mitigated by making these requirements generate reports rather than mandating instant responses and by allowing the reports to be generated from the event history if required
A records system must have sufficient functionality to perform as a records system – even a minimal system as specified by MoReq2010

Thanks Jens for your questions, we will try to let everyone know about the next podcast on Twitter @MusingOverMoReq so that we can receive postbag questions like Jens ahead of time.