In order to allow external organizations to access your CSE content, you must grant them access via your existing IdP that is already being used for CSE or create the required additional Client IDs via your Google IdP, or your preferred third-party IdP. 

• • Google Reference:  Configure a guest IdP for any external users

  • Optional: A .well-known file can also be used for authentication if not using the Admin Console to configure the Guest IdP

Enter the Client ID generated from your IdP provider. For Google IdP, the Discovery URI will be https://accounts.google.com/.well-known/openid-configuration (referenced here).

Select which Web Apps you want to enable guest access for in the next page: Drive and Docs, and/or Meet. An additional Client ID is required if also enabling Guest access for Meet (referenced here).

Google IdP

If the external org needing guest access is using Google IdP without CSE enabled, an OAuth 2.0 Client ID will need to be created in Cloud Console > APIs & Services > Credentials. This Client ID will then be used to configure the Guest IdP in Admin Console of the org wishing to share content with the external org, as well as the VPK container for CSE. An additional Client ID will be needed if also configuring guest access for Meet as previously mentioned above.

VPK for CSE Container

• The new Client ID(s) will need to be added to the VPK container’s cse.env file as an additional value for the JWT_AUD variable. (Refer to this article for more information on the JWT_AUD variable.)

  • This value needs to be base64-encoded and placed within the cse.env file (or values.yamlfile if deploying via Helm).

  • { authn: [..., "client_ID"], authz: {...}}

• Additional environment variables need to be updated on the CSE container side are the JWKS_AUTHN_ISSUERS and JWKS_AUTHZ_ISSUERS variables. (Refer to this article for more information on these variables.)

  • These two are base64 encoded and they need to have the following added as a key-value pair to the dictionary that is encoded within the cse.env file (or values.yamlfile if deploying via Helm).

    Example:

• • For Google IdP:

{ ..., "https://accounts.google.com": "https://www.googleapis.com/oauth2/v3/certs" }

• • For Okta (or any 3rd-party IdP) as an example:

{ ..., "https://<customer>.okta.com": "https://<customer>.okta.com/oauth2/v1/keys" }

• Once the above steps are completed, restart the container(s). Repeat these steps for any additional containers in the customer’s environment.

End User Experience

Once the steps above have been completed, your end users can now create encrypted CSE files in Drive, Docs, Sheets & Slides and share them with external users.

With any authentication method, guests will be presented with pop-up message asking them to sign in with an identity provider before they can access client-side encrypted content.

Once authenticated, guest access will be granted and the external user can now view and edit CSE content shared to them. Collaboration is also enabled on encrypted CSE files like Docs, Sheets, and Slides.

For a detailed step-by-step on collaboration with CSE files, and how to get started with encrypted files, please visit the Google help center below:

• Collaborate on encrypted files in Docs, Sheets, & Slides
• Get started with encrypted files in Drive, Docs, Sheets & Slides