Qpercom’s strategy is driven both internally and by our valued clients. We constantly add new features to our application suite as we endeavour to update our application technologies and keep pace with our client needs. In parallel, we also aim to improve the infrastructure on which our applications run. This relates to what are often called non-functional requirements, such as:
- User security
- User management
- Single sign on
- Single sign off
Requirements such as these can be fulfilled on an ad hoc basis in handcrafted code in each of the Qpercom applications. An alternative approach is to follow what might be called the path to enterprise-grade infrastructure. In the latter, we use integration of some strategic open source software, which, in this case is Keycloak.
Introducing Keycloak Authentication
Keycloak is an open source software product which facilitates single sign on/off with identity management, access management and authorization. Keycloak is currently under the stewardship of Red Hat and it has a wide range of features, many of which work out of the box. Rather than just talking about Keycloak, it’s nicer to see it in action.
An example of a Keycloak-protected application landing page is illustrated in Figure 1, where we have a fictional library application with two protected options (marked in blue):
- Browse books
- Manage Library
Figure 1: A protected application
The option to browse books is allowed for all logged-in library users. However, the option to manage the library book inventory is allowed only for privileged library users, i.e., the librarian. Access to each of the two options in Figure 1 is in fact managed by Keycloak and not the application. So, what happens when a user selects one of these two options? Good question. On selecting either option, the user is seamlessly redirected to log into the identity provider Keycloak, as illustrated in Figure 2.
Figure 2: Redirection to Keycloak
Figure 2 is the generic out-of-the-box Keycloak look and feel. I note in passing that the theme used to generate the user interface element in Figure 2 can be customized if required to match Qpercom’s branding. So, once Keycloak is deployed to production, the login screen may look somewhat different from that of Figure 2. But it’s still just a user login challenge.
Once the login is completed in Figure 2, the user is returned back to the original application. At this point, the user has been authenticated and is free to use the application features. Notice that the entire user authentication mechanism is handled by Keycloak rather than by the application. In a sense, the application has ‘outsourced’ the login procedure. No need for any handcrafted, brittle authentication mechanism inside the application. Instead, we have an industry-standard mechanism as provided by a product supported by a community of open source developers and managed by a multi-billion dollar corporation.
In order to achieve this authentication outsourcing mechanism, the user details have to be entered into Keycloak and this can be done in a number of ways. For example, using the Keycloak administrative console, as illustrated in Figure 3.
Figure 3: The Keycloak adminstrative console
In Figure 3, we see some of the major functional elements of Keycloak, namely:
- Realms – a University or Volume recruiter, e.g., NUI Galway, or Health Education England (NHS/HEE)
- Clients – an application which is itself a ‘client’ of Keycloak, e.g., Observe, Recruit, Choice, Entrust and Analyse
- Roles – a generic user type, such as, Examiner, Student, and so on
- Groups – a generic group, e.g., a class of students
- Users – a specific human login user, e.g., a student user, an examiner, and so on
While Figure 3 contains a lot of detail, the above are the principal items required for the implementation of authentication and authorization and they are now briefly described.
Realms, Clients, Roles, Groups, Users
One way to think about a Realm is as an organizational container. In other words, a realm models a site such as a university. So, it makes sense to think of NUI Galway or UCD as realms. Inside a given realm, we have Clients, i.e., Qpercom applications (Observe, Recruit, Choice, Entrust and Analyse. This might be slightly confusing at first because the applications are the ‘clients of Keycloak’ and are subject to decisions related to:
- Redirection (as we saw in Figure 1)
- Authentication (as we saw in Figure 2)
- Authorization
Role is a key concept to understand and is used to model a user category, such as, an examiner or student, applicant. The fact that Keycloak supports roles is a reflection of its implementation of what is called role based access control or RBAC. RBAC (https://en.wikipedia.org/wiki/Role-based_access_control) is a powerful and scalable approach to handling access control and authorization.
Groups allows for an added element of modelling by placing entities in arbitrary groupings. Users represent the individual user entities in the Qpercom applications, i.e., student users, examiners, etc.
The Keycloak REST API
There is also a Keycloak REST API that can achieve much the same thing as the Keycloak administratvie console. The important point is that there is a requirement on the administrator to create some Keycloak specific data.
The same type of authentication described above (for login) can also be provided for dynamically generated lists in the applications. For example, let’s say that we have a list of exams but our currently logged-in examiner has access to just a subset of the list. Can we apply the same type of protection using Keycloak? The answer is yes we can and this takes us into the allied area of authorization.
Identity Management, Authentication, and Authorization
Identity management and authentication typically relate to the area of allowing users to log into a given application or system. Authorization relates to the management of permissions to use specific features inside the application. Keycloak provides a range of authorization features. Figure 4 illustrates the basic idea where the Qpercom Observe, Recruit or Analyse application uses Keycloak to enforce a user policy.
Figure 4: Policy management in Keycloak
Policy enforcement is handled by Keycloak and this also means that the Qpercom application doesn’t have to include any handcrafted policy management. This is a really powerful feature and allows for the definition of policies in Keycloak and the execution of those policies in the application. Just as for authentication, the enforcement decisions are the responsibility of Keycloak. Again, this outsourcing arrangement frees up the application developers to focus on providing end user value in the form of new features. Any advances made in Keycloak also become available to the Qpercom application suite in the form of a software upgrade (of Keycloak).
User Creation
Figure 5 illustrates the user creation screen in the Keycloak administrative console.
Figure 5: User creation
In Figure 5, we are creating a new user called, Barney. The only mandatory field in the user creation procedure is the Username, which must be unique. And that’s it. Obviously, there is a use case for legacy Observe user data to be migrated into Keycloak. This is a little beyond the scope of this blog post, but it essentially consists of some mechanism of exporting the Observer users and then pushing a transformed version of that data into the Keycloak REST API.
Single Sign On/Off (SSO)
One of the many powerful features of Keycloak is single sign on. Internally, Keycloak supports two schemes out-of-the-box, namely: OpenID Connect version 1.0 and SAMLversion 2.0. Other schemes can be added if required.
As these are token-based schemes, once the logged-in user has a token, the token can be used in conjunction with Keycloak on multiple applications. It is expected that existing Qpercom customers will be interested in using this Keycloak feature as part of their onsite SSO facilities.
If you would like more information you can reach us here.
