Organizations with an identity provider that supports OpenID Connect (OIDC) can enable single sign-on (SSO) for PubSub+ Cloud accounts in the PubSub+ Cloud Console and for management access to PubSub+ event brokers.
Console SSO allows users to log in directly to
When Console SSO is enabled, users still need an account in PubSub+ Cloud with an assigned role to access the Cloud Console. If you enable group management for PubSub+ Cloud, you can assign roles to user groups and users can be automatically added to a user group based on claim values received from the identity provider (IdP). For more information, see Configuring User Access.
If you set up Console SSO, you can also set up SSO for management access to your event broker services. For more information, see Configuring Single Sign-On for Event Broker Services.
Authentication Data Flow
The data flow of the PubSub+ Cloud SSO authentication process is shown in the following diagram and described in the steps below:
- The user connects to the Cloud Console.
- PubSub+ Cloud redirects the user login request to the authorization endpoint of the IdP.
- The identity provider presents a login screen to the user. The IdP may use additional methods, such as two-factor authentication to verify the user's identity.
- The user provides the requested credentials to the IdP and logs in successfully.
- The IdP returns an authorization code to the user and redirects the user back to PubSub+ Cloud.
- The user sends the authorization code to PubSub+ Cloud.
- PubSub+ Cloud requests the user's ID token, which includes user claims from the IdP.
- The IdP returns the ID token to PubSub+ Cloud. The ID token contains the user's email claim. If group management is configured the token also includes the Groups claim or other claims set up for claim mapping. If PubSub+ Cloud is configured to request additional scopes, the token may include additional claims values for the requested scope.
- PubSub+ Cloud maps the email claim and any other applicable claims to the user's email address. If group management is enabled, PubSub+ Cloud adds the user to the appropriate user group.
- The user accesses PubSub+ Cloud.
How SSO with OIDC Works
SSO is an authentication process that allows users to log in to one domain and then have access to several independent systems without further action. The user identity is maintained across the independent systems and the user can be assigned roles and permissions according to the individual system settings.
SSO relies on an identity provider (IdP), such as Okta, Auth0, PingIdentity, or Microsoft Entra ID, to create, maintain, and manage identity information and to provide authentication services to the various independent systems. These IdPs use OAuth 2.0 and OIDC for identity management. OAuth is a delegation protocol for accessing APIs and is the industry-standard protocol for identity and access management. To learn more about OAuth, see the OAuth 2.0 Protocol. OpenID Connect (OIDC) is an identity layer that sits on top of OAuth. It verifies a user’s identity and provides profile information from the identity provider to the systems that user logs in to. To learn more, see the OpenID website.
When a user attempts to authenticate with a system that uses OIDC, the login request is redirected to the IdP where the user provides credentials to prove their identity. After the IdP authenticates the user, it sends an authorization code to the user that the system then accepts as proof of identity. The system then requests user claims from the IdP to get any required information about the user and determine the level of access to give to the user. The IdP returns claims using JSON Web tokens.
When you configure SSO in PubSub+ Cloud, you can specify additional scopes to request from the IdP. Scopes are collections of information (claims) that the IdP can include during authentication. By default, PubSub+ Cloud requests the "openid" and "email" scopes.
Many IdPs can be configured to automatically include specific claims implicitly in the identity token for use in role management. However, for certain configurations, it may be necessary to explicitly request additional information (scopes) in addition to those mentioned above. In these cases, you can add the names of these additional scopes to your SSO configuration.