Integrating Connect with Your Authentication System
By the end of this lesson, you will be able to:
- Explain the benefits of centralizing authentication with an identity provider
- Distinguish authentication from authorization in the context of Connect
- Describe the user roles Connect supports and how group membership maps to them
- Recognize how to protect sensitive values in the configuration file
Introduction
Up until now, Connect has managed authentication itself, relying on user names and passwords. In a production deployment, you will want to integrate Connect with the authentication system your organization already uses. Users then authenticate with their existing credentials instead of a separate Connect password, following industry-standard authentication flows.
Connect can integrate with many types of enterprise authentication systems. In this training we use OpenID Connect (OIDC), a single sign-on protocol that centralizes user authentication across your organization’s applications. While OIDC extends the OAuth 2.0 protocol with identity information, in practice the terms OAuth and OIDC are often used interchangeably. If your infrastructure uses a different type of authentication system, refer to the Admin Guide for the exact steps you will need to take.
To integrate an identity provider (IdP) with Connect, there are two things you need to configure: the authentication settings, which allow Connect and the IdP to share information about the identity of the user logging in, and the authorization settings, which determine the role, and therefore the permission level, each user assumes in Connect.
- Reading time: 15 minutes
- Documentation reading time: 25-45 minutes
- Hands-on exercise time: 15-30 minutes
User Roles and Group Mapping
To facilitate user management, Connect can automatically assign user roles based on the group information included in the OIDC claim. You enable this with UserRoleGroupMapping = true in the [Authorization] section, and then map groups to roles, for example with AdministratorRoleMapping and PublisherRoleMapping.
Groups that are not listed in the configuration file are given the default role, Viewer by default. The Authorization.DefaultUserRole setting controls the role unlisted groups receive. This means you only need to list the groups whose role differs from the default.
Before configuring the mapping, it is important to have a good understanding of the roles users can have in Connect, and of which groups in your identity provider should hold which role. The accompanying lab has you work this out for a realistic set of users and groups.
Just-in-Time Provisioning
By default, Connect is configured to create users on first login, which is called “just in time provisioning”. Even though the identity provider knows about many users, they do not exist in Connect until they log in for the first time. This keeps user management simple: you manage people in your IdP, and Connect mirrors them as they start using the system.
Protecting Secrets in the Configuration File
Some parameters in your Connect configuration file are sensitive, such as the client secret needed for the authentication flow with OIDC. These parameters can be encrypted using a command-line utility installed with Connect called rscadmin. The encryption process uses a key that is, by default, generated and managed by your Connect installation; the Admin Guide has more information about this encryption key and how you can manage it.
Centralizing authentication pays off well beyond the login page:
- Single sign-on: users authenticate with their existing credentials across all your organization’s applications, including Connect.
- Centralized offboarding: when someone leaves the organization, disabling their account in the identity provider revokes their access everywhere, including Connect.
- Consistent role management: mapping groups to Connect roles ties permissions to the groups your organization already maintains.
As you plan your own installation, identify where you will get the information you need to integrate your authentication system with Connect, such as the issuer URL, client ID, and client secret for OIDC, and decide how you will determine the Connect roles users should have in your organization.
In the accompanying lab, you will configure Connect to authenticate against an OIDC identity provider, map groups to roles, and verify that users get the right role when they log in.