Chapter 7. Securing data

Procedure

1. Taking as input the tls.key and tls.crt from the certificate in PEM format, run the following command to create a keystore.

   openssl pkcs12 -export -in tls.crt -inkey tls.key -out keystore.pkcs12

   The following table describes the elements of the openssl command:

   Table 7.1. openssl command to generate a keystore from certificate files

   Command element	Description
   pkcs12	The openssl pkcs12 utility.
   -export	Exports the file.
   -in tls.crt	Identifies the certificate file.
   -inkey tls.key	Identifies the key to import into the keystore.
   -out keystore.pkcs12	Specifies the name of the keystore file to create.

2. From the keystore.pkcs12 file that you generated in the previous step, type the following command to convert the file to Base64 encoding:

   base64 keystore.pkcs12

3. Copy the contents of the command output to a YAML secret file.

   For more information, see Section 7.1.7, “Creating an OpenShift secret to store the keystore and truststore”.

1. From a terminal window, using the public key certificate, tls.crt, type the following command:

   keytool -import -file tls.crt -alias myalias -keystore truststore.pkcs12

2. Type the following command to convert the output to Base64 encoding:

   base64 truststore.pkcs12

3. Copy the contents of the command output and paste it into the secret.

Procedure

1. Create a YAML file to define a secret of type kubernetes.io/tls, and include the following information:

   • The public and private keys of the TLS key pair.
   • The name of the virtual database that you want to create.

   • The OpenShift namespace in which you want to create the virtual database.

     For example:

     apiVersion: v1
     kind: Secret
     type: Opaque
     metadata:
       name: _VDB_NAME-keystore 1
       namespace: PROJECT_NAME 2
     
     data: 3
       keystore.pkcs12: >-
           -----BEGIN KEYSTORE-----
           [...]
           -----END KEYSTORE-----
       truststore.pkcs12: >-
           -----BEGIN TRUSTSTORE-----
           [...]
           -----END TRUSTSTORE-----

     1

     The name of the secret. The secret name must match the name of the virtual database object in the CR YAML file that the Data Virtualization Operator uses to create a virtual database, for example, dv-customer.

     2

     The OpenShift namespace in which the virtual database service is deployed, for example, myproject.

     3

     The data value is made up of the contents of the TLS keystore certificate (keystore.pkcs12), and the truststore (truststore.pkcs12) in base64-encoded format.

2. Save the file as dv-customer-keystore.yaml.

3. Open a terminal window, sign in to the OpenShift project where you want to add the secret, and then type the following command:

   $ oc apply -f tls_secret.yaml

1. Type the following command to add the secret to OpenShift:

   oc create -f dv-customer-keystore.yaml

Procedure

1. From a browser, log in to the Red Hat Single Sign-On Admin Console.

2. Create a realm for your data virtualization service.

   1. From the menu for the master realm, hover over Master and then click Add realm.
   2. Type a name for the realm, such as datavirt, and then click Create.

3. Add roles.

   1. From the menu, click Roles.
   2. Click Add Role.
   3. Type a name for the role, for example ReadRole, and then click Save.
   4. Create other roles as needed to map to the roles in your organization’s LDAP or Active Directory. For information about federating user data from external identity providers, see the Server Administration Guide.

4. Add users.

   1. From the menu, click Users, and then click Add user.
   2. On the Add user form, type a user name, for example, user, specify other user properties that you want to assign, and then click Save.
      Only the user field is mandatory.
   3. From the details page for the user, click the Credentials tab.
   4. Type and confirm a password for the user, click Reset Password, and then click Change password when prompted.

5. Assign roles to the user.

   1. Click the Role Mappings tab.
   2. In the Available Roles field, click ReadRole and then click Add selected.
6. Create a second user called developer, and assign a password and roles to the user.

7. Create a data virtualization client entry.

   The client entry represents the data virtualization service as an SSO client application. .. From the menu, click Clients. .. Click Create to open the Add Client page. .. In the Client ID field, type a name for the client, for example, dv-client. .. In the Client Protocol field, choose openid-connect. .. Leave the Root URL field blank, and click Save.

Procedure

1. Log in to the Red Hat Single Sign-On Admin Console to find the values for the required authentication properties.

2. In a text editor, open the CR YAML file that you used to deploy your virtual database, and define authentication environment variables that are based on the values of your Red Hat Single Sign-On properties.

   For example:

   env:
     - name: KEYCLOAK_REALM
       value: master
     - name: KEYCLOAK_AUTH_SERVER_URL
       value: http://rh-sso-datavirt.openshift.example.com/auth
       - name: KEYCLOAK_RESOURCE
         value: datavirt
     - name: KEYCLOAK_SSL_REQUIRED
       value: external
     - name: KEYCLOAK_PUBLIC_CLIENT
       value: true

3. Declare a build source dependency for the following Maven artifact for securing data virtualizations: org.teiid:spring-keycloak

   For example:

   env:
     ....
     build:
       source:
         dependencies:
           - org.teiid:spring-keycloak

4. Save the CR.

Procedure

1. In a text editor, open the file that contains the DDL description that you used to deploy the virtual database.

2. Insert statements to add any roles that you defined for virtual database users in Red Hat Single Sign-On. For example, to add a role with the name ReadRole add the following statement to the DDL:

   CREATE ROLE ReadRole WITH FOREIGN ROLE ReadRole;

   Add separate CREATE ROLE statements for each role that you want to implement for the virtual database.

3. Insert statements that specify the level of access that users with the role have to database objects. For example,

   GRANT SELECT ON TABLE "portfolio.CustomerZip" TO ReadRole

   Add separate GRANT statements for each role that you want to implement for the virtual database.

4. Save and close the CR or DDL file.

   You are now ready to redeploy the virtual database. For information about how to run the Data Virtualization Operator to deploy the virtual database, see Chapter 6, Running the Data Virtualization Operator to deploy a virtual database.

   After you redeploy the virtual database, add a redirect URL in the Red Hat Single Sign-On Admin Console. For more information, see Section 7.3.4, “Adding a redirect URI for the data virtualization client in the Red Hat Single Sign-On Admin Console”.

Procedure

1. From a browser, sign in to the Red Hat Single Sign-On Admin Console.
2. From the security realm where you created the client for the data virtualization service, click Clients in the menu, and then click the ID of the data virtualization client that you created previously (for example, dv-client).
3. In the Valid Redirect URIs field, type the root URL for the OData service and append an asterisk to it. For example, http://datavirt.odata.example.com/*

4. Test whether Red Hat Single Sign-On intercepts calls to the OData API.

   1. From a browser, type the address of an OData endpoint, for example:

      http://datavirt.odata.example.com/odata/CustomerZip

      A login page prompts you to provide credentials.

5. Sign in with the credentials of an authorized user.

   Your view of the data depends on the role of the account that you use to sign in.