Increase web app security with Spring Security, Keycloak and other safeguards
Web app security has never been as critical to revenue as it is today. Entire industries have been sucked into the digitalisation maelstrom. And many software providers can no longer avoid the SaaS model for their platforms. To ensure that services on the internet are secure and GDPR-compliant in Europe, it is helpful to take a look at the risks in order to be able to initiate appropriate preventive measures.
The non-profit organisation “Open Web Application Security Project” (OWASP) publishes its Top 10Â web application security risks each year. It includes risks directly related to web app identity and access management. It is an integral part of overall web app security. After all, no one can afford to make mistakes in this area nowadays. User security is paramount. If you make a mistake here, you risk irreparable damage to your image that may be impossible to repair. These incidents can be extremely expensive and, often, the whole business may depend on it.
Inadequate access control is the biggest danger
In 2021, OWASP cited “Broken Access Control” as the biggest threat to web apps. That alone should be enough to show how important clean user authentication is. One recommendation here is to use the OAuth Standard (OAuth 2.0). For Java-based web apps, it can be implemented with the Spring Security Framework. This makes it possible to separate simple access control to an application from authorisation provided by the application itself. This task is then taken over by an “Authorisation Server”, which informs the application (client) of the authorisation of a user or another entity and, so to speak, enables the authorisation for access. The application trusts the authorising entity and then grants access itself.
Spring Security is not a 360° solution for web app access managementÂ
Spring Security is not nearly enough to guarantee user security on web apps. Why not? Because a separate implementation is necessary for each connected application. This costs a lot of time and requires the utmost concentration for each individual integration, which can only be done with in-house programming.
The whole thing is already available out-of-the-box with Keycloak. This means that you do not have to go through the trouble of implementing it for each additional connected application, nor do you have to implement it at all via programming.
Keycloak offers OAuth 2.0 out-of-the-box
If you already have Spring Security implemented for your Java application, it is easy to add the multi-functionality and the resulting comfort with Keycloak via the Keycloak Adapter provided. In the medium term, however, Keycloak will discontinue Java adaptor support. It is therefore recommended to use both together now and not in stages. For this reason, the Keycloak community recommends the use of Spring Security.
You can look into more information about securing web apps with Spring Security 5 and Keycloak. Spring Security is continuously evolving and, as from November 2022, if offers the possibility to set up a private server for authentication. You can read more about it here.
With regard to this function, it remains to be seen whether this could become an alternative to Keycloak. After all, the open-source software comes with a lot of features out-of-the-box, so it will be difficult for alternative providers to keep up. For example, Keycloak’s own admin console is a very strong advantage, which is why many continue to rely on Keycloak.
Keycloak, like Spring Security, cannot provide all-round security for user identities.
In principle, however, neither Spring Security nor Keycloak itself can separate unlawful access from unauthorised access. And exactly this became a worldwide problem in December 2020. Two weeks before Christmas, SolarWinds’ security platform Orion was compromised, as discovered by the IT security firm FireEye, who was also affected by the hack.
The attackers obtained the single sign-on key and proceeded to move through the hierarchy, using the corresponding admin rights in the SolarWinds platform. There, they installed the so-called Sunburst Trojan, which was delivered to all Orion customers with an update. An overview of this landmark coup can be read on techtarget.
The installation of a trojan is no longer possible with the separation of login and access.
This would not have happened if SolarWind had separated login from the authorisation of access rights in their system. This is made possible by implementing the authorisation framework SecuRole®, which ensures end-to-end security. This creates an additional security layer that checks and approves access rights independently of the login. It does this by relying on a further checking instance that is not affected if the SSO key is stolen. Hackers would have the possibility to gain access in some way if they got hold of the credentials, but they can only move laterally, i.e. on the level of a simple registered user without real rights in the system. Thus, they would not have the chance to act like an administrator and install a trojan.
You can find out more about end-to-end security for internet identities in the free webinar with our partner KuppingerCole: The evolution of access control
Conclusion: The interaction of Spring Security, Keycloak and extensions constitutes comprehensive user protection.
We maintain that not one of the aforementioned add-ons represents comprehensive IAM-related security for web apps. Instead, a combination of all these components makes the most sense and only together can they offer a real increase in protection for web applications.
Overview of the differences: Spring Security, Keycloak and Login-Master
The following table provides an overview of the points raised. It also shows the wider differences between Spring Security, Keycloak and a comprehensive IAM solution for web apps and services:
| Function | Login-Master | Keycloak (out-of-the-box) | Spring Security |
|---|---|---|---|
| User authentication (authentication, identification) | See Keycloak | Yes | Yes, self-programmed, for each individual app |
| Token-based authorisation (separation of login-functionalities from concrete access approval) | Yes, with the Keycloak extension SecuRole® | Yes, with limitations | No: If an app tries to refer back to a users group, it will be saved in a local user registry. This is problematic for cloud-based apps. |
| GDPR-conform handling of user data | Yes | Yes, but only partially | Yes, with major limitations, because each app collects its own data, which makes it independently responsible for GDPR conformity. |
| Central storage of user information and credentials | See Keycloak | Yes | No, each individual application becomes a data silo |
| Central IMS with: 1) Role management: - via role shop - via ABAC (attribute based access control, e.g. organisational unit, position, etc..) - via central admin - via delegated admins 2) Audit 3) Automatic processes 4) Import from authoritative data sources 5) Online definition of applications and roles 6) Re-certification | Yes | Only partially or manually via central admin via a few dialogues | No |
| Securing of non-Java-based applications | Yes | Yes | No |