Enabling OpenNMS for SSO with Keycloak and OAuth2 Proxy

In this blog, we’ll go over SSO, the various elements and technologies that go into an SSO process, where Keycloak fits, and how to enable OpenNMS for SSO with Keycloak and OAuth2 Proxy.

Single Sign-On (SSO) is an authentication process that allows users to access multiple applications or systems with a single set of login credentials, typically consisting of a username and password. This simplifies user management and enhances security by centralizing the authentication process. SSO reduces the risk of password fatigue and minimizes the attack surface for phishing and other credential-based attacks, as users maintain fewer passwords and sessions.

SSO operates by establishing trust relationships between an identity provider (IdP) and various service providers (SPs). When a user logs in through the IdP, a secure token is generated and shared with the SPs, granting the user access without requiring additional logins. The token can include additional information like groups the user is a part of.

SSO solutions are commonly implemented using protocols such as SAML (Security Assertion Markup Language), OAuth, and OpenID Connect, which facilitate secure and efficient identity management across diverse platforms and environments. Users commonly run into SSO when they log into Microsoft, Google, or Apple Cloud solutions through a single login.

OAuth is an open standard for access delegation commonly used to grant websites or applications access to user information without exposing the user’s credentials. It works by allowing an end user to authorize a third-party application to access their resources hosted by a service provider, typically without sharing their username and password. Instead, OAuth uses tokens to manage access. When a user initiates an OAuth flow, they are redirected to an authorization server where they can grant permissions. Once approved, the authorization server issues an access token to the third-party application. This token is then used to access the user’s resources within the service provider’s environment.

In the context of SSO, OAuth is employed to streamline the user authentication process across multiple applications. When integrated with SSO, OAuth allows users to authenticate once through a trusted identity provider and then access various third-party applications without having to log in again. This is typically achieved by combining OAuth with another protocol, like OpenID Connect (OIDC), which extends OAuth 2.0 to include authentication capabilities. The identity provider uses OAuth to issue tokens that contain user authentication information, which service providers trust to grant access, thereby facilitating seamless and secure user experiences across multiple services.

OAuth2 Proxy is an open-source reverse proxy and identity provider that provides authentication and authorization for web applications. It acts as an intermediary between users and your backend services, ensuring that only authenticated and authorized users can access protected resources. By leveraging OAuth 2.0, it allows users to log in using third-party identity providers like Google, GitHub, or Microsoft. OAuth 2 Proxy handles the OAuth 2.0 flow, exchanges authorization codes for access tokens, and forwards authenticated requests to the backend, effectively securing your applications.

Keycloak is an open-source identity and access management (IAM) solution that provides features such as SSO, user federation, identity brokering, and social login. In the context of SSO, Keycloak acts as an identity provider (IdP). When a user tries to access a service, Keycloak handles the authentication process. If the user is not already authenticated, Keycloak prompts for credentials and, upon successful authentication, generates an access token. Keycloak can be linked to Oauth via OIDC.

Keycloak simplifies the implementation of SSO by managing authentication, user sessions, and token issuance centrally. It supports integration with various third-party applications through identity brokering, allowing Keycloak to delegate authentication to external identity providers such as social networks or enterprise identity systems.

Keycloak is considered one of the top IAM providers, especially within the open-source community. While it may not have the same market penetration or awareness as some of the larger, more commercial IAM solutions like Okta, Auth0, or Azure Active Directory, it holds a strong position due to its robust feature set and flexibility.

1. Open Source: Being open-source, Keycloak provides transparency, cost-effectiveness, and the ability to customize the platform to fit specific needs. This is an advantage for organizations that require full control over their IAM solution.
2. Comprehensive Feature Set: Keycloak offers a wide range of features, including SSO, social login, user federation, identity brokering, and multi-factor authentication (MFA). It also supports standard protocols such as OAuth 2.0, OpenID Connect, and SAML 2.0.
3. Integration Capabilities: Keycloak can integrate with various third-party applications and services, making it a versatile choice for diverse IT environments. Its identity brokering capabilities allow seamless integration with external identity providers.
4. Community Support: As an open-source project, Keycloak benefits from a large and active community of developers and users who contribute to its development, provide support, and share knowledge.
5. Enterprise Readiness: Keycloak is designed to meet the needs of enterprise environments with scalability, high availability, and strong security features.
6. Flexibility and Customization: Keycloak's architecture allows for extensive customization to match specific organizational requirements, including unique or complex IAM needs.

In the context of Identity and Access Management, authentication and authorization are key processes that secure access to resources. Authentication verifies the identity of a user or system, typically using credentials like usernames, passwords, or biometric data, ensuring the entity is whom it claims to be. Authorization, on the other hand, determines what an authenticated user is allowed to do by evaluating their roles, permissions, and policies.

Authentication answers, "Who are you?" while authorization answers, "What are you allowed to do?", working together to ensure that only authorized users can access and perform actions on protected resources.

Solutions typically used for each:

Authentication Solutions:

• Identity Providers (IdPs): These specialize in authentication and include solutions like Okta, Auth0, Keycloak, and Azure Active Directory (Azure AD).
• Multi-Factor Authentication (MFA) Providers: Solutions like Duo Security, Google Authenticator, and Microsoft Authenticator add an extra layer of security to the authentication process.

Authorization Solutions:

1. Access Management Systems: These systems handle authorization by defining and enforcing policies on who can access what resources. Examples include AWS Identity and Access Management (IAM), Azure Role-Based Access Control (RBAC), and Google Cloud IAM.

• Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC): These models are used to define permissions based on roles (RBAC) or attributes (ABAC), and solutions like Apache Shiro and Spring Security help implement these models.

Many IAM platforms, such as Okta, Auth0, and Keycloak, provide integrated solutions that handle both authentication and authorization, offering a unified approach to managing user identities and access.

This process usually works by the authorization server providing a token to the service provider, in this case, OpenNMS, directing it to grant access to the requested resource. OpenNMS does not natively support Keycloak’s default authorization server, OAuth, so the provided tokens are not useful by themselves. We can leverage the power of OAuth2 Proxy to generate headers based on the content of the token and use those headers with OpenNMS to process authentication and authorization.

That process works for both Authentication and Authorization:

Authentication:

1. Request: OAuth2 Proxy unpacks the token and turns it into a request that gets sent to OpenNMS with the correct headers. One is the username, and the other includes the roles that are assigned to the user. The roles have to match OpenNMS’s roles, most commonly ROLE_ADMIN and ROLE_USER. OpenNMS has to be configured to trust the request and the request must provide specific headers that OpenNMS is expecting.
2. Proxy lockdown: The header approach does present a basic issue in that anybody can send these headers by default. The next step is to lock down OpenNMS to only receive traffic from the proxy so that there's nowhere else that a user could potentially come in from to bypass the proxy.

Authorization:

• Pre-authorization: Users can either be pre-configured within the system, or alternatively, OpenNMS can enable pre-authorization by saying that any user coming in that is pre-authenticated is automatically authorized. If a user comes in through SSO and doesn't exist in OpenNMS and pre-authorization is not enabled, that user will get a login failure. If we turn on pre-authorization, then that user will be given access because they're pre-authorized, meaning we are confirming they should exist, and OpenNMS can just log them in.

The flow for logging in ultimately looks something like the below diagram: 

If you’d like to see it in action, contact us to set up a demo or give it a try yourself!

Next, we will be making this work with Kubernetes with the OpenNMS and Oauth2 Proxy helm charts and explaining how this changes the flow for ingress! Stay tuned!