Home

Overview for Customers

If you are intending to use the Pathfinder SSO service in order to provide authentication for your application, the User Guide is for you. You are on the first page.

Why Pathfinder SSO?

The Pathfinder SSO service (also known as "KeyCloak" or "RedHat SSO"). Provides a simple way for application development teams to set up login functionality for their app from approved identity providers over a standard, secure protocol.

An "Identity Provider" is the holder of the identity that is used to log in with. The Pathfinder SSO service is NOT an identity provider. When a user of your application logs in, they will not be providing credentials to your application directly, or even to the Pathfinder SSO service. They will be logging in directly with the identity provider. That login event is then propagated back to your application in the form of a token that proves that they have logged in correctly.

It is totally possible for your application to integrate with any or all of the identity providers directly instead of using the Pathfinder SSO service. The benefits of using Pathfinder SSO are:

• Easy setup. We've made this the #1 feature of this service. You can get your DEV, TEST, and PROD instances running against most of the available identity providers right away. The Pathfinder SSO service already has integrations to the following identity providers:

  • IDIR (BC Common Logon Page)
  • BCeID Basic (BC Common Logon Page) -- Allows login only with BCeID Basic
  • BCeID Business (BC Common Logon Page) -- Allows login only with BCeID Business
  • BCeID Basic & Business(BC Common Logon Page) -- Allows login with BCeID Basic or BCeID Business
  • GitHub only in DEV and TEST environments at this time

• OIDC protocol. Where certain identity providers (BCeID in particular) support SAML protocol when used directly, Pathfinder SSO brokers the SAML connection and lets you use OIDC instead. OIDC is more common and simpler to set up in modern programming stacks.

• Session Management. Some identity providers don't offer advanced session management capabilities.

Why NOT Pathfinder SSO?

It is technically possible to integrate directly with the various identity providers instead of using OCP-SSO. Architectural reasons for direct integration include:

• High Availability Requirements. The Pathfinder SSO service has no formal published service level agreements (see BC Government SSO Service Definition). Although there is a dedicated operations team monitoring, patching, and troubleshooting the service, they take weekends off and have not engineered for 99.999% uptime. If you have a mission-critical application, think seriously about whether this service fits into your architecture.
• High Volume Expectations. The service is shared by many dozens of applications. If one application starts sending millions of login requests, the service itself can experience service degradation which is felt by all the users of all the applications. Pathfinder SSO is managed on the OpenShift Platform and scales fluidly, but there are limits to the resources it can consume.
• Unique Configuration Needs. New customers no longer receive a dedicated realm where they can experiment and invent on top of the platform (see "What's Changed" below).
• BC Services Card Integration Requirements. Because of the high-security nature of the BC Services Card identity and the private information that is available in the context of a login, BCSC is not allowed to be shared between applications. In a dedicated realm the BCSC integration, once approved and configured by IDIM, can be set up. Since we are not offering dedicated realms at this time, teams that need to integrate with BCSC will need to find another solution (see BC Services Card Integration for useful advice).

What's Changed?

As of 2021, the Pathfinder SSO service has changed it's service offering. Existing customers will not be affected, but new customers will experience a different service offering.

• Previously, customers were provisioned their very own KeyCloak realm. A realm is like a security zone that is protected from the configuration changes made by other realms. Each team worked in their own realm and was given access to the KeyCloak administration console for their realm where they could make any changes they wanted to.
• In 2020, the OCP-SSO service started to hit maximum capacity for realms in a way that was not possible to mitigate via the usual vertical and horizontal scaling approaches. The KeyCloak product was not designed to handle an unlimited number of realms and we managed to find the limit (unfortunately!).
• Until such time as we have another production instance of KeyCloak that can start adding new realms, new customers will now be added to one of the specially configured standard realms. Instead of receiving an entire realm per team, they will receive a pre-configured client inside an existing realm. There is no compromise to the security in this configuration, but it does mean that teams will no longer receive credentials to log on to the KeyCloak server and make changes to their configuration. Changes will be made by the operations team in response to requests for now (we're working on automations to solve this problem). Although this is a compromise in terms of the flexibility of the service, it actually makes setting up simpler and faster for teams.
• New customers get an easy-to-set-up authentication component. What about authorization? KeyCloak includes features that allow administrators to define roles and groups and assign users to these roles and groups. When a user logs in, their authorization context(s) come through to the application in the form of claims inside their token. The application can check the user's role and/or group membership and execute authorization-aware application logic based on the values. This feature is used by many of the existing applications supported by Pathfinder SSO (but not all of them). Because using this feature requires access to the KeyCloak administration console (or at least API) in order to administrate, it is not available to new customers that do not have their own realm (it would be a potential security breach to allow realm management in a realm shared by many applications). If you need an architectural solution for authorization, see Handling Authorization for useful advice. We are working on providing authorization capabilities to customers in the standard realm, but at this time any authorization features must be handled by means of a request to the operations team.
• We have removed GitHub as an IDP in the production versions of the standard realms. The IDP is still available in dedicated realms and may return to the standard realms pending security review. GitHub is still available as an IDP in the DEV and TEST versions of the service, for teams that find that useful during development cycles.