Metadata and content are the essential and central focus for all information professionals, archivists and librarians. When implementing a new system or migrating from an old information management system it is especially important to get data structures and metadata consistent and correctly formed and presented.
Amidst the many tasks in a project plan to implement a new system, the transfer of “user” metadata, however, is often regarded as just another item on the list and one that can be left to technical staff.
User data, however, is the key to the door of marketing the service. When properly considered and applied the loading of and treatment of user data can be a major benefit in the pursuit of increased use of content and a better user experience.
There are a range of different approaches that can be taken, from simply loading a user file of names to setting up integration with a Directory Service or Membership System and layering user profiling and implementing My Account functionality.
Authenticating a user is often referred to as Single Sign On (SSO), when the person points to a URL in their web browser and automatically connects to the library or archive service without having to enter a user name or password. There are three key benefits:
The terminology used is full of acronyms and for the non-technical person may be confusing. The acronyms used and the different concepts applied to the set-up of users are often not understood. Much depends on whether the system being implemented is installed on in house servers (referred to as being “behind the firewall” or is to be implemented in a Data Centre external to the organisation or in the Cloud.
The most common terms and abbreviations used are:
DS – Directory Service
SSO – Single Sign On
ADFS – Active Directory Federation Services
SAML – Security Assertion Mark-up Language
AD – Active Directory
Active Directory (AD) was developed by Microsoft for Windows to manage a network of devices and users. It is included as part of the Windows Server operating system as a set of processes and services.
Initially, Active Directory was only in charge of centralised management of the network and was applied when the servers on which applications are installed were within the organisation (not in the Cloud) and managed by the internal IT Department. It was used to help organise a company’s users, computers and more, hence the use of the word Directory.
The internal IT Administrator uses AD to organise a company’s complete hierarchy from which computers belong and on which network, it can include what every user’s profile picture looks like and which users have access to file storage facilities on the network. Typically, most organisations using Windows on the desktop will have Windows Servers and an Active Directory service that holds details of all users in the organisation and the permissions to allow access to the corporate network.
Where there is a reference to LDAP (Lightweight Directory Access Protocol) this is an application protocol for querying and modifying items in Active Directory (AD). AD is a directory services database, and LDAP is one of the protocols used to talk to it.
If your library or archive system is implemented in-house you will need to have Active Directory integration applied for users to be able to take advantage of Single Sign On.
AD worked well until it became more common to implement application systems in the Cloud or external Data Centres where the servers on which the application is installed are external to the organisation and not part of the internal IT computer network. At this point, it was not advisable to use Active Directory, since connecting to it directly would compromise the security of the internal network.
Active Directory Federation Services (ADFS) was created to allow authentication by services that sit outside the corporate domain (the internal company network) such that a user who is outside the company using an application that is not inside the corporate domain network, can connect, be authenticated and logged in automatically. ADFS acts as a bridge between the internal AD and external service users are authenticating with. The principal behind ADFS is using a trusted token to maintain application security and implement federated identity. Claims-based authentication is the process of authenticating a user based on a set of claims about its identity contained in a trusted token. This too is a Microsoft developed product and is used with Windows Servers.
Instead of ADFS some organisations have chosen to introduce third party authentication solutions to allow applications that are hosted on Cloud Servers to authenticate users.
ADFS is the ideal choice if all of your users are internal to the organisation and have accounts setup in AD.
Security Assertion Mark-up Language (SAML) has become the standard protocol for web browser Single Sign-On (SSO) using secure tokens. It uses cryptography and digital signatures to pass a secure sign-in token from an “identity provider” (a third party used to manage secure tokens and to simplify implementing SAML services) to an application hosted in the Cloud “service provider”.
This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:
Most organisations already know the identity of users because they are logged in to their Active Directory domain or intranet. It makes sense to use this information to log users in to other applications, such as web-based applications, and one of the more elegant ways of doing this is by using SAML. Essentially SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.
There are a number of Identity Providers now available to provide SSO and SAML services, including OneLogin and Okta. The diagram below is from OneLogin to explain the way SAML works.
SAML takes ADFS a step further as it allows the authentication of users who exist in a third-party authentication service such as OneLogin or Okta not just those who exist in a local AD.
OpenID Connect is fast becoming a popular option for membership based systems. It is an open standard which builds on OAuth which only supports authorisation (not authentication) but adds an authentication layer. It’s the same standard used by popular sites such as Facebook, Google and Paypal. With OpenID Connect the “OpenID provider” (a third party used to manage keys and verify the user’s identity) generates a key and association to an application hosted in the Cloud “relay party”.
The choice of mechanism to achieve SSO or authorisation will largely be dictated by IT policies within the organisation, taking account of the technology platforms and services and expertise within the firm or organisation.
What is achieved, whenever a login tool is applied that removes the need for the end user to have to remember user names and passwords, is a greater level of acceptance and eagerness to use the application and content. By removing a barrier to access, the end user will be more likely to visit and enter into engagement with the library or archive service, whenever there is a possible need to consult or request content.
For this reason alone, it is a worthwhile endeavour and one that should be a priority when implementing a library or archive system.
The benefits go beyond simply improving the speed and ease of logging in. The library and archive service now have more details about when the end user is connecting to the service, how often, at what time of day, for what period of time and if the IP address is tracked, from where. All useful metrics in determining what use is being made of the service.
From the end users’ point of view, they become known to the service and do not have to enter details about email address etc when placing requests for service. The end user can immediately see content that is made more relevant perhaps because of the fact the individual is a member of a particular department or function or part of the organisation or is a member of a particular group of users that the service has identified. This in addition to be able to see past search history, status of loans, requests and other relevant transaction data that the service can provide.
This too helps to cement a relationship with the end user and allow the end user to perform more tasks in the system than might otherwise be the case, when the user is not logged in. It may also mean that the variety of content can be more carefully presented in a Search Portal customised to the needs of a particular type of user.
There is more to discuss on the topic of user data. We will follow up this article with others during the year to introduce concepts that can add value to the library in terms of improving services to end users and controlling data that is held in respect of an individual user, how GDPR can be managed and the benefits of a User Centric approach to delivering information services.
Soutron software is designed to work with Directory Services such as those managed via established protocols such as SAML, AD and ADFS mentioned above. In addition we can build custom connections with in house systems or third party membership services to authenticate and provide a means to keep a user file updated.
> Soutron Library Management
> Soutron Records Management
> Soutron Archive
> Soutron Business Archive
1989 – 2024 © Soutron Global Inc – All Rights Reserved | Terms & Privacy | Sitemap
