/owl/config/**.
+2. Prefix all properties with the `export` statement.
+3. Restart the web app.
+{% endtab %}
+
+{% tab title="Cloud native installation" %}
+1. Add the properties as environment variables to your **owl-web ConfigMap**.
+2. Recycle the pod.
+{% endtab %}
+{% endtabs %}
+
+#### Required properties
+
+| Property | Description |
+| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| SAML\_ENABLED | Whether Collibra DQ uses SAML.
If set to false, users sign in with a username and password.
If set to true, SAML handles the authentication request.
|
+| SAML\_ENTITY\_ID | The name of the application for the identity provider, for example Collibra DQ.
It is an immutable unique identifier of the service provider for the identity provider (IDP).
|
+
+#### Optional properties: general
+
+You can further configure your SAML setup with the following optional properties.
+
+| Property | Description |
+| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| SAML\_ENTITY\_BASEURL | The base URL that is provided in the service provider metadata.
Set this property when you use DNS.
|
+| SAML\_LB\_EXISTS | Whether the application needs to configure a load balancer.
You generally need this setting only when the Load Balancer is set for SSL Termination.
The default value is false.
If set to true, you must also provide a value for SAML_LB_SERVER_NAME.
|
+| SAML\_METADATA\_USE\_URL | Whether Collibra DQ uses an URL or a file for the identity provider metadata.
The default value is true.
If set to false, the file must be accessible to the owl-web and the path provided in the Meta-Data URL field of the Meta Data Configurations section under Admin Console --> SAML Setup --> Connection.
|
+| SAML\_ROLES\_PROP\_NAME | The attribute in which the identity provider stores the role of the user authenticating in the SAML response.
The default value is memberOf.
|
+| SAML\_GRANT\_ALL\_PUBLIC | Whether any user authenticated by the identity provider is allowed to login the Collibra DQ application.
The default value is false.
|
+| SAML\_USER\_NAME\_PROP | The name of the attribute in the SAML response that contains the username of the user who is authenticating. |
+| SAML\_TENANT\_PROP\_NAME | If using multi-tenant mode, the variable in which the identity provider stores the tenant name of the user authenticating in the SAML response.
The app will attempt to use the RelayState parameter to identify the tenant and then fall back on this property.
|
+| SAML\_KEYSTORE\_FILE | The path to the keystore for SSL validation.
The store should contain the keypair of the identity provider for SSL verification.
|
+| SAML\_KEYSTORE\_PASS | The password for the keystore provided in `SAML_KEYSTORE_FILE`. |
+| SAML\_KEYSTORE\_ALIAS | The alias of the keypair (private and public) in the keystore used for SSL verification. |
+
+#### Optional p
+
+When **SAML\_METADATA\_USE\_URL** is set to `true` (default), the following additional properties are available.
+
+| Property | Description |
+| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| SAML\_METADATA\_TRUST\_CHECK | Whether to enable Collibra DQ to do trust verification of the identity provider.
The default value is false.
|
+| SAML\_METADATA\_REQUIRE\_SIGNATURE | Whether Collibra DQ signs authentication requests to the identity provider.
The default value is false.
|
+| SAML\_INCLUDE\_DISCOVERY\_EXTENSION | Whether to enable Collibra DQ to indicate in the SAML metadata that it’s able to consume responses from an IDP Discovery Service.
The default value is false.
|
+
+#### Optional Properties: Load Balancer
+
+When **SAML\_LB\_EXISTS** is set to `true`, the following additional properties are available.
+
+| Property | Description |
+| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| SAML\_LB\_INCLUDE\_PORT\_IN\_REQUEST | Whether to include the port number in the request.
The default value is false.
|
+| SAML\_LB\_PORT | The port number of the load balancer.
The default value is 443.
|
+| SAML\_LB\_SCHEME | The protocol of the load balancer.
The default value is https.
|
+| SAML\_LB\_SERVER\_NAME | The server or DNS name.
Usually, the same as SAML_ENTITY_BASEURL without specifying the protocol, for example without https://.
This property is required and has no default.
|
+| SAML\_LB\_CONTEXT\_PATH | Any path that may be defined on the load balancer. |
+
+{% code title="Example" %}
+```
+#enable SAML & show the SAML SSO option on the login page
+SAML_ENABLED=true
+
+#set SSL communication properties for SAML
+SAML_KEYSTORE_FILE=/keystore.p12
+SAML_KEYSTORE_PASS=****
+SAML_KEYSTORE_ALIAS=****
+
+#in multi-tenant mode set the name of the IDP variable to hold the tenat name
+SAML_TENANT_PROP_NAME=tenant
+
+#set the name of the IDP variable to hold the user roles in the response
+SAML_ROLES_PROP_NAME=memberOf
+
+#allow login if authenticated to the IDP
+SAML_GRANT_ALL_PUBLIC=true
+
+#set the EntityId of the application to be supplied to the IDP
+SAML_ENTITY_ID=OwlOneLogin
+
+#optinally set a property that contains the username in the response
+SAML_USER_NAME_PROP=""
+
+#optionally use a file for the IDP metadata vs a URL (default is true)
+SAML_METADATA_USE_URL=false
+
+#optional security settings to
+SAML_METADATA_TRUST_CHECK=false
+SAML_METADATA_REQUIRE_SIGNATURE=false
+SAML_INCLUDE_DISCOVERY_EXTENSION=false
+```
+{% endcode %}
+
+### Download service provider metadata for the IDP
+
+Once you have enabled and configured SAML authentication, you can download the service provider metadata that is required by your identity provider from `https:///saml/metadata`.
+
+### Enable the SAML sign in option
+
+When you are ready with your IDP settings, add the final configuration settings in the **Admin Console**:
+
+1. Sign in as an existing administrator with a username and password to the tenant you want to configure.
+2. In the **Admin Console**, click **SAML Setup**.
+3. In the **Connection** tab, select the **SAML Enabled** check-box.
+4. In the **Meta Data Configurations** section, click **+Add**.
+5. Enter the required information.
+
+| Option | Description |
+| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Meta-Data URL | The URL of the identity provider metadata XML file or the location of the downloaded XML file, depending on how you configured the SAML\_METADATA\_USE\_URL property. |
+| Meta-Data Label | The name for this specific configuration. |
+| IDP URL | The URL of the Collibra DQ application that is provisioned by the identity provider. |
+
+Save your changes.
+
+{% hint style="success" %}
+Once you complete this setup, you can restart your application and sign in using the SAML SSO option.
+{% endhint %}
diff --git a/security/configuration/authentication-with-saml-idp/multi-tenancy-support-through-saml-relaystate.md b/security/configuration/authentication-with-saml-idp/multi-tenancy-support-through-saml-relaystate.md
new file mode 100644
index 00000000..061bb350
--- /dev/null
+++ b/security/configuration/authentication-with-saml-idp/multi-tenancy-support-through-saml-relaystate.md
@@ -0,0 +1,7 @@
+# Multi-tenancy support through SAML RelayState
+
+Starting with Collibra DQ version 2021.11, in a multi-tenant environment, you can help route SSO to the proper tenant with the SAML provided **RelayState** property.
+
+When set, the property is sent to the IDP and then returned to the consumer service, such as /saml/SSO. The application checks that value to ensure the correct tenant is set up.
+
+You can set the **RelayState** property in the in the **SAML Setup** section of the **Admin Console**.
diff --git a/security/configuration/connection-security.md b/security/configuration/connection-security.md
new file mode 100644
index 00000000..caf9e541
--- /dev/null
+++ b/security/configuration/connection-security.md
@@ -0,0 +1,17 @@
+# Connection Security
+
+Log into the Admin Console Page as an Administrator of Owl.
+
+Go to the Admin Console page (click the Owl -> click the Gear -> click Admin Console).
+
+Click on “Security” and toggle on “DB Connection Security”.
+
+Log into the Admin Console Page as an Administrator of Owl.
+
+Go to the Admin Console page (click the Owl -> click the Gear -> click Admin Console).
+
+Click on “DB Access” as shown below
+
+
+
+Here you will see all the established connections. Click on a connection name to begin mapping roles to the connection. Any user in those mapped roles will be able to see the connection in the UI.
diff --git a/security/configuration/dataset-security/README.md b/security/configuration/dataset-security/README.md
new file mode 100644
index 00000000..6380fcd1
--- /dev/null
+++ b/security/configuration/dataset-security/README.md
@@ -0,0 +1,23 @@
+# Dataset Security
+
+Log into the Admin Console Page as an Administrator of Owl.
+
+Go to the Admin Console page (click the Owl -> click the Gear -> click Admin Console).
+
+Click on “Security” as described in the “Security Settings” section of this document (just above) and toggle on “Dataset Security”.
+
+Log into the Admin Console Page as an Administrator of Owl.
+
+Go to the Admin Console page (click the Owl -> click the Gear -> click Admin Console).
+
+Click on “Datasets” as shown below
+
+
+
+Note all the Datasets from the demo script we launch at the beginning of this document have been added to ROLE\_PUBLIC ROLE defined in Owl except the row\_count Dataset. At this point we already have the [odemo@owl.com](mailto:odemo@owl.com) user created and mapped to the ROLE\_PUBLIC ROLE which has access to those Datasets. Lets login as [odemo@owl.com](mailto:odemo@owl.com) and try to access row\_count DatasetStats page (for an understanding on how to access the DatasetStats page see section entitled “Understanding the DQ DatasetStats Page” in this document…..doing so will result in the error message below.
+
+
+
+However I can see the other DatasetStats that are part of the PUBLIC\_ROLE as [odemo@owl.com](mailto:odemo@owl.com) is a member of that ROLE.
+
+The last thing to notice is that as the user [odemo@owl.com](mailto:odemo@owl.com) cannot access the Admin pages the AD Group odemo is a part of the ADMIN\_ROLE.
diff --git a/security/configuration/dataset-security/dataset-masking.md b/security/configuration/dataset-security/dataset-masking.md
new file mode 100644
index 00000000..d6099ea2
--- /dev/null
+++ b/security/configuration/dataset-security/dataset-masking.md
@@ -0,0 +1,20 @@
+---
+description: Add column level masking for sensitive data in a dataset
+---
+
+# Dataset Masking
+
+## Masking From the UI
+
+After an owlcheck has been run you can perform column level masking from the hoot page if you have ROLE\_ADMIN or ROLE\_DATASET\_MANAGER.
+
+{% hint style="info" %}
+Masking updates will take effect for all existing and future runs of the selected dataset.
+{% endhint %}
+
+{% hint style="info" %}
+ROLE\_ADMIN and ROLE\_DATASET\_MANAGER also have the ability to unmask.
+{% endhint %}
+
+
+
diff --git a/security/configuration/role-based-access-control-rbac.md b/security/configuration/role-based-access-control-rbac.md
new file mode 100644
index 00000000..0aaa9ffb
--- /dev/null
+++ b/security/configuration/role-based-access-control-rbac.md
@@ -0,0 +1,34 @@
+# Role Based Access Control (RBAC)
+
+High-level view of Owl’s Security architecture depicted below.
+
+
+
+Whether leveraging a Local User Store, Active Directory, or using the out of the box user accounts that come with Owl via LDIF, security stays the same. An admin can create many ROLE’s. A user, whether local user, LDIF user, or AD user can be part of one or many roles. And a ROLE maps to a Dataset within Owl.
+
+A unique feature within Owl is the fact that Owl does not store information about external user accounts. This avoids the need to sync external users from an external user store such as AD to owl. Instead Owl will map the external group to an internal role. From here the ROLE can be mapped to the different functionality within Owl whether they are Admins / Users / and have access to different datasets and future functionality. The other benefit is that if a specific userid within the external user store is terminated, when the user is purged from the external user store such as AD they will immediately not have access to Owl’s web application. This is because when the user logs into Owl’s web application that is backed by AD their login will interrogate AD to authenticate the user account. See logical flow below for how the group to role mappings work.
+
+
+
+### RBAC Usages
+
+Owl supports RBAC configuration with both core roles and custom roles. Core roles include the following:
+
+| Role | Access Description |
+| ---------------------------- | --------------------------------------------------------------------------------- |
+| ROLE ADMIN | Modify any access, config settings, connections, role delegation |
+| ROLE DATA GOVERNANCE MANAGER | Ability to manage (create / update / delete) Business Units and Data Concepts |
+| ROLE USER MANAGER | Create / modify users, add users to roles |
+| ROLE OWL ROLE MANAGER | Create roles, edit role mappings to users / AD groups / datasets |
+| ROLE DATASET MANAGER | Create / modify datasets to roles, masking of dataset columns |
+| ROLE OWL CHECK | Only role that can run DQ scans if Owlcheck security is enabled |
+| ROLE DATA PREVIEW | Only role that can view source data if data preview security is enabled |
+| ROLE DATASET TRAIN | Only role that can train datasets if dataset train security is enabled |
+| ROLE DATASET RULES | Only role that can add / edit / delete rules if dataset rules security is enabled |
+| ROLE PUBLIC | Public: Access to scorecards, no dataset access when dataset security is enabled |
+
+Custom roles can be added via the Role Management page by navigating to the Admin Console and clicking on the Roles Icon. Custom roles can also be added 'on the fly' during the Active Directory Role Mapping step.
+
+It is these custom roles that will determine the users that have access to datasets (including profile/rules/data preview/scoring), and database connections
+
+Additional information regarding setting up Dataset and Connection security can be found in those documents respectively.
diff --git a/security/configuration/securing-passwords.md b/security/configuration/securing-passwords.md
new file mode 100644
index 00000000..da5777d8
--- /dev/null
+++ b/security/configuration/securing-passwords.md
@@ -0,0 +1,22 @@
+# Securing Passwords
+
+Security is the utmost importance for Collibra DQ and our customers. In order to not send around plain text passwords when owlchecks are executed from the CLI users/admins can encrypt passwords and execute owlchecks using the encrypted passwords instead of plain text. To encrypt your password execute the command below\
+
+
+| owlmanage.sh encypt=password |
+| ---------------------------- |
+
+The output password will look something like the following\
+
+
+| Q+Ri1S+ljpG+fDefXLY4/vXtUosspAoL |
+| -------------------------------- |
+
+Now you can use this password in any owlcheck from the command line where you would normally place a plain text password. Example owlcheck with encrypted password in place of plain text password highlighted in bold.\
+
+
+| ./owlcheck -q "SELECT id, browser->'$.name' browser FROM events" -c "jdbc:mysql://54.212.36.218:2212/test" -u "owl" -p "Q+Ri1S+ljpG+fDefXLY4/vXtUosspAoL" -driver "com.mysql.cj.jdbc.Driver" -lib "/opt/owl/drivers/mysql8" -ds jsonremotemysql -rd "2019-01-28" |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+
+\
+If executing a DQ Job from within the Owl-web the owl-web will automatically encrypt your password for you -- so you do not have to encrypt it. All passwords are masked out of the logs in order not to store plan passwords for security purposes.
diff --git a/security/configuration/ssl-setup-https.md b/security/configuration/ssl-setup-https.md
new file mode 100644
index 00000000..668fdb6d
--- /dev/null
+++ b/security/configuration/ssl-setup-https.md
@@ -0,0 +1,36 @@
+# SSL Setup (HTTPS)
+
+By Default Collibra DQ has plain HTTP enabled for testing. When you are ready to enable SSL for the web application you can set the following environment variables in owl-env.sh to enable HTTPS.
+
+The settings listed at the bottom of this page will disable un-secure HTTP, enable secure HTTPS, and allow you to point to your certificate key store + credentials. \*A restart of the web-application is required.
+
+Before starting please have an accessible key store.
+
+```
+export SERVER_SSL_KEY_STORE:
+```
+
+You can call Collibra DQ's built in 256-bit encryption for the SERVER\_SSL\_KEY\_PASS value from the bin directory: ./owlmanage.sh encrypt=\
+
+Use the response value instead of the plain text value to secure your password.
+
+```
+export SERVER_SSL_KEY_PASS:
+```
+
+```
+export SERVER_HTTP_ENABLED:false
+export SERVER_HTTPS_ENABLED:true
+export SERVER_REQUIRE_SSL:true
+
+####START KEYSTORE SETTINGS####
+export SERVER_SSL_KEY_TYPE:PKCS12
+#SET PATH TO KEYSTORE
+export SERVER_SSL_KEY_STORE:KeystorePathHere
+export SERVER_SSL_KEY_PASS:*******
+export SERVER_SSL_KEY_ALIAS:keystoreAliasNameHere
+```
+
+Most common SSL types are JKS and PKCS12
+
+\*Dont forget to restart the web application from the bin directory: ./owlmanage.sh restart=owlweb
diff --git a/security/owl-security.md b/security/owl-security.md
new file mode 100644
index 00000000..60fb493f
--- /dev/null
+++ b/security/owl-security.md
@@ -0,0 +1,9 @@
+# Overview
+
+Owl offers multiple methods of user authentication including a local user store and Active Directory or generic LDAP integration.
+
+Security can be configured to meet your needs. Advanced options to segment groups and roles are available. Additionally, options for SAML and SSO are available.
+
+You can control configurations at the Web (UI), Postgres, and Application layers depending on your security requirements. Encryption is available for data in-transit or at-rest.
+
+.png>)
diff --git a/workflows/assignment-queue-s/README.md b/workflows/assignment-queue-s/README.md
new file mode 100644
index 00000000..1bc31ec6
--- /dev/null
+++ b/workflows/assignment-queue-s/README.md
@@ -0,0 +1,19 @@
+# Assignment Queue(s)
+
+
+
+OwlDQ provides observations that usually need review to validate. In many cases, it makes sense to assign the validation to a person that has access to the source data. Assignments can be handled by Owl internally, or an existing ServiceNow or JIRA queue when configured.
+
+When reviewing any observation you will notice a column called "Action
+
+.png>)
+
+From the action dropdown, if you choose to validate a finding, you will also have the ability to assign that item to another Owl user for further investigation
+
+.png>)
+
+If you do not choose an assignee (X), it will mark the item as valid, but unassigned: Acknowledged
+
+Your External Queues are where the source of the assignment should be tracked, OWDQ/JIRA/Serive Now are all options. OWLDQ is automatically configured, but you can configure others via the Admin Console and clicking on Assignment Queues.
+
+.png>)
diff --git a/workflows/assignment-queue-s/external-assignment.md b/workflows/assignment-queue-s/external-assignment.md
new file mode 100644
index 00000000..8f23760e
--- /dev/null
+++ b/workflows/assignment-queue-s/external-assignment.md
@@ -0,0 +1,14 @@
+# External assignment
+
+Collibra DQ has the ability to link to an Assignment Queue. You can assign any item to a user that has previously logged into the application and has a matching Service Now account. Choose the configured queue from the assignment drop-down list after selecting the **Validate** option from the actions drop-down list as previously described.
+
+
+
+{% hint style="warning" %}
+To configure a queue, you must have ROLE\_ADMIN or ROLE\_CONNECTION\_MANAGER.
+{% endhint %}
+
+1. Go to the **Admin Console** and click **Assignment Queues**.\
+ 
+2. **Add** or **Edit** a Service Now configuration from the corresponding page.\
+ 
diff --git a/workflows/assignment-queue-s/faq.md b/workflows/assignment-queue-s/faq.md
new file mode 100644
index 00000000..1c4b89fa
--- /dev/null
+++ b/workflows/assignment-queue-s/faq.md
@@ -0,0 +1,9 @@
+# FAQ
+
+## Can anyone assign an item?
+
+Anyone with access to the dataset and TRAIN role (if enabled) can assign an item. Users who have been assigned an item can resolve without the TRAIN role.
+
+## How do I add people to the assignment list
+
+Once a person logs into the Owl Application they will get a profile and become eligible for assignment.
diff --git a/workflows/assignment-queue-s/internal-assignment.md b/workflows/assignment-queue-s/internal-assignment.md
new file mode 100644
index 00000000..d7c1810b
--- /dev/null
+++ b/workflows/assignment-queue-s/internal-assignment.md
@@ -0,0 +1,5 @@
+# Internal Assignment
+
+Owl has a built in Assignment Queue. You can assign any item to a user that has previously logged into the application. Simply choose OWLDQ from the assignment dropdown after choosing the "validate" option from the actions dropdown as previously described.
+
+
diff --git a/workflows/email-alerts.md b/workflows/email-alerts.md
new file mode 100644
index 00000000..99179e57
--- /dev/null
+++ b/workflows/email-alerts.md
@@ -0,0 +1,46 @@
+# Email Alerts
+
+
+
+### Setting up an Email Server using the WebApp
+
+Navigate to OwlWeb URL. Then click the gear icon on the left in the admin section and click alerts.
+
+
+
+### Creating a Condition to Send an Alert
+
+Also shows some of the common rules associated with this dataset for quick reference while creating. Use the batch name to create a consolidated list of alerts and distribution list for a set of notifications per dataset.
+
+
+
+## DQ Alert in your Inbox
+
+Below is what an alert email that makes it into your inbox will look like. Always smart to make sure your email client didn't mark it as spam and that the SMTP was setup properly. Some email clients automatically strip images therefore we try to keep the emails light on styling and straight to the point.
+
+
+
+## Failed DQ Job Email Alert
+
+There is also a scenario where the DQ job fails to run or has an exception and therefore never gets a chance to score the data or run the alert condition. This is is a FAILED alert.
+
+
+
+## Alert Notifications in Web UI
+
+There are also alert notifications in the web UI. This can be helpful to confirm that the email alerts were sent out and to whom should have received the notifications.
+
+
+
+### Setting up the EmailServer Programmatically
+
+If you are in a notebook or pipeline you may prefer to use the Scala/Spark API to create the Email Server
+
+```scala
+ val emailServer = OwlUtils.createEmailServer("smtp-relay.sendinblue.com", 587)
+ emailServer.setUsername("abc@owl-analytics.com")
+ emailServer.setPassword("abc")
+ emailServer.setCurrentSet(1)
+ Util.EmailServerDaoFactory.delete(emailServer)
+ Util.EmailServerDaoFactory.insert(emailServer)
+```