Chapter 12. Managing identities and authorizations
Chapter 12. Managing identities and authorizations This section describes different aspects of managing identities and authorizations of Red Hat CodeReady Workspaces. Section 12.1, "Authenticating users" Section 12.2, "Authorizing users" Section 12.3, "Configuring authorization" Section 12.6, "Removing user data" Section 12.4, "Configuring OpenShift OAuth" Section 12.5, "Configuring Minikube with GitHub Authentication" 12.1. Authenticating users This document covers all aspects of user authentication in Red Hat CodeReady Workspaces, both on the CodeReady Workspaces server and in workspaces. This includes securing all REST API endpoints, WebSocket or JSON RPC connections, and some web resources. All authentication types use the JWT open standard as a container for transferring user identity information. In addition, CodeReady Workspaces server authentication is based on the OpenID Connect protocol implementation, which is provided by default by RH-SSO . Authentication in workspaces implies the issuance of self-signed per-workspace JWT tokens and their verification on a dedicated service based on JWTProxy . 12.1.1. Authenticating to the CodeReady Workspaces server 12.1.1.1. Authenticating to the CodeReady Workspaces server using other authentication implementations This procedure describes how to use an OpenID Connect (OIDC) authentication implementation other than RH-SSO. Procedure Update the authentication configuration parameters that are stored in the multiuser.properties file (such as client ID, authentication URL, realm name). Write a single filter or a chain of filters to validate tokens, create the user in the CodeReady Workspaces dashboard, and compose the subject object. If the new authorization provider supports the OpenID protocol, use the OIDC JS client library available at the settings endpoint because it is decoupled from specific implementations. If the selected provider stores additional data about the user (first and last name, job title), it is recommended to write a provider-specific ProfileDao implementation that provides this information. 12.1.1.2. Authenticating to the CodeReady Workspaces server using OAuth For easy user interaction with third-party services, the CodeReady Workspaces server supports OAuth authentication. OAuth tokens are also used for GitHub-related plug-ins. OAuth authentication has two main flows: delegated Default. Delegates OAuth authentication to RH-SSO server. embedded Uses built-in CodeReady Workspaces server mechanism to communicate with OAuth providers. To switch between the two implementations, use the che.oauth.service_mode= <embedded|delegated> configuration property. The main REST endpoint in the OAuth API is /api/oauth , which contains: An authentication method, /authenticate , that the OAuth authentication flow can start with. A callback method, /callback , to process callbacks from the provider. A token GET method, /token , to retrieve the current user's OAuth token. A token DELETE method, /token , to invalidated the current user's OAuth token. A GET method, / , to get the list of configured identity providers. 12.1.1.3. Using Swagger or REST clients to execute queries The user's RH-SSO token is used to execute queries to the secured API on the user's behalf through REST clients. A valid token must be attached as the Request header or the ?token=USDtoken query parameter. Access the CodeReady Workspaces Swagger interface at \https://codeready-<openshift_deployment_name>.<domain_name>/swagger . The user must be signed in through RH-SSO, so that the access token is included in the Request header. 12.1.2. Authenticating in a CodeReady Workspaces workspace Workspace containers may contain services that must be protected with authentication. Such protected services are called secure . To secure these services, use a machine authentication mechanism. JWT tokens avoid the need to pass RH-SSO tokens to workspace containers (which can be insecure). Also, RH-SSO tokens may have a relatively shorter lifetime and require periodic renewals or refreshes, which is difficult to manage and keep in sync with the same user session tokens on clients. Figure 12.1. Authentication inside a workspace 12.1.2.1. Creating secure servers To create secure servers in CodeReady Workspaces workspaces, set the secure attribute of the endpoint to true in the dockerimage type component in the devfile. Devfile snippet for a secure server components: - type: dockerimage endpoints: - attributes: secure: 'true' 12.1.2.2. Workspace JWT token Workspace tokens are JSON web tokens ( JWT ) that contain the following information in their claims: uid : The ID of the user who owns this token uname : The name of the user who owns this token wsid : The ID of a workspace which can be queried with this token Every user is provided with a unique personal token for each workspace. The structure of a token and the signature are different from what they are in RH-SSO. The following is an example token view: # Header { "alg": "RS512", "kind": "machine_token" } # Payload { "wsid": "workspacekrh99xjenek3h571", "uid": "b07e3a58-ed50-4a6e-be17-fcf49ff8b242", "uname": "john", "jti": "06c73349-2242-45f8-a94c-722e081bb6fd" } # Signature { "value": "RSASHA256(base64UrlEncode(header) + . + base64UrlEncode(payload))" } The SHA-256 cipher with the RSA algorithm is used for signing JWT tokens. It is not configurable. Also, there is no public service that distributes the public part of the key pair with which the token is signed. 12.1.2.3. Machine token validation The validation of machine tokens (JWT tokens) is performed using a dedicated per-workspace service with JWTProxy running on it in a separate Pod. When the workspace starts, this service receives the public part of the SHA key from the CodeReady Workspaces server. A separate verification endpoint is created for each secure server. When traffic comes to that endpoint, JWTProxy tries to extract the token from the cookies or headers and validates it using the public-key part. To query the CodeReady Workspaces server, a workspace server can use the machine token provided in the CHE_MACHINE_TOKEN environment variable. This token is the user's who starts the workspace. The scope of such requests is restricted to the current workspace only. The list of allowed operations is also strictly limited. 12.2. Authorizing users User authorization in CodeReady Workspaces is based on the permissions model. Permissions are used to control the allowed actions of users and establish a security model. Every request is verified for the presence of the required permission in the current user subject after it passes authentication. You can control resources managed by CodeReady Workspaces and allow certain actions by assigning permissions to users. Permissions can be applied to the following entities: Workspace System All permissions can be managed using the provided REST API. The APIs are documented using Swagger at \https://codeready-<openshift_deployment_name>.<domain_name>/swagger/#!/permissions . 12.2.1. CodeReady Workspaces workspace permissions The user who creates a workspace is the workspace owner. By default, the workspace owner has the following permissions: read , use , run , configure , setPermissions , and delete . Workspace owners can invite users into the workspace and control workspace permissions for other users. The following permissions are associated with workspaces: Table 12.1. CodeReady Workspaces workspace permissions Permission Description read Allows reading the workspace configuration. use Allows using a workspace and interacting with it. run Allows starting and stopping a workspace. configure Allows defining and changing the workspace configuration. setPermissions Allows updating the workspace permissions for other users. delete Allows deleting the workspace. 12.2.2. CodeReady Workspaces system permissions CodeReady Workspaces system permissions control aspects of the whole CodeReady Workspaces installation. The following permissions are applicable to the system: Table 12.2. CodeReady Workspaces system permission Permission Description manageSystem Allows control of the system and workspaces. setPermissions Allows updating the permissions for users on the system. manageUsers Allows creating and managing users. monitorSystem Allows accessing endpoints used for monitoring the state of the server. All system permissions are granted to the administrative user. To configure the administrative user, use the CHE_SYSTEM_ADMIN__NAME property. The default value is admin . The system permissions are granted when the CodeReady Workspaces server starts. If the record of the user is not in the CodeReady Workspaces user database, the permissions are granted after the first login of the user. 12.2.3. manageSystem permission Users with the manageSystem permission have access to the following services: Path HTTP Method Description /resource/free/ GET Get free resource limits. /resource/free/{accountId} GET Get free resource limits for the given account. /resource/free/{accountId} POST Edit free resource limit for the given account. /resource/free/{accountId} DELETE Remove free resource limit for the given account. /installer/ POST Add installer to the registry. /installer/{key} PUT Update installer in the registry. /installer/{key} DELETE Remove installer from the registry. /logger/ GET Get logging configurations in the CodeReady Workspaces server. /logger/{name} GET Get configurations of logger by its name in the CodeReady Workspaces server. /logger/{name} PUT Create logger in the CodeReady Workspaces server. /logger/{name} POST Edit logger in the CodeReady Workspaces server. /resource/{accountId}/details GET Get detailed information about resources for the given account. /system/stop POST Shutdown all system services, prepare CodeReady Workspaces to stop. 12.2.4. monitorSystem permission Users with the monitorSystem permission have access to the following services. Path HTTP Method Description /activity GET Get workspaces in a certain state for a certain amount of time. 12.2.5. Listing CodeReady Workspaces permissions To list CodeReady Workspaces permissions that apply to a specific resource , perform the GET /permissions request. To list the permissions that apply to a user , perform the GET /permissions/{domain} request. To list the permissions that apply to all users , perform the GET /permissions/{domain}/all request. The user must have manageSystem permissions to see this information. The suitable domain values are: system organization workspace Note The domain is optional. If no domain is specified, the API returns all possible permissions for all the domains. 12.2.6. Assigning CodeReady Workspaces permissions To assign permissions to a resource, perform the POST /permissions request. The suitable domain values are: system organization workspace The following is a message body that requests permissions for a user with a userId to a workspace with a workspaceID : Requesting CodeReady Workspaces user permissions { "actions": [ "read", "use", "run", "configure", "setPermissions" ], "userId": "userID", 1 "domainId": "workspace", "instanceId": "workspaceID" 2 } 1 The userId parameter is the ID of the user that has been granted certain permissions. 2 The instanceId parameter is the ID of the resource that retrieves the permission for all users. 12.3. Configuring authorization CodeReady Workspaces uses the permissions model for user authorization. 12.3.1. Authorization and user management Red Hat CodeReady Workspaces uses RH-SSO to create, import, manage, delete, and authenticate users. RH-SSO uses built-in authentication mechanisms and user storage. It can use third-party identity management systems to create and authenticate users. Red Hat CodeReady Workspaces requires a RH-SSO token when you request access to CodeReady Workspaces resources. Local users and imported federation users must have an email address in their profile. The default RH-SSO credentials are admin:admin . You can use the admin:admin credentials when logging into Red Hat CodeReady Workspaces for the first time. It has system privileges. Identifying the RH-SSO URL Go to the OpenShift web console and to the RH-SSO project. 12.3.2. Configuring CodeReady Workspaces to work with RH-SSO The deployment script configures RH-SSO. It creates a codeready-public client with the following fields: Valid Redirect URIs : Use this URL to access CodeReady Workspaces. Web Origins The following are common errors when configuring CodeReady Workspaces to work with RH-SSO: Invalid redirectURI error Occurs when you access CodeReady Workspaces at myhost , which is an alias, and your original CHE_HOST is 1.1.1.1 . If this error occurs, go to the RH-SSO administration console and ensure that the valid redirect URIs are configured. CORS error Occurs when you have an invalid web origin. 12.3.3. Configuring RH-SSO tokens A user token expires after 30 minutes by default. You can change the following RH-SSO token settings: 12.3.4. Setting up user federation RH-SSO federates external user databases and supports LDAP and Active Directory. You can test the connection and authenticate users before choosing a storage provider. See the User storage federation page in RH-SSO documentation to learn how to add a provider. See the LDAP and Active Directory page in RH-SSO documentation to specify multiple LDAP servers. 12.3.5. Enabling authentication with social accounts and brokering RH-SSO provides built-in support for GitHub, OpenShift, and most common social networks such as Facebook and Twitter. See RH-SSO documentation to learn how to enable Login with GitHub . 12.3.5.1. Configuring GitHub OAuth OAuth for GitHub allows for automatic SSH key upload to GitHub. Prerequisites The oc tool is available. Procedure Create an OAuth application in GitHub with the following URLs: Enter the CodeReady Workspaces URL as Homepage URL . The default value is https://codeready-openshift-workspaces. <domain> / . Enter the Authorization callback URL as follows: If the Dev Workspace engine is not enabled, enter the RH-SSO GitHub endpoint URL as Authorization callback URL . The default value is https://keycloak-openshift-workspaces. <domain> /auth/realms/codeready/broker/github/endpoint . If the Dev Workspace engine is enabled, enter the CodeReady Workspaces OAuth callback URL as Authorization callback URL . The default value is https://codeready-openshift-workspaces. <domain> /api/oauth/callback . Create a new secret in the project where CodeReady Workspaces is deployed. 1 CodeReady Workspaces namespace. The default is openshift-workspaces 2 base64 encoded GitHub OAuth Client ID 3 base64 encoded GitHub OAuth Client Secret If CodeReady Workspaces was already installed wait until rollout of RH-SSO component finishes. 12.3.5.2. Configuring a Bitbucket server that uses self-signed TLS certificates The following chapter describes how to configure a Bitbucket (BB) server that uses self-signed TLS certificates so that the CodeReady Workspaces server and workspace components can establish a trusted connection with BB. Creating ConfigMaps for additional TLS and gitSelfSign certificates. This enables: Launching a factory using a devfile URL. Importing and cloning a project. Note Configure the OAuth 1 authentication on the BB server side. For more information, see Configuring Bitbucket Server OAuth 1 Creating a ConfigMap for importing additional certificates is necessary only if a BB server is setup with self-signed TLS certificates. These certificates are needed for the proper functionality of CodeReady Workspaces server and tools inside of a workspace, which use them for performing Git operations related to a specific repository. Prerequisites A value of the BB server certification authority (CA) exported in the Base64 ASCII format and stored in a ca.crt file. An instance of CodeReady Workspaces. Procedure Provision the CA of the BB server to the CodeReady Workspaces server to enable it to read the devfiles stored in the BB server. To do so, add the following ConfigMap to the openshift-workspaces project: Provision the CA of the BB server to the CodeReady Workspaces server to be able to use Git operations. To do so, add a new ConfigMap to the openshift-workspaces project: Edit the CheCluster Custom Resource (CR) to configure the CodeReady Workspaces server. spec: server: # ... gitSelfSignedCert: <boolean> 1 1 Use true for a BB server that use a self-signed cert. Default value: false . For more information, see https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#advanced-configuration-options-for-the-che-server-component.adoc . Reference For adding a Bitbucket CA certificate into CodeReady Workspaces, see https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#importing-untrusted-tls-certificates.adoc . 12.3.5.3. Configuring the Bitbucket and CodeReady Workspaces integration to use OAuth1 The following section describes the configuration of the OAuth 1 authentication that is needed for performing read and write operations with Bitbucket (BB) repositories. To use BB repositories with allowed Git operations, such as clone and push , register a BB endpoint with CodeReady Workspaces first, and configure the OAuth 1 authentication. Note This procedure requires: generating RSA key pairs generating a consumer key-secret pair creating an application link on the BB side configuring BB on the CodeReady Workspaces-server side This procedure also describes how to activate OAuth 1 for Bitbucket Server to: Use devfiles hosted on a Bitbucket Server. Enable CodeReady Workspaces to obtain and renew Bitbucket Server Personal access tokens . Prerequisites The oc tool is available. Bitbucket Server is available from CodeReady Workspaces server. An instance of CodeReady Workspaces. Procedure Generate an RSA key pair and a stripped-down version of the public key: Generate a consumer key and a shared secret. Configure an Application Link in Bitbucket to enable the communication from CodeReady Workspaces to Bitbucket Server. In Bitbucket Server, click the cog in the top navigation bar to navigate to Administration > Application Links . Enter the application URL: \https://codeready-<openshift_deployment_name>.<domain_name> and click the Create new link button. In the warning message stating No response was received from the URL click the Continue button. Complete the Link Applications form and click the Continue button. Application Name <CodeReady Workspaces> Application Type Generic Application. Service Provider Name <CodeReady Workspaces> Consumer Key Paste the content of the <bitbucket_server_consumer_key> file. Shared secret Paste the content of the <bitbucket_shared_secret> file. Request Token URL <Bitbucket Server URL> /plugins/servlet/oauth/request-token Access token URL <Bitbucket Server URL> /plugins/servlet/oauth/access-token Authorize URL <Bitbucket Server URL> /plugins/servlet/oauth/access-token Create incoming link Enabled. Complete the Link Applications form and click the Continue button. Consumer Key Paste the content of the <bitbucket_server_consumer_key> file. Consumer name <CodeReady Workspaces> Public Key Paste the content of the <public-stripped.pub> file. Create a OpenShift Secret in CodeReady Workspaces project containing the consumer and private keys. USD oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: <CodeReady Workspaces-namespace> 1 labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: ' <scm-server-endpoint> ' 2 type: Opaque data: private.key: ' <user-private-key> ' 3 consumer.key: ' <bitbucket_server_consumer_key> ' 4 EOF 1 CodeReady Workspaces namespace. The default is openshift-workspaces 2 Bitbucket Server URL 3 base64 encoded content of the <privatepkcs8.pem> file without first and last lines. 4 base64 encoded content of the <bitbucket_server_consumer_key> file. Example #!/usr/bin/env bash NS=USD{1:-eclipse-che} CONSUMER_KEY=USD(cat ./certs/bitbucket_server_consumer_key) PRIVATE_KEY=USD(cat ./certs/privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n') BITBUCKET_HOST=' <your-bitbucket-host-here> ' unameOut="USD(uname -s)" case "USD{unameOut}" in Linux*) BASE64_FUNC='base64 -w 0';; Darwin*) BASE64_FUNC='base64';; CYGWIN*) BASE64_FUNC='base64 -w 0';; MINGW*) BASE64_FUNC='base64 -w 0';; *) BASE64_FUNC='base64 -w 0' esac cat <<EOF | oc apply -n USDNS -f - kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: https://USDBITBUCKET_HOST type: Opaque data: private.key: USD(echo -n USDPRIVATE_KEY | USDBASE64_FUNC) consumer.key: USD(echo -n USDCONSUMER_KEY | USDBASE64_FUNC) EOF See the whole script in this GitHub example . Additional resources Bitbucket Server overview Download Bitbucket Server Bitbucket Server Personal access tokens How to generate public key to application link 3rd party applications Using AppLinks to link to other applications https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#authenticating-on-scm-server-with-a-personal-access-token.adoc . 12.3.5.4. Configuring GitLab servers To use a GitLab server as a project sources supplier, register the GitLab server URL with CodeReady Workspaces using the CHE_INTEGRATION_GITLAB_SERVER__ENDPOINTS property and specify the hostname of the server to register. Example For additional examples of configuring GitLab servers see Understanding CodeReady Workspaces server advanced configuration using the Operator Additional resources https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#advanced-configuration-options-for-the-che-server-component.adoc 12.3.5.5. Configuring GitLab OAuth2 with the codeready-server engine OAuth2 for GitLab allows accepting factories from private GitLab repositories. Prerequisites The GitLab server is running and available from CodeReady Workspaces. Procedure Create a Authorized OAuth2 application in GitLab using CodeReady Workspaces as the application Name and RH-SSO GitLab endpoint URL as the value for Redirect URI . The callback URL default value is https://keycloak-openshift-workspaces. <DOMAIN> /auth/realms/codeready/broker/gitlab/endpoint , where <DOMAIN> is OpenShift cluster domain. Store the Application ID and Secret values. All three types of GitLab OAuth 2 applications are supported: User owned, Group owned and Instance-wide. Create a custom OIDC provider link on RH-SSO pointing to GitLab server. Fill the following fields: Client ID a value from the Application ID field provided by GitLab server in step; Client Secret a value from Secret field provided by GitLab server in step; Authorization URL a URL which have a https:// <GITLAB_DOMAIN> /oauth/authorize format; Token URL a URL which have a https:// <GITLAB_DOMAIN> /oauth/token format; Scopes set of scopes which must contain (but not limited to) the following set: api write_repository openid ; Store Tokens needs to be enabled; Store Tokens Readable needs to be enabled Note Substitute <GITLAB_DOMAIN> with the URL and port of the GitLab installation. Register the GitLab instance URL with the enabled OAuth 2 support in CodeReady Workspaces using the CHE_INTEGRATION_GITLAB_OAUTH__ENDPOINT property. Warning The GitLab instance URL must be present in the list of configured GitLab integration endpoints, set by the CHE_INTEGRATION_GITLAB_SERVER__ENDPOINTS property. Additional resources In case of having issues CodeReady Workspaces accessing GitLab related to TLS keys, consult with the following docs: https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#importing-untrusted-tls-certificates.adoc . https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#deploying-che-with-support-for-git-repositories-with-self-signed-certificates.adoc . 12.3.5.6. Configuring GitLab OAuth2 with the Dev Workspace engine Prerequisites The GitLab server is running and available from CodeReady Workspaces. Procedure Create an OAuth2 Authorized application in Gitlab: Enter Che as the application Name . Enter the CodeReady Workspaces OAuth callback URL as the Redirect URI . The default value is https://codeready-openshift-workspaces. <domain> /api/oauth/callback . Check the Confidential and Expire access tokens checkboxes. Under Scopes , check the api , write_repository , and openid checkboxes. Click Save application and store the Application ID and Secret values. Create a new secret in the project where CodeReady Workspaces is deployed. 1 The CodeReady Workspaces namespace. The default is openshift-workspaces. Additional resources Configure GitLab as an OAuth 2.0 authentication identity provider 12.3.6. Using protocol-based providers RH-SSO supports SAML v2.0 and OpenID Connect v1.0 protocols. 12.3.7. Managing users using RH-SSO You can add, delete, and edit users in the user interface. See RH-SSO User Management for more information. 12.3.8. Configuring CodeReady Workspaces to use an external RH-SSO installation By default, CodeReady Workspaces installation includes the deployment of a dedicated RH-SSO instance. However, using an external RH-SSO is also possible. This option is useful when a user has an existing RH-SSO instance with already-defined users, for example, a company-wide RH-SSO server used by several applications. Table 12.3. Placeholders used in examples <provider-realm-name> RH-SSO realm name intended for use by CodeReady Workspaces <oidc-client-name> Name of the oidc client defined in <provider-realm-name> <auth-base-url> Base URL of the external RH-SSO server Prerequisites In the administration console of the external installation of RH-SSO, define a realm that contains the users to connect to CodeReady Workspaces: In this realm , define an OIDC client that CodeReady Workspaces will use to authenticate the users. This is an example of such a client with the correct settings: Note Client Protocol must be openid-connect . Access Type must be public . CodeReady Workspaces only supports the public access type. Valid Redirect URIs must contain at least two URIs related to the CodeReady Workspaces server, one using the http protocol and the other https . These URIs must contain the base URL of the CodeReady Workspaces server, followed by /* wildcards. Web Origins must contain at least two URIs related to the CodeReady Workspaces server, one using the http protocol and the other https . These URIs must contain the base URL of the CodeReady Workspaces server, without any path after the host. The number of URIs depends on the number of installed product tools. With CodeReady Workspaces that uses the default OpenShift OAuth support, user authentication relies on the integration of RH-SSO with OpenShift OAuth. This allows users to log in to CodeReady Workspaces with their OpenShift login and have their workspaces created under personal OpenShift projects. This requires setting up an OpenShift "RH-SSO Identity Provider". When using an external RH-SSO, configure the RH-SSO manually. For instructions, see the appropriate RH-SSO documentations for either OpenShift 3 or OpenShift 4 . The configured RH-SSO has the options Store Tokens and Stored Tokens Readable enabled. Procedure Set the following properties in the CheCluster Custom Resource (CR): spec: auth: externalIdentityProvider: true identityProviderURL: <auth-base-url> identityProviderRealm: <provider-realm-name> identityProviderClientId: <oidc-client-name> When installing CodeReady Workspaces with OpenShift OAuth support enabled, set the following properties in the CheCluster Custom Resource (CR): spec: auth: openShiftoAuth: true # Note: only if the OpenShift "RH-SSO Identity Provider" alias is different from 'openshift-v3' or 'openshift-v4' server: customCheProperties: CHE_INFRA_OPENSHIFT_OAUTH IDENTITY PROVIDER: <OpenShift "RH-SSO Identity Provider" alias> 12.3.9. Configuring SMTP and email notifications Red Hat CodeReady Workspaces does not provide any pre-configured MTP servers. To enable SMTP servers in RH-SSO: Go to che realm settings > Email . Specify the host, port, username, and password. Red Hat CodeReady Workspaces uses the default theme for email templates for registration, email confirmation, password recovery, and failed login. 12.3.10. Enabling self-registration Self-registration allows users to register themselves in a CodeReady Workspaces instance by accessing the CodeReady Workspaces server URL. For CodeReady Workspaces installed without OpenShift OAuth support, self-registration is disabled by default, therefore the option to register a new user is not available on the login page. Prerequisites You are logged in as an administrator. Procedure To enable self-registration of users: Navigate to the Realm Settings menu on the left and open the Login tab. Set User registration option to On . 12.4. Configuring OpenShift OAuth For users to interact with OpenShift, they must first authenticate to the OpenShift cluster. OpenShift OAuth is a process in which users prove themselves to a cluster through an API with obtained OAuth access tokens. Authentication with the https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#openshift-connector-overview.adoc is a possible way for CodeReady Workspaces users to authenticate with an OpenShift cluster. The following section describes the OpenShift OAuth configuration options and its use with a CodeReady Workspaces. 12.4.1. Configuring OpenShift OAuth with initial user Prerequisites The oc tool is available. crwctl management tool is available. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#using-the-chectl-management-tool.adoc . Procedure Configure OpenShift identity providers on the cluster. See the Understanding identity provider configuration . When a user skips the Configuring step of OpenShift "RH-SSO Identity Provider", and the OpenShift cluster does not already contain a configured RH-SSO, CodeReady Workspaces creates an initial OpenShift user for the HTPasswd identity provider. Credentials of this user are stored in the openshift-oauth-user-credentials secret, located in the openshift-config namespace. Obtain the credentials for logging in to an OpenShift cluster and CodeReady Workspaces instance: Obtain OpenShift user name: Obtain OpenShift user password: Deploy CodeReady Workspaces using OperatorHub or the crwctl, see the crwctl server:deploy specification chapter. OpenShift OAuth will be enabled by default. 12.4.2. Configuring OpenShift OAuth without provisioning OpenShift initial OAuth user The following procedure describes how to configure OpenShift OAuth without provisioning the initial OAuth user. Prerequisites crwctl management tool is available. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#using-the-chectl-management-tool.adoc . Procedure If you have installed CodeReady Workspaces by using the Operator, configure the following values in the codeready-workspaces Custom Resource: spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: '' If you have installed CodeReady Workspaces by using the crwctl tool, use the --che-operator-cr-patch-yaml flag: The patch.yaml file must contain the following: spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: '' 12.4.3. Removing OpenShift initial OAuth user The following procedure describes how to remove OpenShift initial OAuth user provisioned by Red Hat CodeReady Workspaces. Prerequisites The oc tool installed. An instance of Red Hat CodeReady Workspaces running on OpenShift. Logged in to OpenShift cluster using the oc tool. Procedure Update codeready-workspaces custom resource: 12.5. Configuring Minikube with GitHub Authentication On Minikube, crwctl provides a default OpenID Connect (OIDC) issuer, which can serve as a bridge to third party RH-SSO, such as GitHub. Dex is the default OIDC issuer, preconfigured with static users. Configure Dex to use GitHub authentication. Prerequisites CodeReady Workspaces is installed on Minikube. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#installing-che-on-minikube.adoc . Procedure Get Minikube IP and remember it as <minikube_ip> : Create an OAuth App for your Minikube instance in GitHub. See GitHub documentation . 1 Name is only displayed on GitHub. It is not used internally so it can be any name. 2 Main URL to CodeReady Workspaces instance. 3 Callback URL to Dex. crwctl deploys Dex on dex. subdomain. In the GitHub OAuth application page, click Generate a new client secret and remember the value of the generated client secret as <client_secret> . Edit the Dex config map: connectors: - type: github id: github name: GitHub config: clientID: <client_id> 1 clientSecret: <client_secret> 2 redirectURI: https://dex. <minikube_ip> .nip.io/callback 3 1 OAuth client id copied from GitHub OAuth application 2 OAuth client secret, generated at GitHub in step 3 Callback URL to Dex. This must match configuration in GitHub OAuth application from step 1. Note: To remove Dex static users, delete all enablePasswordDB and staticPasswords sections. Restart the Dex pod: Verification steps Open CodeReady Workspaces URL. The dashboard displays GitHub login prompt. 12.6. Removing user data 12.6.1. Removing user data according to GDPR The General Data Protection Regulation ( GDPR ) law enforces the right for individuals to have personal data erased. The following procedure describes how to remove a user's data from a cluster and the RH-SSO database. Note The following commands use the default OpenShift project, openshift-workspaces , as a user's example for the -n option. Prerequisites A user or an administrator authorization token. To delete any other data except the data bound to a user account, admin privileges are required. The admin is a special CodeReady Workspaces administrator account pre-created and enabled using the CHE_SYSTEM_ADMIN__NAME and CHE_SYSTEM_SUPER__PRIVILEGED__MODE = true Custom Resource definitions. If needed, use commands below for creating the admin user: Note All system permissions are granted to the administrative user. To configure the administrative user, use the CHE_SYSTEM_ADMIN__NAME property. The default value is admin . The system permissions are granted when the CodeReady Workspaces server starts. If the user record is not in the CodeReady Workspaces user database, the permissions are granted after the first login of the user. Authorization token privileges: admin - Can delete all personal data of all users user - Can delete only the data related to the user A user or an administrator is logged in the OpenShift cluster with deployed CodeReady Workspaces. A user ID is obtained. Get the user ID using the commands below: For the current user: To find a user by name: To find a user by email: Example of obtaining a user ID This example uses vparfono as a local user name. The user ID is at the bottom of the curl command output. { "name": "vparfono", "links": [ { . . . } ], "email": "vparfono@redhat.com", "id": "921b6f33-2657-407e-93a6-fb14cf2329ce" } Procedure Update the codeready-workspaces CheCluster Custom Resource (CR) definition to permit the removal of a user's data from the RH-SSO database: Remove the data using the API: Verification Running the following command returns code 204 as the API response: Additional resources To remove the data of all users, follow the instructions for https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#uninstalling-che.adoc .
components: - type: dockerimage endpoints: - attributes: secure: 'true' Header { "alg": "RS512", "kind": "machine_token" } Payload { "wsid": "workspacekrh99xjenek3h571", "uid": "b07e3a58-ed50-4a6e-be17-fcf49ff8b242", "uname": "john", "jti": "06c73349-2242-45f8-a94c-722e081bb6fd" } Signature { "value": "RSASHA256(base64UrlEncode(header) + . + base64UrlEncode(payload))" } { "actions": [ "read", "use", "run", "configure", "setPermissions" ], "userId": "userID", 1 "domainId": "workspace", "instanceId": "workspaceID" 2 } oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: github-oauth-config namespace: <...> 1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: github type: Opaque data: id: <...> 2 secret: <...> 3 EOF oc create configmap bitbucket-ca-cert-for-factory --from-file=ca.crt -n openshift-workspaces oc label configmap bitbucket-ca-cert-for-factory app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=ca-bundle -n openshift-workspaces oc create configmap che-git-self-signed-cert --from-file=ca.crt --from-literal=githost= <bitbucket_server_url> -n openshift-workspaces spec: server: # ... gitSelfSignedCert: <boolean> 1 openssl genrsa -out <private.pem> 2048 openssl rsa -in <private.pem> -pubout > <public.pub> openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in <private.pem> -out <privatepkcs8.pem> cat <public.pub> | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > <public-stripped.pub> openssl rand -base64 24 > <bitbucket_server_consumer_key> openssl rand -base64 24 > <bitbucket_shared_secret> oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: <CodeReady Workspaces-namespace> 1 labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: ' <scm-server-endpoint> ' 2 type: Opaque data: private.key: ' <user-private-key> ' 3 consumer.key: ' <bitbucket_server_consumer_key> ' 4 EOF #!/usr/bin/env bash NS=USD{1:-eclipse-che} CONSUMER_KEY=USD(cat ./certs/bitbucket_server_consumer_key) PRIVATE_KEY=USD(cat ./certs/privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n') BITBUCKET_HOST=' <your-bitbucket-host-here> ' unameOut="USD(uname -s)" case "USD{unameOut}" in Linux*) BASE64_FUNC='base64 -w 0';; Darwin*) BASE64_FUNC='base64';; CYGWIN*) BASE64_FUNC='base64 -w 0';; MINGW*) BASE64_FUNC='base64 -w 0';; *) BASE64_FUNC='base64 -w 0' esac cat <<EOF | oc apply -n USDNS -f - kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: https://USDBITBUCKET_HOST type: Opaque data: private.key: USD(echo -n USDPRIVATE_KEY | USDBASE64_FUNC) consumer.key: USD(echo -n USDCONSUMER_KEY | USDBASE64_FUNC) EOF https://gitlab.apps.cluster-2ab2.2ab2.example.opentlc.com/ oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: gitlab-oauth-config namespace: <namespace> 1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: gitlab che.eclipse.org/scm-server-endpoint: <your_GitLab_service_URL> type: Opaque data: id: <base64_encoded_GitLab_Application_ID> secret: <base64_encoded_GitLab_Secret> EOF spec: auth: externalIdentityProvider: true identityProviderURL: <auth-base-url> identityProviderRealm: <provider-realm-name> identityProviderClientId: <oidc-client-name> spec: auth: openShiftoAuth: true Note: only if the OpenShift "RH-SSO Identity Provider" alias is different from 'openshift-v3' or 'openshift-v4' server: customCheProperties: CHE_INFRA_OPENSHIFT_OAUTH IDENTITY PROVIDER: <OpenShift "RH-SSO Identity Provider" alias> oc get secret openshift-oauth-user-credentials -n openshift-config -o json | jq -r '.data.user' | base64 -d oc get secret openshift-oauth-user-credentials -n openshift-config -o json | jq -r '.data.password' | base64 -d spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: '' crwctl server:deploy --che-operator-cr-patch-yaml=patch.yaml spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: '' oc patch checluster/codeready-workspaces -n openshift-workspaces --type=json -p '[{"op": "replace", "path": "/spec/auth/initialOpenShiftOAuthUser", "value": false}]' minikube ip Application name: CodeReady Workspaces 1 Homepage URL: https://<minikube_ip>.nip.io 2 Authorization callback URL: https://dex.<minikube_ip>.nip.io/callback 3 oc edit configmap dex -n dex connectors: - type: github id: github name: GitHub config: clientID: <client_id> 1 clientSecret: <client_secret> 2 redirectURI: https://dex. <minikube_ip> .nip.io/callback 3 oc delete pod dex -n dex spec: server: customCheProperties: CHE_SYSTEM_SUPER__PRIVILEGED__MODE: 'true' CHE_SYSTEM_ADMIN__NAME: ' <admin-name> ' oc patch checluster/codeready-workspaces --type merge -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_SUPER__PRIVILEGED__MODE": "true"} } }}' -n openshift-workspaces oc patch checluster/codeready-workspaces --type merge -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_ADMIN__NAME": " <admin-name> "} } }}' -n openshift-workspaces curl -X GET --header 'Authorization: Bearer <user-token> ' 'https:// <codeready- <openshift_deployment_name> . <domain_name> > /api/user' curl -X GET --header 'Authorization: Bearer <user-token> ' 'https:// <codeready- <openshift_deployment_name> . <domain_name> > /api/user/find?name= <username> ' curl -X GET --header 'Authorization: Bearer <user-token> ' 'https:// <codeready- <openshift_deployment_name> . <domain_name> > /api/user/find?email= <email> ' curl -X GET --header 'Authorization: Bearer <user-token> ' 'https://che-vp-che.apps.che-dev.x6e0.p1.openshiftapps.com/api/user/find?name=vparfono' { "name": "vparfono", "links": [ { . . . } ], "email": "vparfono@redhat.com", "id": "921b6f33-2657-407e-93a6-fb14cf2329ce" } oc patch checluster/codeready-workspaces --patch "{\"spec\":{\"server\":{\"customCheProperties\": {\"CHE_KEYCLOAK_CASCADE__USER__REMOVAL__ENABLED\": \"true\"}}}}" --type=merge -n openshift-workspaces curl -i -X DELETE --header 'Authorization: Bearer <user-token> ' https:// <codeready- <openshift_deployment_name> . <domain_name> > /api/user/ <user-id> curl -i -X DELETE --header 'Authorization: Bearer <user-token> ' https:// <codeready- <openshift_deployment_name> . <domain_name> > /api/user/ <user-id>