Identity and Access Management: Key Technology for User Portals

Corporate user portals need a number of important technological factors to be successful. Successful means that they are accepted by customers and that an active and loyal community forms there, which shares content, grows and increases the company’s sales in the long term. Customers will only do this if they can assume that their data is secure and if it is made easy for them to log into the user portal and connected channels. The operating organization, in turn, must not only ensure the security of its customers, but also protect its own systems externally.  

I would like to introduce a key technology that is crucial for this: Identity and Access Management (IAM). IAM occupies a central position in the technical infrastructure of user portals; however, there are several other building blocks that are not considered here. Setting up a user portal and securing it internally and externally are complex and anything but trivial.  

To operate a user portal professionally, you need an IAM system. IAM includes all internal policies and tools that IT departments use to grant access rights to various applications and systems and to manage digital entities. Such identities can be either natural persons or technical identities (software, IoT hardware). IAM systems thus represent an important element of cybersecurity by providing secure access to corporate resources.

The first main task of an IAM system is to authenticate entities whenever a user requests access. In the simplest case, the username and password are checked against the company’s own database. Meanwhile, multifactor authentication and adaptive authentication are used due to security concerns.  

The second main IAM task is the authorization of the authenticated entity. The entity’s access rights are verified and depending on the assigned role, it is granted access to the appropriate resource level.

Another key function of IAM systems is managing user identities, i.e. creating, editing and deleting users. For this purpose, the systems can be synchronized with directories such as Microsoft Active Directory. Users are assigned one or more roles according to previously created IAM policies, with which certain rights are associated.

Single sign-on is not just another IAM feature, but a complete key technology principle. The most powerful IAM systems offer it as well, but in my eyes it deserves to be considered separately.

With Single Sign-On (SSO), your end users only need to authenticate once in your User Portal or on another authorized instance, such as Gmail or Facebook. As soon as this external instance reports a successful login back to the user portal, the user is logged in to all connected systems such as social media channels. This significantly facilitates customer engagement and improves the customer experience.    

Entering the password once saves time and delivers additional security, as the customer only needs to remember one password and only one password needs to be transmitted. Since users only need to authenticate at a single point, it can be better secured and verified for correctness (URL, SSL server certificate). 

SSO is initially a higher-level technical principle. There are different solution approaches for SSO. In the media solution, the user uses an electronic token (USB, Bluetooth) to be authenticated. In the local solution, users install a client on their regularly used workstation that automatically fills in logon masks with user name and password. When using a ticketing system for SSO, a network of trusted services is established. The user is assigned a ticket as a “trusted user” when logging in to one of these services, which logs him/her in for all other services in the network. Finally, in the portal solution, the user logs into a portal and is authenticated and blanket authorized for each application integrated within the portal. In the case of web-based services, for example, this can be done using HTTP cookies or a dencentral protocol such as OpenID.

OpenID is a decentralized authentication system for web-based services. A user who has registered once with an OpenID provider receives a URL-based identity, the OpenID. This allows him to log in to all websites that support OpenID. Since OpenID is decentralized and available exclusively as open source software, anyone can become an OpenID provider and operate an OpenID server with relatively little effort. This has led to the widespread adoption of OpenID, with small and medium-sized providers contributing as much as big tech.

This global spread and popularity of OpenID is its greatest asset, but the technology behind it is vulnerable to phishing attacks. As a result, it is increasingly being supplanted by OAuth and OpenID Connect, which offer more security configuration options.   

In IT, a “realm” refers to the totality of all entries in a directory or the directory itself within a directory service such as Active Directory. This can be all human users and technical entities using the IT system of a company, or the members of a user portal. When such directory services are used as a ticketing system for SSO, the realm tells the application which instance of a directory service to authenticate against. It shows it where the requested user account is located for which an SSO ticket should be requested.

A distributed SSO authentication service for open computer networks such as the Internet that uses tickets and realms is Kerberos. Developed at MIT in 1978, Kerberos can be used for secure authentication on TCP/IP networks. Passwords no longer need to be transmitted over the network and are replaced by tickets. A Kerberos server only manages accounts that belong to its realm; a computer can only belong to one realm at a time. In order to access services in other realms via Kerberos, trust positions must be established between the individual realms. Kerberos has been Microsoft’s standard protocol for SSO authentication since Windows Server version 2000/2003 and client version Windows 2000/XP. The Kerberos keys are stored in Active Directory. There are already Kerberos implementations for other operating systems such as macOS, Linux and FreeBSD.   

As soon as your user portal grows, it becomes too time-consuming, confusing and therefore error-prone to give each real user direct rights and access to different systems. For multi-user systems such as user portals, it makes sense to assign user roles, where rights are abstracted based on work processes.

Role Based Access Control (RBAC) is considered to be the best practice for role-based management of user rights and for controlling access to files or services. RBAC was described by Ferraiolo and Kuhn in 1992, adopted as an ANSI standard in 2004, and is in use on Microsoft Active Directory and SQL Server, SELInux, FreeBSD, Solaris, Oracle RDBMS, SAP R/3, and many other systems. 

First, one or more roles are assigned to each user. One or more group memberships are attached to each role. Roles and group memberships determine the access rights of a user. Read, write and execute are the most common rights controlled via RBAC. Fortunately for the operators of user portals and online communities, it does not stop there. Rights such as administer, curate, share or create members are extended beyond the “normal” members of a community to include moderators, administrators, community managers and other users of the user portal.  

They really do exist: free and yet powerful IAM systems. I would like to briefly introduce one of them to you, because we have had good experiences with it at yawave:  Keycloak. Keycloak currently runs on Apache License 2.0 and supports three security protocols: OpenID Connect, OAuth 2.0 and SAML 2.0. It supports not only single sign-on, but also single sign-out and provides the user with a comfortable, web-based GUI as an admin console. Keycloak can be used as a standalone IAM system because it allows you to create user databases with user-defined roles and groups. This information can be further used to authenticate users within your application and secure parts of them based on predefined roles. Keycloak allows synchronization with your user database. By default, LDAP and Active Directory are supported, but you can create custom extensions for any user database using the Keycloak User Storage API. Additionally, Keycloak allows you to use social identity providers. It provides out-of-the-box support for Google, Twitter, Facebook and Stack Overflow, but you have to configure them all manually through the admin panel. Keycloak lets you customize all the pages that are displayed to your users. The pages are set up in .ftl format, so you can use classic HTML markups and CSS styles to customize them to your brand and UX design. You can even insert custom JS scripts. Plus, there’s a large and helpful support community.

On the downside, opting for Keycloak could be a disadvantage if you’re only running a single application with only one client in the Keycloak realm – then you lose all the benefits of SSO. If you don’t use social login or allow it for your user portal, Keycloak might not be the right choice either. Using Keycloak as a pure user database is also not suitable, you can better use a database with specific tables, which is easier to configure. Last, not least Keycloak is an open source project. If you are looking for a manufacturer warranty or individual 24h support, you are wrong.

Without selecting and using the appropriate key technologies and processes such as IAM and RBAC, your user portal will not be successful in the long term. I would be pleased if this article could provide you with a few pointers on what you should pay attention to.