mirror of
https://github.com/open-metadata/OpenMetadata.git
synced 2025-12-13 00:22:23 +00:00
parent
4491396507
commit
5ad599600e
34
.github/workflows/sync-docs-v1.yml
vendored
34
.github/workflows/sync-docs-v1.yml
vendored
@ -10,7 +10,7 @@
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
name: Sync publish docs v1
|
||||
name: Sync publish docs
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
@ -56,8 +56,38 @@ jobs:
|
||||
commit-message: See ORIGIN_COMMIT from $GITHUB_REF
|
||||
target-branch: publish
|
||||
|
||||
- name: Push content Collate
|
||||
id: push_content_collate
|
||||
continue-on-error: true
|
||||
uses: cpina/github-action-push-to-another-repository@main
|
||||
env:
|
||||
SSH_DEPLOY_KEY: ${{ secrets.DOCS_COLLATE_SSH_DEPLOY_KEY }}
|
||||
with:
|
||||
source-directory: openmetadata-docs/content/v1.5.x
|
||||
target-directory: content/
|
||||
destination-github-username: 'open-metadata'
|
||||
destination-repository-name: 'docs-collate'
|
||||
user-email: collate@getcollate.io
|
||||
commit-message: See ORIGIN_COMMIT from $GITHUB_REF
|
||||
target-branch: main
|
||||
|
||||
- name: Push images Collate
|
||||
id: push_images_collate
|
||||
continue-on-error: true
|
||||
uses: cpina/github-action-push-to-another-repository@main
|
||||
env:
|
||||
SSH_DEPLOY_KEY: ${{ secrets.DOCS_COLLATE_SSH_DEPLOY_KEY }}
|
||||
with:
|
||||
source-directory: openmetadata-docs/images/
|
||||
target-directory: public/images/
|
||||
destination-github-username: 'open-metadata'
|
||||
destination-repository-name: 'docs-collate'
|
||||
user-email: collate@getcollate.io
|
||||
commit-message: See ORIGIN_COMMIT from $GITHUB_REF
|
||||
target-branch: main
|
||||
|
||||
- name: Slack on Failure
|
||||
if: steps.push_content.outcome != 'success'
|
||||
if: ${{ steps.push_content.outcome != 'success' || steps.push_content_collate != 'success' }}
|
||||
uses: slackapi/slack-github-action@v1.23.0
|
||||
with:
|
||||
payload: |
|
||||
|
||||
1801
openmetadata-docs/content/v1.5.x/collate-menu.md
Normal file
1801
openmetadata-docs/content/v1.5.x/collate-menu.md
Normal file
File diff suppressed because it is too large
Load Diff
@ -59,7 +59,7 @@ Mandatory LDAP Specific Configuration:
|
||||
|
||||
- `host`: hostName for the Ldap Server (Ex - localhost).
|
||||
- `port`: port of the Ldap Server to connect to (Ex - 10636).
|
||||
- `dnAdminPrincipal`: This is the DN Admin Principal(Complete path Example :- cn=admin,dc=example,dc=com ) with a lookup access in the Directory.
|
||||
- `dnAdminPrincipal`: This is the DN Admin Principal(Complete path Example :- cn=admin,dc=example,dc=com) with a lookup access in the Directory.
|
||||
- `dnAdminPassword`: Above Admin Principal Password.
|
||||
- `userBaseDN`: User Base DN(Complete path Example :- ou=people,dc=example,dc=com).
|
||||
|
||||
|
||||
@ -0,0 +1,70 @@
|
||||
---
|
||||
title: Amazon Cognito SSO
|
||||
slug: /security/amazon-cognito
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Amazon Cognito SSO
|
||||
|
||||
Follow the sections in this guide to set up Amazon Cognito SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Amazon Cognito SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is
|
||||
enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Login to AWS Portal
|
||||
|
||||
- Login to [Amazon AWS Portal](https://aws.amazon.com/).
|
||||
- Search for `Cognito` in the search box and select Cognito Service from the dropdown menu.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-1.png" alt="create-account" caption="Search for Cognito" /%}
|
||||
|
||||
### Step 2: Setup User Pool
|
||||
|
||||
- Click on the "Create user pool" button if you do not have any user pools configured yet. Skip this step if you already have a user pool available.
|
||||
- Select the type of ID providers you want to configure for your users and click "Next"
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-2.png" alt="create-account" caption="Setup User Pool" /%}
|
||||
|
||||
- Configure the security requirements in Step 2 as per your organizational needs and proceed to Step 3
|
||||
- Configure the Sign-up experience in Step 3. Make sure to add email as a required attribute before proceeding to step 4
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-3.png" alt="create-account" caption="Configure Sign up Experience" /%}
|
||||
|
||||
- Configure message delivery as per your organizational needs and proceed to Step 5
|
||||
- In Step 5, add a name for the user pool and check the "Use the Cognito Hosted UI" option and provide a Cognito domain as shown in the screenshot below
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-4.png" alt="create-account" caption="Integrate your App" /%}
|
||||
|
||||
- In the same step, select "Public client" for the Initial App client type and configure the Allowed callback URLs
|
||||
with `http://localhost:8585/callback` as shown in the screenshot below. Note: For production deployments, the Allowed
|
||||
callback URLs should be updated with the appropriate domain name.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-5.png" alt="create-account" caption="Configure the App Client" /%}
|
||||
|
||||
- The last step is to Review and create the User Pool.
|
||||
|
||||
### Step 3: Where to find the Credentials
|
||||
|
||||
- The `User Pool ID` can be found in the User Pool summary page as seen in the screenshot below
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-6.png" alt="create-account" caption="User Pool ID" /%}
|
||||
|
||||
- The App client ID can be found under the "App Integration" tab of the User Pool page. There will be a section that
|
||||
lists all the App clients with client name and client ID as shown below
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-7.png" alt="create-account" /%}
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/amazon-cognito-sso/create-server-credentials-8.png" alt="create-account" caption="Client ID" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
- User Pool ID
|
||||
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Auth0 SSO
|
||||
slug: /security/auth0
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Auth0 SSO
|
||||
|
||||
Follow the sections in this guide to set up Auth0 SSO.
|
||||
|
||||
{%important%}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Auth0 SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{%/important%}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Create the Account
|
||||
|
||||
- If you don't have an account, [Sign up](https://auth0.com/signup) to create one.
|
||||
- Select the Account Type, i.e., Company or Personal
|
||||
- Click I need advanced settings and click next.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/create-account-1.png"
|
||||
alt="create-account" /%}
|
||||
|
||||
- Provide the Tenant Domain, select the region and click on Create Account.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/create-account-2.png"
|
||||
alt="create-account" /%}
|
||||
|
||||
- Once done, you will land on the dashboard page.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/create-account-3.png"
|
||||
alt="create-account" /%}
|
||||
|
||||
### Step 2: Create a New Application
|
||||
|
||||
- Once you are on the Dashboard page, click on `Applications > Applications` available on the left-hand side panel.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/create-new-app-1.png"
|
||||
alt="create-app" /%}
|
||||
|
||||
- Click on `Create Application`.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/create-new-app-2.png"
|
||||
alt="create-app" /%}
|
||||
|
||||
- Enter the Application name.
|
||||
- Choose an application type and click on `Create`.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/create-new-app-3.png"
|
||||
alt="create-app" /%}
|
||||
|
||||
### Step 3: Where to Find the Credentials
|
||||
|
||||
- Navigate to the Settings tab.
|
||||
- You will find your `Client ID` and `Domain`.
|
||||
|
||||
{% image
|
||||
src="/images/v1.5/deployment/security/auth0/credentials.png"
|
||||
alt="credentials" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
- Domain
|
||||
@ -0,0 +1,80 @@
|
||||
---
|
||||
title: Azure SSO
|
||||
slug: /security/azure
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Azure SSO
|
||||
|
||||
Follow the sections in this guide to set up Azure SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Azure SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Login to Azure Active Directory
|
||||
|
||||
- Login to [Microsoft Azure Portal](https://azure.microsoft.com/en-in/services/active-directory/external-identities/)
|
||||
- Navigate to the Azure Active Directory.
|
||||
|
||||
{% note %}
|
||||
|
||||
Admin permissions are required to register the application on the Azure portal.
|
||||
|
||||
{% /note %}
|
||||
|
||||
### Step 2: Create a New Application
|
||||
|
||||
- From the Azure Active Directory, navigate to the `App Registrations` section from the left nav bar.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/azure/create-app-1.png" alt="create-app" /%}
|
||||
|
||||
- Click on `New Registration`. This step is for registering the OpenMetadata UI.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/azure/create-app-2.png" alt="create-app" /%}
|
||||
|
||||
- Provide an Application Name for registration.
|
||||
- Provide a redirect URL as a `Single Page Application`.
|
||||
- Click on `Register`.
|
||||
|
||||
{% note %}
|
||||
|
||||
- **SPA (Single Page Application):**
|
||||
This type is designed for implicit flows. In this case, providing both the client ID and client secret will result in a failure because the implicit flow only requires the client ID for authentication.
|
||||
|
||||
- **Web:**
|
||||
This type is intended for confidential clients. If you select this option, you must provide both the client ID and client secret. Simply passing the client ID will cause the authorization process to fail, as the Authorization Code flow requires both credentials for successful authentication.
|
||||
|
||||
### Recommendation:
|
||||
|
||||
- Use the **Web** type for confidential clients that require both a client ID and secret.
|
||||
- Use the **SPA** type for applications using implicit flows where only a client ID is needed.
|
||||
|
||||
{% /note %}
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/azure/create-app-3.png" alt="create-app" /%}
|
||||
|
||||
### Step 3: Where to Find the Credentials
|
||||
|
||||
- The `Client ID` and the `Tenant ID` are displayed in the Overview section of the registered application.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/azure/where-to-find-credentials.png" alt="create-app" /%}
|
||||
|
||||
- When passing the details for `authority`, the `Tenant ID` is added to the URL as shown in the example
|
||||
below. `https://login.microsoftonline.com/TenantID`
|
||||
|
||||
```commandline
|
||||
"authority": "https://login.microsoftonline.com/c11234b7c-b1b2-9854-0mn1-56abh3dea295"
|
||||
```
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
- Tenant ID
|
||||
@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Custom OIDC SSO
|
||||
slug: /security/custom-oidc
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Custom OIDC SSO
|
||||
|
||||
Follow the sections in this guide to set up Custom OIDC SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Custom OIDC SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
- Go to the console of your preferred custom OIDC SSO provider
|
||||
- Create an OIDC client application with implicit flow enabled to get a client ID.
|
||||
|
||||
### Create Client ID and Secret Key
|
||||
|
||||
- Navigate to your preferred OIDC provider console and create an OIDC client application.
|
||||
- Generate client ID and secret key in JSON format.
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
@ -0,0 +1,87 @@
|
||||
---
|
||||
title: Google SSO
|
||||
slug: /security/google
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Google SSO
|
||||
|
||||
Follow the sections in this guide to set up Google SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Google SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Create the Account
|
||||
- Go to [Create Google Cloud Account](https://console.cloud.google.com/)
|
||||
- Click on `Create Project`
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/google/create-account.png" alt="create-account" caption="Create a New Account" /%}
|
||||
|
||||
### Step 2: Create a New Project
|
||||
Enter the **Project name**.
|
||||
Enter the parent organization or folder in the **Location box**. That resource will be the hierarchical parent of the new project.
|
||||
Click **Create**.
|
||||
{% image src="/images/v1.5/deployment/security/google/create-project.png" alt="create-project" caption="Create a New Project" /%}
|
||||
|
||||
### Step 3: How to Configure OAuth Consent
|
||||
- Select the project you created above and click on **APIs & Services** on the left-side panel.
|
||||
{% image src="/images/v1.5/deployment/security/google/configure-oauth-consent.png" alt="configure-oauth-consent" /%}
|
||||
|
||||
- Click on the **OAuth Consent Screen** available on the left-hand side panel.
|
||||
- Choose User Type **Internal**.
|
||||
{% image src="/images/v1.5/deployment/security/google/select-user-type.png" alt="select-user-type" /%}
|
||||
|
||||
- Once the user type is selected, provide the **App Information** and other details.
|
||||
- Click **Save and Continue**.
|
||||
{% image src="/images/v1.5/deployment/security/google/save-app-information.png" alt="save-app-information" /%}
|
||||
|
||||
- On the **Scopes Screen**, Click on **ADD OR REMOVE SCOPES** and select the scopes.
|
||||
- Once done click on **Update**.
|
||||
{% image src="/images/v1.5/deployment/security/google/scopes-screen.png" alt="scopes-screen" /%}
|
||||
|
||||
- Click **Save and Continue**.
|
||||
{% image src="/images/v1.5/deployment/security/google/save-edit-app-registration.png" alt="save-edit-app-registration" /%}
|
||||
|
||||
- Click on **Back to Dashboard**.
|
||||
{% image src="/images/v1.5/deployment/security/google/back-to-dashboard.png" alt="back-to-dashboard" /%}
|
||||
{% image src="/images/v1.5/deployment/security/google/back-to-dashboard-2.png" alt="back-to-dashboard" /%}
|
||||
|
||||
### Step 4: Create Credentials for the Project
|
||||
- Once the OAuth Consent is configured, click on **Credentials** available on the left-hand side panel.
|
||||
{% image src="/images/v1.5/deployment/security/google/create-credentials.png" alt="create-credentials" /%}
|
||||
|
||||
- Click on **Create Credentials**
|
||||
- Select **OAuth client ID** from the dropdown.
|
||||
{% image src="/images/v1.5/deployment/security/google/select-outh-client-id.png" alt="cselect-outh-client-id" /%}
|
||||
|
||||
- Once selected, you will be asked to select the **Application type**. Select **Web application**.
|
||||
{% image src="/images/v1.5/deployment/security/google/select-web-application.png" alt="select-web-application" /%}
|
||||
|
||||
After selecting the **Application Type**, name your project and give the authorized URIs:
|
||||
- domain/callback
|
||||
- domain/silent-callback
|
||||
{% image src="/images/v1.5/deployment/security/google/authorized-urls.png" alt="authorized-urls" /%}
|
||||
|
||||
- Click **Create**
|
||||
- You will get the credentials
|
||||
{% image src="/images/v1.5/deployment/security/google/get-the-credentials.png" alt="get-the-credentials" /%}
|
||||
|
||||
### Step 5: Where to Find the Credentials
|
||||
- Go to **Credentials**
|
||||
- Click on the **pencil icon (Edit OAuth Client)** on the right side of the screen
|
||||
{% image src="/images/v1.5/deployment/security/google/find-credentials.png" alt="find-credentials" /%}
|
||||
|
||||
- You will find the **Client ID** in the top right corner
|
||||
{% image src="/images/v1.5/deployment/security/google/find-clientid-and-secret.png" alt="find-clientid-and-secret" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
76
openmetadata-docs/content/v1.5.x/security-collate/index.md
Normal file
76
openmetadata-docs/content/v1.5.x/security-collate/index.md
Normal file
@ -0,0 +1,76 @@
|
||||
---
|
||||
title: Enable Security
|
||||
slug: /security
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Enable Security
|
||||
|
||||
This section provides detailed instructions to secure the access to the Collate platform.
|
||||
|
||||
Collate has support for multiple identity providers. Please, see the next sections about how to configure them.
|
||||
|
||||
{% note %}
|
||||
|
||||
Collate does not currently support the simultaneous use of multiple authentication mechanisms, such as combining SSO and Basic Authentication.
|
||||
|
||||
{% /note %}
|
||||
|
||||
{%inlineCalloutContainer%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Auth0 SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/auth0"%}
|
||||
Configure Auth0 SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Azure SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/azure"%}
|
||||
Configure Azure SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Custom OIDC SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/custom-oidc"%}
|
||||
Configure a Custom OIDC SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Google SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/google"%}
|
||||
Configure Google SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Okta SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/okta"%}
|
||||
Configure Okta SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Amazon Cognito SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/amazon-cognito"%}
|
||||
Configure Amazon Cognito SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="OneLogin SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/one-login"%}
|
||||
Configure OneLogin SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Keycloak SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/keycloak"%}
|
||||
Configure Keycloak SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%/inlineCalloutContainer%}
|
||||
@ -0,0 +1,73 @@
|
||||
---
|
||||
title: Keycloak SSO
|
||||
slug: /security/keycloak
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Keycloak SSO
|
||||
|
||||
Follow the sections in this guide to set up Keycloak SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Keycloak SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Access the Keycloak Admin Console
|
||||
|
||||
- You need an administrator account. If you don't have, see [Creating the first administrator](https://www.keycloak.org/docs/latest/server_admin/#creating-first-admin_server_administration_guide).
|
||||
- Go to the URL for the Admin Console. For example, for localhost, use this URL: http://localhost:8080/admin/
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/keycloak/1-login-page.png" alt="login-page" /%}
|
||||
|
||||
- Enter the username and password you created.
|
||||
|
||||
### Step 2: Change Realm selected
|
||||
- The Keycloak use Realms as the primary form of organization, we can't use the realm "master" for new clients (apps), only for administration, so change for your specific realm or create a new.
|
||||
- In this example we are used an existing one called "Data-sec".
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/keycloak/2-change-realm.png" alt="change-realm" /%}
|
||||
|
||||
### Step 3: Create OpenMetadata as a new Client
|
||||
- Click on `Clients` in the menu.
|
||||
- Click on `Create` button.
|
||||
- Enter the Client ID and Protocol as the image.
|
||||
- Click on `Save` button.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/keycloak/3-add-client.png" alt="add-client" /%}
|
||||
|
||||
### Step 4: Edit settings of the client
|
||||
- Change "Access Type" value from "public" to "confidential".
|
||||
- Change "implicit flow" and "service accounts" to enabled.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/keycloak/4-edit-settings-client.png" alt="edit-settings-client" /%}
|
||||
|
||||
- At the bottom of the same settings page, change the configurations to the openmetadata address.
|
||||
- The image below shows different possibilities, such as running locally or with a custom domain.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/keycloak/5-edit-settings-url.png" alt="edit-settings-url.png" /%}
|
||||
|
||||
- Click on `Save` button.
|
||||
|
||||
{% note %}
|
||||
|
||||
Note: Scopes `openid`, `email` & `profile` are required to fetch the user details so you will have to add these scopes in your client.
|
||||
|
||||
{% /note %}
|
||||
|
||||
### Step 5: Where to Find the Credentials
|
||||
|
||||
- Navigate to the `Credentials` tab.
|
||||
- You will find your Client `Secret` related to the Client id "open-metadata"
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/keycloak/6-client-credentials.png" alt="client-credentials" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Ldap Authentication
|
||||
slug: /security/ldap
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Setting up Ldap Authentication
|
||||
{%important%}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Auth0 SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{%important%}
|
||||
|
||||
OpenMetadata allows using LDAP for validating email and password authentication.
|
||||
Once setup successfully, the user should be able to sign in to OpenMetadata using the Ldap credentials.
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- `host`: hostName for the Ldap Server (Ex - localhost).
|
||||
- `port`: port of the Ldap Server to connect to (Ex - 10636).
|
||||
- `dnAdminPrincipal`: This is the DN Admin Principal(Complete path Example :- cn=admin,dc=example,dc=com) with a lookup access in the Directory.
|
||||
- `dnAdminPassword`: Above Admin Principal Password.
|
||||
- `userBaseDN`: User Base DN(Complete path Example :- ou=people,dc=example,dc=com).
|
||||
|
||||
Please see the below image for a sample LDAP Configuration in ApacheDS.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/ldap/Ldap_ScreenShot1.png" alt="apache-ldap" /%}
|
||||
|
||||
Advanced LDAP Specific Configuration (Optional):
|
||||
|
||||
- `maxPoolSize`: Connection Pool Size to use to connect to LDAP Server.
|
||||
- `sslEnabled`: Set to true if the SSL is enable to connect to LDAP Server.
|
||||
- `truststoreConfigType`: Truststore type. It is required. Can select from {CustomTrustStore, HostName, JVMDefault, TrustAll}
|
||||
- `trustStoreConfig`: Config for the selected truststore type. Please check below note for setting this up.
|
||||
|
||||
{%note%}
|
||||
|
||||
Based on the different `truststoreConfigType`, we have following different `trustStoreConfig`.
|
||||
|
||||
1. **TrustAll**: Provides an SSL trust manager which will blindly trust any certificate that is presented to it, although it may optionally reject certificates that are expired or not yet valid. It can be convenient for testing purposes, but it is recommended that production environments use trust managers that perform stronger validation.
|
||||
- `examineValidityDates`: Indicates whether to reject certificates if the current time is outside the validity window for the certificate.
|
||||
|
||||
2. **JVMDefault**: Provides an implementation of a trust manager that relies on the JVM's default set of trusted issuers.
|
||||
- `verifyHostname`: Controls using TrustAllSSLSocketVerifier vs HostNameSSLSocketVerifier. In case the certificate contains cn=hostname of the Ldap Server set it to true.
|
||||
|
||||
3. **HostName**: Provides an SSL trust manager that will only accept certificates whose hostname matches an expected value.
|
||||
- `allowWildCards`: Indicates whether to allow wildcard certificates which contain an asterisk as the first component of a CN subject attribute or dNSName subjectAltName extension.
|
||||
- `acceptableHostNames`: The set of hostnames and/or IP addresses that will be considered acceptable. Only certificates with a CN or subjectAltName value that exactly matches one of these names (ignoring differences in capitalization) will be considered acceptable. It must not be null or empty.
|
||||
|
||||
4. **CustomTrustStore**: Use the custom Truststore by providing the below details in the config.
|
||||
- `trustStoreFilePath`: The path to the trust store file to use. It must not be null.
|
||||
- `trustStoreFilePassword`: The PIN to use to access the contents of the trust store. It may be null if no PIN is required.
|
||||
- `trustStoreFileFormat`: The format to use for the trust store. (Example :- JKS, PKCS12).
|
||||
- `verifyHostname`: Controls using TrustAllSSLSocketVerifier vs HostNameSSLSocketVerifier. In case the certificate contains cn=hostname of the Ldap Server set it to true.
|
||||
- `examineValidityDates`: Indicates whether to reject certificates if the current time is outside the validity window for the certificate.
|
||||
|
||||
{%/note%}
|
||||
153
openmetadata-docs/content/v1.5.x/security-collate/oidc/index.md
Normal file
153
openmetadata-docs/content/v1.5.x/security-collate/oidc/index.md
Normal file
@ -0,0 +1,153 @@
|
||||
---
|
||||
title: OIDC Based Authentication
|
||||
slug: /security/oidc
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Setting up Any Oidc Provider
|
||||
{%important%}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Auth0 SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{%important%}
|
||||
|
||||
This guide provides instructions on setting up OpenID Connect (OIDC) configuration for your application. OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol that allows clients to verify the identity of the end-user.
|
||||
Below configurations are universally applicable to all SSO provider like Google, Auth0, Okta, Keycloak, etc.
|
||||
|
||||
Below are the configuration types to set up the OIDC Authentication with a Confidential Client type:
|
||||
|
||||
```yaml
|
||||
authenticationConfiguration:
|
||||
clientType: ${AUTHENTICATION_CLIENT_TYPE:-confidential}
|
||||
publicKeyUrls: ${AUTHENTICATION_PUBLIC_KEYS:-[http://localhost:8585/api/v1/system/config/jwks]}
|
||||
oidcConfiguration:
|
||||
id: ${OIDC_CLIENT_ID:-""}
|
||||
type: ${OIDC_TYPE:-""} # google, azure etc.
|
||||
secret: ${OIDC_CLIENT_SECRET:-""}
|
||||
scope: ${OIDC_SCOPE:-"openid email profile"}
|
||||
discoveryUri: ${OIDC_DISCOVERY_URI:-""}
|
||||
useNonce: ${OIDC_USE_NONCE:-true}
|
||||
preferredJwsAlgorithm: ${OIDC_PREFERRED_JWS:-"RS256"}
|
||||
responseType: ${OIDC_RESPONSE_TYPE:-"code"}
|
||||
disablePkce: ${OIDC_DISABLE_PKCE:-true}
|
||||
callbackUrl: ${OIDC_CALLBACK:-"http://localhost:8585/callback"}
|
||||
serverUrl: ${OIDC_SERVER_URL:-"http://localhost:8585"}
|
||||
clientAuthenticationMethod: ${OIDC_CLIENT_AUTH_METHOD:-"client_secret_post"}
|
||||
tenant: ${OIDC_TENANT:-""}
|
||||
maxClockSkew: ${OIDC_MAX_CLOCK_SKEW:-""}
|
||||
customParams: ${OIDC_CUSTOM_PARAMS:-}
|
||||
```
|
||||
# Configuration Parameters
|
||||
|
||||
## Public Key Url (publicKeyUrls):
|
||||
This needs to be updated as per different SSO providers. The default value is `http://localhost:8585/api/v1/system/config/jwks`. This is the URL where the public keys are stored. The public keys are used to verify the signature of the JWT token.
|
||||
|
||||
{%important%}
|
||||
|
||||
**Google**: https://www.googleapis.com/oauth2/v3/certs
|
||||
|
||||
**Okta**: https://dev-19259000.okta.com/oauth2/aus5836ihy7o8ivuJ5d7/v1/keys
|
||||
|
||||
**Auth0**: https://dev-3e0nwcqx.us.auth0.com/.well-known/jwks.json
|
||||
|
||||
**Azure**: https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys
|
||||
|
||||
Also if you have enabled [JWT Tokens](/deployment/security/enable-jwt-tokens) then http://localhost:8585/api/v1/system/config/jwks also needs to be there in the list with proper server url.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Client ID (id):
|
||||
The client ID provided by your OIDC provider. This is typically obtained when you register your application with the OIDC provider.
|
||||
|
||||
## Type (type):
|
||||
Specify the type of OIDC provider you are using (e.g., google, azure). This value is same as `provider` in `authenticationConfiguration`.
|
||||
|
||||
## Client Secret (secret):
|
||||
Replace with the client secret provided by your OIDC provider.
|
||||
|
||||
## Scope (scope):
|
||||
Define the scopes that your application requests during authentication. Update ${OIDC_SCOPE:-"openid email profile"} with the desired scopes.
|
||||
|
||||
{% note %}
|
||||
|
||||
It does not need to be changed in most cases. The default scopes are `openid email profile`. The openid scope is required for OIDC authentication. The email and profile scopes are used to retrieve the user's email address and profile information.
|
||||
Although, some provider only give Refresh Token if `offline_access` scope is provided. So, if you want to use Refresh Token, you need to add `offline_access` scope, like below:
|
||||
`offline_access openid email profile`.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Discovery URI (discoveryUri):
|
||||
Provide the URL of the OIDC provider's discovery document. This document contains metadata about the provider's configuration.
|
||||
|
||||
{%important%}
|
||||
|
||||
It is mostly in the format as below: https://accounts.google.com/.well-known/openid-configuration
|
||||
|
||||
**Google**: https://accounts.google.com/.well-known/openid-configuration
|
||||
|
||||
**Okta**: https://dev-19259000.okta.com/oauth2/aus5836ihy7o8ivuJ5d7/.well-known/openid-configuration
|
||||
|
||||
**Auth0**: https://dev-3e0nwcqx.us.auth0.com/.well-known/openid-configuration
|
||||
|
||||
**Azure**: https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
|
||||
|
||||
Normally it's some initial SSO provider URL followed by `.well-known/openid-configuration`
|
||||
|
||||
{%important%}
|
||||
|
||||
## Use Nonce (useNonce):
|
||||
Set to true by Default, if you want to use nonce for replay attack protection during authentication. This does not need to be changed.
|
||||
|
||||
## Preferred JWS Algorithm (preferredJwsAlgorithm):
|
||||
Specify the preferred JSON Web Signature (JWS) algorithm. Default is RS256 and need not be changed .
|
||||
|
||||
## Response Type (responseType):
|
||||
Define the response type for the authentication request. Default is code and need not be changed.
|
||||
|
||||
## Disable PKCE (disablePkce):
|
||||
Set ${OIDC_DISABLE_PKCE:-true} to true if you want to disable Proof Key for Code Exchange (PKCE). If you want to send CodeVerifier and CodeChallenge in the request, set it to false.
|
||||
|
||||
## Callback URL (callbackUrl):
|
||||
Provide the callback URL where the OIDC provider redirects after authentication. Update ${OIDC_CALLBACK:-"http://localhost:8585/callback"} with your actual callback URL.
|
||||
|
||||
{%important%}
|
||||
|
||||
The only initial part of the URL should be changed, the rest of the URL should be the same as the default one. The default URL is `http://localhost:8585/callback`.
|
||||
Also, this should match what you have configured in your OIDC provider.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Server URL (serverUrl):
|
||||
Specify the URL of your OM Server. Default is http://localhost:8585.
|
||||
|
||||
## Client Authentication Method (clientAuthenticationMethod):
|
||||
Define the method used for client authentication. Default is client_secret_post.
|
||||
|
||||
{%important%}
|
||||
|
||||
This does not need to be changed in most cases. The default value is `client_secret_post`.
|
||||
This method is used to send the client ID and client secret in the request body.
|
||||
Another possible value is `client_secret_basic`, which sends the client ID and client secret in the Authorization header.
|
||||
Depending on the OIDC provider, you may need to change this value if only one of them is supported.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Tenant (tenant):
|
||||
If applicable, specify the tenant ID for multi-tenant applications. Example in case of Azure.
|
||||
|
||||
{%important%}
|
||||
|
||||
This is only applicable for multi-tenant applications. If you are using a single tenant application, you can leave this field empty.
|
||||
For Azure SSO Provider this may be needed.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Max Clock Skew (maxClockSkew):
|
||||
Define the maximum acceptable clock skew between your application server and the OIDC server.
|
||||
|
||||
## Custom Parameters (customParams):
|
||||
If you have any additional custom parameters required for OIDC configuration, specify them here.
|
||||
141
openmetadata-docs/content/v1.5.x/security-collate/okta/index.md
Normal file
141
openmetadata-docs/content/v1.5.x/security-collate/okta/index.md
Normal file
@ -0,0 +1,141 @@
|
||||
---
|
||||
title: Okta SSO
|
||||
slug: /security/okta
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Okta SSO
|
||||
|
||||
Follow the sections in this guide to set up Okta SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Okta SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
This document will explain how to create an Okta app and configure it for OAuth. This will generate the information required for Single Sign On with Okta.
|
||||
|
||||
### Step 1: Create an Okta Account
|
||||
- Go to [Create Okta Account](https://developer.okta.com/signup/).
|
||||
- Provide the required input and click on Sign Up.
|
||||
- Else you can continue with Google or GitHub.
|
||||
|
||||
### Step 2: Create the OIDC App Integration.
|
||||
- Once done with **Signup/Sign** in, you will be redirected to the **Getting Started** page in Okta.
|
||||
{% image src="/images/v1.5/deployment/security/okta/create-oidc-app-integration.png" alt="create-oidc-app-integration" /%}
|
||||
|
||||
- Click on **Applications -> Applications** in the left navigation panel.
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-applications.png" alt="click-applications" /%}
|
||||
|
||||
- Click on the **Create App Integration** button.
|
||||
{% image src="/images/v1.5/deployment/security/okta/create-app-integration.png" alt="create-app-integration" /%}
|
||||
|
||||
### Step 3: Configuring the App
|
||||
- Once you are in the **Create a new app integration** page, select **OIDC - OpenID Connect**.
|
||||
- Next, select the **Application type -> Single-Page Application**.
|
||||
- Once selected, click **Next**.
|
||||
{% image src="/images/v1.5/deployment/security/okta/configuring-the-app.png" alt="configuring-the-app" /%}
|
||||
|
||||
- From the **General Settings** page,
|
||||
* Enter an **App integration name**
|
||||
* Select the following in **Grant type**:
|
||||
* **Authorization Code**
|
||||
* **Refresh Token** - For the refresh token behavior, it is recommended to select the option to 'Rotate token after every use'.
|
||||
* **Implicit (hybrid)** - Select the options to allow ID Token and Access Token with implicit grant type.
|
||||
* Enter the **Sign-in redirect URIs**
|
||||
* http://localhost:8585/callback
|
||||
* http://localhost:8585/silent-callback
|
||||
* Enter the **Sign-out redirect URIs**
|
||||
* Enter the **Base URIs**
|
||||
* Select the required option for **Controlled access**
|
||||
- Click **Save**.
|
||||
{% image src="/images/v1.5/deployment/security/okta/general-settings-click-save.png" alt="general-settings-click-save" /%}
|
||||
|
||||
- The app is now configured.
|
||||
{% image src="/images/v1.5/deployment/security/okta/app-is-configured.png" alt="app-is-configured" /%}
|
||||
|
||||
### Step 4: Add Authorization Server to get the Issuer URL
|
||||
#### New Authorization Server
|
||||
It is recommended to create a separate authorization server for different applications. The authorization server needs an endpoint, which'll be the Issuer URL.
|
||||
- Click on **Security -> API** in the left navigation panel.
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-security-api.png" alt="click-security-api" /%}
|
||||
|
||||
- From the **Authorization Servers** tab, click on **Add Authorization Server** button.
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-add-authorization-server.png" alt="click-add-authorization-server" /%}
|
||||
|
||||
- Enter a Name and Description.
|
||||
- While creating the authorization server, an **Audience** must be provided for the server. The Audience is the **Client ID** of the single page application that was created. Refer the next Step 7 to locate the Client ID.
|
||||
- **Save** the changes.
|
||||
{% image src="/images/v1.5/deployment/security/okta/add-auth-server-save-changes.png" alt="add-auth-server-save-changes" /%}
|
||||
|
||||
This will generate the Issuer URL.
|
||||
#### Default Authorization Server (not recommended )
|
||||
It is recommended to create a separate authorization server for different applications. The authorization server needs an endpoint, which'll be the Issuer URL.
|
||||
- Click on **Security -> API** in the left navigation panel.
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-security-api.png" alt="click-security-api" /%}
|
||||
|
||||
- From the **Authorization Servers** tab, click on **default** server.
|
||||
{% image src="/images/v1.5/deployment/security/okta/default-server.png" alt="default-server" /%}
|
||||
|
||||
|
||||
### Step 5: Change the Issuer URL from Dynamic to Okta URL
|
||||
Once the Authorization Server has been added, navigate to Security >> API >> Authorization Servers and click on the authorization server created in the previous step.
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-auth-server-from-prev-step.png" alt="click-auth-server-from-prev-step" /%}
|
||||
|
||||
The Issuer URL shows up as Dynamic by default. Change the Issuer URL to Okta URL and save the changes.
|
||||
{% image src="/images/v1.5/deployment/security/okta/change-issuer-url.png" alt="change-issuer-url" /%}
|
||||
|
||||
### Step 6: Create a Default Scope
|
||||
- To create a default scope from **Security -> API**, click on the required **Authorization Server**.
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-req-auth-server.png" alt="click-req-auth-server" /%}
|
||||
|
||||
- In the resulting page, click on the **Scopes** tab
|
||||
- Click on **Add Scope**
|
||||
{% image src="/images/v1.5/deployment/security/okta/add-scope.png" alt="add-scope" /%}
|
||||
|
||||
- Set as a **Default Scope**.
|
||||
{% image src="/images/v1.5/deployment/security/okta/set-default-scope.png" alt="set-default-scope" /%}
|
||||
|
||||
### Step 7: Add New Access Policy and Rule
|
||||
- From **Security -> API**, click on the required **Authorization Server**
|
||||
- Navigate to the **Access Policies Tab**
|
||||
- Click on **Add New Access Policy**
|
||||
{% image src="/images/v1.5/deployment/security/okta/add-new-access-policy.png" alt="add-new-access-policy" /%}
|
||||
|
||||
- To create a policy, add a Name and Description.
|
||||
- Assign the policy to the required clients.
|
||||
{% image src="/images/v1.5/deployment/security/okta/assign-policy.png" alt="" /%}
|
||||
|
||||
- Add a new **Rule** inside the policy as required. Rules can be created with just a few grant type details, such as Client Credentials, Authorization Code, Device Authorization, and Token Exchange.
|
||||
- Click on **Create Rule** to save the changes.
|
||||
{% image src="/images/v1.5/deployment/security/okta/add-rule.png" alt="add-rule" /%}
|
||||
|
||||
### Step 8: Where to Find the Credentials
|
||||
- Once the app is configured, the **Client ID** can be used.
|
||||
- You can also go to **Application -> Application** as in step 2.
|
||||
- You should be able to see your application in the list.
|
||||
{% image src="/images/v1.5/deployment/security/okta/see-your-application.png" alt="see-your-application" /%}
|
||||
|
||||
- Click on your application.
|
||||
- You will find your **Client ID** and **Okta domain**.
|
||||
- The **Client authentication** is enabled by default.
|
||||
- By clicking on the Edit **** option for General Settings, you can deselect the option for **User consent**. Save the changes.
|
||||
{% image src="/images/v1.5/deployment/security/okta/deselect-user-consent.png" alt="deselect-user-consent" /%}
|
||||
|
||||
- Click on the **Sign On** tab from the top navigation bar.
|
||||
- Click on Edit for **OpenID Connect ID Token**.
|
||||
- For **Issuer**, change from the Dynamic (based on request domain) option to the **Okta URL** option.
|
||||
- The **Audience** is the same as the Client ID.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/okta/click-edit-token.png" alt="click-edit-token" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Issuer URL
|
||||
- Client ID
|
||||
@ -0,0 +1,57 @@
|
||||
---
|
||||
title: OneLogin SSO
|
||||
slug: /security/one-login
|
||||
collate: true
|
||||
---
|
||||
|
||||
# OneLogin SSO
|
||||
|
||||
Follow the sections in this guide to set up OneLogin SSO.
|
||||
|
||||
{% note %}
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with OneLogin SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Configure a new Application
|
||||
|
||||
- Login to [OneLogin](https://www.onelogin.com/) as an administrator and click on Applications
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-1.png" alt="create-account" /%}
|
||||
|
||||
- Click on the `Add App` button and search for `openid connect`
|
||||
- Select the `OpenId Connect (OIDC)` app
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-2.png" alt="create-account" /%}
|
||||
|
||||
- Change the Display Name of the app to `Open Metadata` and click `Save`
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-3.png" alt="create-account" /%}
|
||||
|
||||
- Configure the login Url (`http(s)://<domain>/signin`) and redirect URI (`http(s)://<domain>/callback`) as shown below
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-4.png" alt="create-account" /%}
|
||||
|
||||
- Configure the users in the organization that can access OpenMetadata app by clicking on the `Users`
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-5.png" alt="create-account" /%}
|
||||
|
||||
- Click on "SSO" and select `None (PKCE)` for Token Endpoint.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-6.png" alt="create-account" /%}
|
||||
|
||||
### Step 2: Where to find the Credentials
|
||||
|
||||
- Go to "SSO" and copy the Client ID
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/one-login/create-server-credentials-7.png" alt="create-account" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Issuer URL
|
||||
- Client ID
|
||||
@ -0,0 +1,53 @@
|
||||
---
|
||||
title: SAML AWS SSO
|
||||
slug: /security/saml/aws
|
||||
collate: true
|
||||
---
|
||||
|
||||
# SAML AWS SSO
|
||||
|
||||
Follow the sections in this guide to set up AWS SSO using SAML.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create OpenMetadata application
|
||||
|
||||
### Step 1: Configure a new Application in AWS Console
|
||||
|
||||
- Login to [AWS Console](https://aws.amazon.com/console/) as an administrator and search for IAM Identity Center.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-1.png" alt="IAM-Identity-Center" /%}
|
||||
|
||||
- Click on `Choose your identity source` and configure as per security requirements.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-2.png" alt="identity-source" /%}
|
||||
|
||||
- After identity source is set up successfully, goto step 2 and click on `Manage Access to application` and add all the required users who need access to application.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-3.png" alt="manage-access" /%}
|
||||
|
||||
- Click on `Set up Identity Center enabled applications`, and click `Add application`, and select `Add custom SAML 2.0 application`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-4.png" alt="saml-application" /%}
|
||||
|
||||
- Set Display Name to `OpenMetadata` , and download the metadata xml file and save it someplace safe, it is needed to setup OM Server
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-5.png" alt="metadata-xml" /%}
|
||||
|
||||
- Click on `Manage assignments to your cloud applications` and select `OpenMetadata` from list of applications.
|
||||
|
||||
- Click on `Actions` and select `Edit Configurations` from list. Populate the shown values replacing `localhost:8585` with your `{domain}:{port}` and Submit.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-6.png" alt="edit-configuration" /%}
|
||||
|
||||
- Click on `Actions` again and select `Edit Attribute Mapping` from list. Populate the values as shown below and submit
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/aws/saml-aws-7.png" alt="edit-attribute" /%}
|
||||
|
||||
Send the Collate team the above information to configure the server.
|
||||
@ -0,0 +1,79 @@
|
||||
---
|
||||
title: SAML AZURE SSO
|
||||
slug: /security/saml/azure
|
||||
collate: true
|
||||
---
|
||||
|
||||
# SAML AZURE SSO
|
||||
|
||||
Follow the sections in this guide to set up Azure SSO using SAML.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create OpenMetadata application
|
||||
|
||||
### Step 1: Configure a new Application in Microsoft Entra ID
|
||||
|
||||
- Login to [Azure Portal](https://portal.azure.com) as an administrator and search for Microsoft Entra ID.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-1.png" alt="EnterpriseApplications" /%}
|
||||
|
||||
- Click on `Enterprise Applications` and then ` + New Application ` .
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-2.png" alt="new-application" /%}
|
||||
|
||||
- After that a new window will appear with different applications, click on `Create your own application`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-3.png" alt="create-own-application" /%}
|
||||
|
||||
- Give your application a name and select `Integrate any other application you don't find in the gallery` and then click `Create`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-4.png" alt="name-application-create" /%}
|
||||
|
||||
- Once you have the application created, open the app from list , and then click on `Single Sign-On` and then `SAML`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-5.png" alt="saml-create-single-sign-On" /%}
|
||||
|
||||
- Edit `Basic SAML Configuration` and populate the values as shown below for `EntityId` and `Assertion Consumer Service Url`. These value should match the one configured with Openmetadata Server side for `samlConfiguration.sp.entityId` and `samlConfiguration.sp.acs` respectively. After this click `Save`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-6.png" alt="edit-basic-saml-configuration" /%}
|
||||
|
||||
- Click on `Attributes and Claims` and click on the `Required Claim (NameId)`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-7.png" alt="edit-claims" /%}
|
||||
|
||||
- You will see the values as below image, we need to set the value `Source Attribute` to a user mail value claim from the IDP. Click on `Edit` and then select the `Source Attribute` as `user.mail` or `user.userprincipalname` (in some cases this is also a mail) and then click `Save`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-8.png" alt="edit-claim-value" /%}
|
||||
|
||||
- To Confirm the claim value we can navigate to user page and check the value of the user. In my case as you can see User Princpal Name is a my mail which i want to use for Openmetadata , so for me `user.userprincipalname` would be correct claim.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-9.png" alt="user-claim-value" /%}
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- You must always communicate via signed Request for both request from SP to IDP and response from IDP to SP.
|
||||
- To do so we need to add SP certificate to IDP , so that IDP can validate the signed Auth Request coming from SP.
|
||||
|
||||
- Generate the certificate using below command and then upload the certificate to IDP.
|
||||
```shell
|
||||
openssl req -new -x509 -days 365 -nodes -sha256 -out saml.crt -keyout saml.pem
|
||||
openssl x509 -in saml.crt -out samlCER.cer -outform DER
|
||||
```
|
||||
|
||||
- Under `Single Sign-On` you will see SAML Certificates, click on `Verification Certificates`.
|
||||
|
||||
{% image src="/images/v1.5/deployment/security/saml/azure/saml-azure-11.png" alt="verification-certificate" /%}
|
||||
|
||||
- You can then check the `Require Verification Certificates` and import the certification with .cer format we generated previously.
|
||||
|
||||
{% /note %}
|
||||
|
||||
Send the Collate team the above information to configure the server.
|
||||
@ -0,0 +1,79 @@
|
||||
---
|
||||
title: SAML SSO
|
||||
slug: /security/saml
|
||||
collate: true
|
||||
---
|
||||
|
||||
# SAML SSO
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Configuring Identity Provider and Service Provider
|
||||
|
||||
### Identity Provide (IDP) Configuration
|
||||
|
||||
- Every IDP will have the following information
|
||||
|
||||
1. EntityId/Authority -> Same as IDP Openmetadata has an Entity Id
|
||||
2. SignOn Url -> Service Provider SignOn Url
|
||||
3. X509 Certificate -> In case the SP expects (wantAuthnRequestSigned) then provide certificate for validating.
|
||||
4. Authority Url -> We just need to update the domain `localhost`.
|
||||
5. NameID: This is sent as part of request and is provided by the IDP.
|
||||
|
||||
Every IDP provides this information, we can download the XML Metadata and configure the OM taking the values from the XML.
|
||||
|
||||
### Service Provider (SP) Configuration
|
||||
|
||||
- Openmetadata is the service provider, we just update the `localhost` to the hosted URI.
|
||||
|
||||
1. EntityId/Authority -> Normally a Url providing info about the provider.
|
||||
2. SignOn Url -> Url to be used for signing purpose.
|
||||
3. X509 Certificate -> In case the SP expects a signed response from IDP, the IDP can be configured with Signing Certificate given by SP.
|
||||
4. Private Key -> In case SP expects a encrypted response from the IDP , the IDP can be configured with SPs public key for encryption and the Private Key can be used for SP for decrypting.
|
||||
|
||||
### Security Configuration
|
||||
|
||||
Security Configuration controls the SP requirement for the Security related aspects.
|
||||
The SP can be configured to send signed or encrypted or both request , and in return can also expect
|
||||
signed or encrypted or both responses from the IDP.
|
||||
|
||||
## Setup JWT Configuration
|
||||
|
||||
Jwt Configuration is mandatory for Saml SSO.
|
||||
|
||||
- Follow the guide here for JWT Configuration [Enable JWT Token](/deployment/security/enable-jwt-tokens).
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) the ones shipped with OM are for POC only.
|
||||
|
||||
{% /note %}
|
||||
|
||||
More specific details on different IDPs can be found below:
|
||||
|
||||
{% inlineCalloutContainer %}
|
||||
{% inlineCallout
|
||||
color="violet-70"
|
||||
icon="celebration"
|
||||
bold="AWS Saml"
|
||||
href="/security/saml/aws" %}
|
||||
Configure AWS as IDP.
|
||||
{% /inlineCallout %}
|
||||
{% /inlineCalloutContainer %}
|
||||
|
||||
{% inlineCalloutContainer %}
|
||||
{% inlineCallout
|
||||
color="violet-70"
|
||||
icon="celebration"
|
||||
bold="Azure Saml"
|
||||
href="/security/saml/azure" %}
|
||||
Configure AWS as IDP.
|
||||
{% /inlineCallout %}
|
||||
{% /inlineCalloutContainer %}
|
||||
1800
openmetadata-docs/content/v1.6.x-SNAPSHOT/collate-menu.md
Normal file
1800
openmetadata-docs/content/v1.6.x-SNAPSHOT/collate-menu.md
Normal file
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,70 @@
|
||||
---
|
||||
title: Amazon Cognito SSO
|
||||
slug: /security/amazon-cognito
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Amazon Cognito SSO
|
||||
|
||||
Follow the sections in this guide to set up Amazon Cognito SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Amazon Cognito SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is
|
||||
enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Login to AWS Portal
|
||||
|
||||
- Login to [Amazon AWS Portal](https://aws.amazon.com/).
|
||||
- Search for `Cognito` in the search box and select Cognito Service from the dropdown menu.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-1.png" alt="create-account" caption="Search for Cognito" /%}
|
||||
|
||||
### Step 2: Setup User Pool
|
||||
|
||||
- Click on the "Create user pool" button if you do not have any user pools configured yet. Skip this step if you already have a user pool available.
|
||||
- Select the type of ID providers you want to configure for your users and click "Next"
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-2.png" alt="create-account" caption="Setup User Pool" /%}
|
||||
|
||||
- Configure the security requirements in Step 2 as per your organizational needs and proceed to Step 3
|
||||
- Configure the Sign-up experience in Step 3. Make sure to add email as a required attribute before proceeding to step 4
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-3.png" alt="create-account" caption="Configure Sign up Experience" /%}
|
||||
|
||||
- Configure message delivery as per your organizational needs and proceed to Step 5
|
||||
- In Step 5, add a name for the user pool and check the "Use the Cognito Hosted UI" option and provide a Cognito domain as shown in the screenshot below
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-4.png" alt="create-account" caption="Integrate your App" /%}
|
||||
|
||||
- In the same step, select "Public client" for the Initial App client type and configure the Allowed callback URLs
|
||||
with `http://localhost:8585/callback` as shown in the screenshot below. Note: For production deployments, the Allowed
|
||||
callback URLs should be updated with the appropriate domain name.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-5.png" alt="create-account" caption="Configure the App Client" /%}
|
||||
|
||||
- The last step is to Review and create the User Pool.
|
||||
|
||||
### Step 3: Where to find the Credentials
|
||||
|
||||
- The `User Pool ID` can be found in the User Pool summary page as seen in the screenshot below
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-6.png" alt="create-account" caption="User Pool ID" /%}
|
||||
|
||||
- The App client ID can be found under the "App Integration" tab of the User Pool page. There will be a section that
|
||||
lists all the App clients with client name and client ID as shown below
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-7.png" alt="create-account" /%}
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/amazon-cognito-sso/create-server-credentials-8.png" alt="create-account" caption="Client ID" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
- User Pool ID
|
||||
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Auth0 SSO
|
||||
slug: /security/auth0
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Auth0 SSO
|
||||
|
||||
Follow the sections in this guide to set up Auth0 SSO.
|
||||
|
||||
{%important%}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Auth0 SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{%/important%}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Create the Account
|
||||
|
||||
- If you don't have an account, [Sign up](https://auth0.com/signup) to create one.
|
||||
- Select the Account Type, i.e., Company or Personal
|
||||
- Click I need advanced settings and click next.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/create-account-1.png"
|
||||
alt="create-account" /%}
|
||||
|
||||
- Provide the Tenant Domain, select the region and click on Create Account.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/create-account-2.png"
|
||||
alt="create-account" /%}
|
||||
|
||||
- Once done, you will land on the dashboard page.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/create-account-3.png"
|
||||
alt="create-account" /%}
|
||||
|
||||
### Step 2: Create a New Application
|
||||
|
||||
- Once you are on the Dashboard page, click on `Applications > Applications` available on the left-hand side panel.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/create-new-app-1.png"
|
||||
alt="create-app" /%}
|
||||
|
||||
- Click on `Create Application`.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/create-new-app-2.png"
|
||||
alt="create-app" /%}
|
||||
|
||||
- Enter the Application name.
|
||||
- Choose an application type and click on `Create`.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/create-new-app-3.png"
|
||||
alt="create-app" /%}
|
||||
|
||||
### Step 3: Where to Find the Credentials
|
||||
|
||||
- Navigate to the Settings tab.
|
||||
- You will find your `Client ID` and `Domain`.
|
||||
|
||||
{% image
|
||||
src="/images/v1.6/deployment/security/auth0/credentials.png"
|
||||
alt="credentials" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
- Domain
|
||||
@ -0,0 +1,80 @@
|
||||
---
|
||||
title: Azure SSO
|
||||
slug: /security/azure
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Azure SSO
|
||||
|
||||
Follow the sections in this guide to set up Azure SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Azure SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Login to Azure Active Directory
|
||||
|
||||
- Login to [Microsoft Azure Portal](https://azure.microsoft.com/en-in/services/active-directory/external-identities/)
|
||||
- Navigate to the Azure Active Directory.
|
||||
|
||||
{% note %}
|
||||
|
||||
Admin permissions are required to register the application on the Azure portal.
|
||||
|
||||
{% /note %}
|
||||
|
||||
### Step 2: Create a New Application
|
||||
|
||||
- From the Azure Active Directory, navigate to the `App Registrations` section from the left nav bar.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/azure/create-app-1.png" alt="create-app" /%}
|
||||
|
||||
- Click on `New Registration`. This step is for registering the OpenMetadata UI.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/azure/create-app-2.png" alt="create-app" /%}
|
||||
|
||||
- Provide an Application Name for registration.
|
||||
- Provide a redirect URL as a `Single Page Application`.
|
||||
- Click on `Register`.
|
||||
|
||||
{% note %}
|
||||
|
||||
- **SPA (Single Page Application):**
|
||||
This type is designed for implicit flows. In this case, providing both the client ID and client secret will result in a failure because the implicit flow only requires the client ID for authentication.
|
||||
|
||||
- **Web:**
|
||||
This type is intended for confidential clients. If you select this option, you must provide both the client ID and client secret. Simply passing the client ID will cause the authorization process to fail, as the Authorization Code flow requires both credentials for successful authentication.
|
||||
|
||||
### Recommendation:
|
||||
|
||||
- Use the **Web** type for confidential clients that require both a client ID and secret.
|
||||
- Use the **SPA** type for applications using implicit flows where only a client ID is needed.
|
||||
|
||||
{% /note %}
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/azure/create-app-3.png" alt="create-app" /%}
|
||||
|
||||
### Step 3: Where to Find the Credentials
|
||||
|
||||
- The `Client ID` and the `Tenant ID` are displayed in the Overview section of the registered application.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/azure/where-to-find-credentials.png" alt="create-app" /%}
|
||||
|
||||
- When passing the details for `authority`, the `Tenant ID` is added to the URL as shown in the example
|
||||
below. `https://login.microsoftonline.com/TenantID`
|
||||
|
||||
```commandline
|
||||
"authority": "https://login.microsoftonline.com/c11234b7c-b1b2-9854-0mn1-56abh3dea295"
|
||||
```
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
- Tenant ID
|
||||
@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Custom OIDC SSO
|
||||
slug: /security/custom-oidc
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Custom OIDC SSO
|
||||
|
||||
Follow the sections in this guide to set up Custom OIDC SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Custom OIDC SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
- Go to the console of your preferred custom OIDC SSO provider
|
||||
- Create an OIDC client application with implicit flow enabled to get a client ID.
|
||||
|
||||
### Create Client ID and Secret Key
|
||||
|
||||
- Navigate to your preferred OIDC provider console and create an OIDC client application.
|
||||
- Generate client ID and secret key in JSON format.
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
@ -0,0 +1,87 @@
|
||||
---
|
||||
title: Google SSO
|
||||
slug: /security/google
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Google SSO
|
||||
|
||||
Follow the sections in this guide to set up Google SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Google SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Create the Account
|
||||
- Go to [Create Google Cloud Account](https://console.cloud.google.com/)
|
||||
- Click on `Create Project`
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/google/create-account.png" alt="create-account" caption="Create a New Account" /%}
|
||||
|
||||
### Step 2: Create a New Project
|
||||
Enter the **Project name**.
|
||||
Enter the parent organization or folder in the **Location box**. That resource will be the hierarchical parent of the new project.
|
||||
Click **Create**.
|
||||
{% image src="/images/v1.6/deployment/security/google/create-project.png" alt="create-project" caption="Create a New Project" /%}
|
||||
|
||||
### Step 3: How to Configure OAuth Consent
|
||||
- Select the project you created above and click on **APIs & Services** on the left-side panel.
|
||||
{% image src="/images/v1.6/deployment/security/google/configure-oauth-consent.png" alt="configure-oauth-consent" /%}
|
||||
|
||||
- Click on the **OAuth Consent Screen** available on the left-hand side panel.
|
||||
- Choose User Type **Internal**.
|
||||
{% image src="/images/v1.6/deployment/security/google/select-user-type.png" alt="select-user-type" /%}
|
||||
|
||||
- Once the user type is selected, provide the **App Information** and other details.
|
||||
- Click **Save and Continue**.
|
||||
{% image src="/images/v1.6/deployment/security/google/save-app-information.png" alt="save-app-information" /%}
|
||||
|
||||
- On the **Scopes Screen**, Click on **ADD OR REMOVE SCOPES** and select the scopes.
|
||||
- Once done click on **Update**.
|
||||
{% image src="/images/v1.6/deployment/security/google/scopes-screen.png" alt="scopes-screen" /%}
|
||||
|
||||
- Click **Save and Continue**.
|
||||
{% image src="/images/v1.6/deployment/security/google/save-edit-app-registration.png" alt="save-edit-app-registration" /%}
|
||||
|
||||
- Click on **Back to Dashboard**.
|
||||
{% image src="/images/v1.6/deployment/security/google/back-to-dashboard.png" alt="back-to-dashboard" /%}
|
||||
{% image src="/images/v1.6/deployment/security/google/back-to-dashboard-2.png" alt="back-to-dashboard" /%}
|
||||
|
||||
### Step 4: Create Credentials for the Project
|
||||
- Once the OAuth Consent is configured, click on **Credentials** available on the left-hand side panel.
|
||||
{% image src="/images/v1.6/deployment/security/google/create-credentials.png" alt="create-credentials" /%}
|
||||
|
||||
- Click on **Create Credentials**
|
||||
- Select **OAuth client ID** from the dropdown.
|
||||
{% image src="/images/v1.6/deployment/security/google/select-outh-client-id.png" alt="cselect-outh-client-id" /%}
|
||||
|
||||
- Once selected, you will be asked to select the **Application type**. Select **Web application**.
|
||||
{% image src="/images/v1.6/deployment/security/google/select-web-application.png" alt="select-web-application" /%}
|
||||
|
||||
After selecting the **Application Type**, name your project and give the authorized URIs:
|
||||
- domain/callback
|
||||
- domain/silent-callback
|
||||
{% image src="/images/v1.6/deployment/security/google/authorized-urls.png" alt="authorized-urls" /%}
|
||||
|
||||
- Click **Create**
|
||||
- You will get the credentials
|
||||
{% image src="/images/v1.6/deployment/security/google/get-the-credentials.png" alt="get-the-credentials" /%}
|
||||
|
||||
### Step 5: Where to Find the Credentials
|
||||
- Go to **Credentials**
|
||||
- Click on the **pencil icon (Edit OAuth Client)** on the right side of the screen
|
||||
{% image src="/images/v1.6/deployment/security/google/find-credentials.png" alt="find-credentials" /%}
|
||||
|
||||
- You will find the **Client ID** in the top right corner
|
||||
{% image src="/images/v1.6/deployment/security/google/find-clientid-and-secret.png" alt="find-clientid-and-secret" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
@ -0,0 +1,76 @@
|
||||
---
|
||||
title: Enable Security
|
||||
slug: /security
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Enable Security
|
||||
|
||||
This section provides detailed instructions to secure the access to the Collate platform.
|
||||
|
||||
Collate has support for multiple identity providers. Please, see the next sections about how to configure them.
|
||||
|
||||
{% note %}
|
||||
|
||||
Collate does not currently support the simultaneous use of multiple authentication mechanisms, such as combining SSO and Basic Authentication.
|
||||
|
||||
{% /note %}
|
||||
|
||||
{%inlineCalloutContainer%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Auth0 SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/auth0"%}
|
||||
Configure Auth0 SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Azure SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/azure"%}
|
||||
Configure Azure SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Custom OIDC SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/custom-oidc"%}
|
||||
Configure a Custom OIDC SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Google SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/google"%}
|
||||
Configure Google SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Okta SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/okta"%}
|
||||
Configure Okta SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Amazon Cognito SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/amazon-cognito"%}
|
||||
Configure Amazon Cognito SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="OneLogin SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/one-login"%}
|
||||
Configure OneLogin SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%inlineCallout
|
||||
color="violet-70"
|
||||
bold="Keycloak SSO"
|
||||
icon="add_moderator"
|
||||
href="/security/keycloak"%}
|
||||
Configure Keycloak SSO to access the UI and APIs
|
||||
{%/inlineCallout%}
|
||||
{%/inlineCalloutContainer%}
|
||||
@ -0,0 +1,73 @@
|
||||
---
|
||||
title: Keycloak SSO
|
||||
slug: /security/keycloak
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Keycloak SSO
|
||||
|
||||
Follow the sections in this guide to set up Keycloak SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Keycloak SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Access the Keycloak Admin Console
|
||||
|
||||
- You need an administrator account. If you don't have, see [Creating the first administrator](https://www.keycloak.org/docs/latest/server_admin/#creating-first-admin_server_administration_guide).
|
||||
- Go to the URL for the Admin Console. For example, for localhost, use this URL: http://localhost:8080/admin/
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/keycloak/1-login-page.png" alt="login-page" /%}
|
||||
|
||||
- Enter the username and password you created.
|
||||
|
||||
### Step 2: Change Realm selected
|
||||
- The Keycloak use Realms as the primary form of organization, we can't use the realm "master" for new clients (apps), only for administration, so change for your specific realm or create a new.
|
||||
- In this example we are used an existing one called "Data-sec".
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/keycloak/2-change-realm.png" alt="change-realm" /%}
|
||||
|
||||
### Step 3: Create OpenMetadata as a new Client
|
||||
- Click on `Clients` in the menu.
|
||||
- Click on `Create` button.
|
||||
- Enter the Client ID and Protocol as the image.
|
||||
- Click on `Save` button.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/keycloak/3-add-client.png" alt="add-client" /%}
|
||||
|
||||
### Step 4: Edit settings of the client
|
||||
- Change "Access Type" value from "public" to "confidential".
|
||||
- Change "implicit flow" and "service accounts" to enabled.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/keycloak/4-edit-settings-client.png" alt="edit-settings-client" /%}
|
||||
|
||||
- At the bottom of the same settings page, change the configurations to the openmetadata address.
|
||||
- The image below shows different possibilities, such as running locally or with a custom domain.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/keycloak/5-edit-settings-url.png" alt="edit-settings-url.png" /%}
|
||||
|
||||
- Click on `Save` button.
|
||||
|
||||
{% note %}
|
||||
|
||||
Note: Scopes `openid`, `email` & `profile` are required to fetch the user details so you will have to add these scopes in your client.
|
||||
|
||||
{% /note %}
|
||||
|
||||
### Step 5: Where to Find the Credentials
|
||||
|
||||
- Navigate to the `Credentials` tab.
|
||||
- You will find your Client `Secret` related to the Client id "open-metadata"
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/keycloak/6-client-credentials.png" alt="client-credentials" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Client ID
|
||||
@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Ldap Authentication
|
||||
slug: /security/ldap
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Setting up Ldap Authentication
|
||||
{%important%}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Auth0 SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{%important%}
|
||||
|
||||
OpenMetadata allows using LDAP for validating email and password authentication.
|
||||
Once setup successfully, the user should be able to sign in to OpenMetadata using the Ldap credentials.
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- `host`: hostName for the Ldap Server (Ex - localhost).
|
||||
- `port`: port of the Ldap Server to connect to (Ex - 10636).
|
||||
- `dnAdminPrincipal`: This is the DN Admin Principal(Complete path Example :- cn=admin,dc=example,dc=com) with a lookup access in the Directory.
|
||||
- `dnAdminPassword`: Above Admin Principal Password.
|
||||
- `userBaseDN`: User Base DN(Complete path Example :- ou=people,dc=example,dc=com).
|
||||
|
||||
Please see the below image for a sample LDAP Configuration in ApacheDS.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/ldap/Ldap_ScreenShot1.png" alt="apache-ldap" /%}
|
||||
|
||||
Advanced LDAP Specific Configuration (Optional):
|
||||
|
||||
- `maxPoolSize`: Connection Pool Size to use to connect to LDAP Server.
|
||||
- `sslEnabled`: Set to true if the SSL is enable to connect to LDAP Server.
|
||||
- `truststoreConfigType`: Truststore type. It is required. Can select from {CustomTrustStore, HostName, JVMDefault, TrustAll}
|
||||
- `trustStoreConfig`: Config for the selected truststore type. Please check below note for setting this up.
|
||||
|
||||
{%note%}
|
||||
|
||||
Based on the different `truststoreConfigType`, we have following different `trustStoreConfig`.
|
||||
|
||||
1. **TrustAll**: Provides an SSL trust manager which will blindly trust any certificate that is presented to it, although it may optionally reject certificates that are expired or not yet valid. It can be convenient for testing purposes, but it is recommended that production environments use trust managers that perform stronger validation.
|
||||
- `examineValidityDates`: Indicates whether to reject certificates if the current time is outside the validity window for the certificate.
|
||||
|
||||
2. **JVMDefault**: Provides an implementation of a trust manager that relies on the JVM's default set of trusted issuers.
|
||||
- `verifyHostname`: Controls using TrustAllSSLSocketVerifier vs HostNameSSLSocketVerifier. In case the certificate contains cn=hostname of the Ldap Server set it to true.
|
||||
|
||||
3. **HostName**: Provides an SSL trust manager that will only accept certificates whose hostname matches an expected value.
|
||||
- `allowWildCards`: Indicates whether to allow wildcard certificates which contain an asterisk as the first component of a CN subject attribute or dNSName subjectAltName extension.
|
||||
- `acceptableHostNames`: The set of hostnames and/or IP addresses that will be considered acceptable. Only certificates with a CN or subjectAltName value that exactly matches one of these names (ignoring differences in capitalization) will be considered acceptable. It must not be null or empty.
|
||||
|
||||
4. **CustomTrustStore**: Use the custom Truststore by providing the below details in the config.
|
||||
- `trustStoreFilePath`: The path to the trust store file to use. It must not be null.
|
||||
- `trustStoreFilePassword`: The PIN to use to access the contents of the trust store. It may be null if no PIN is required.
|
||||
- `trustStoreFileFormat`: The format to use for the trust store. (Example :- JKS, PKCS12).
|
||||
- `verifyHostname`: Controls using TrustAllSSLSocketVerifier vs HostNameSSLSocketVerifier. In case the certificate contains cn=hostname of the Ldap Server set it to true.
|
||||
- `examineValidityDates`: Indicates whether to reject certificates if the current time is outside the validity window for the certificate.
|
||||
|
||||
{%/note%}
|
||||
@ -0,0 +1,153 @@
|
||||
---
|
||||
title: OIDC Based Authentication
|
||||
slug: /security/oidc
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Setting up Any Oidc Provider
|
||||
{%important%}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Auth0 SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{%important%}
|
||||
|
||||
This guide provides instructions on setting up OpenID Connect (OIDC) configuration for your application. OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol that allows clients to verify the identity of the end-user.
|
||||
Below configurations are universally applicable to all SSO provider like Google, Auth0, Okta, Keycloak, etc.
|
||||
|
||||
Below are the configuration types to set up the OIDC Authentication with a Confidential Client type:
|
||||
|
||||
```yaml
|
||||
authenticationConfiguration:
|
||||
clientType: ${AUTHENTICATION_CLIENT_TYPE:-confidential}
|
||||
publicKeyUrls: ${AUTHENTICATION_PUBLIC_KEYS:-[http://localhost:8585/api/v1/system/config/jwks]}
|
||||
oidcConfiguration:
|
||||
id: ${OIDC_CLIENT_ID:-""}
|
||||
type: ${OIDC_TYPE:-""} # google, azure etc.
|
||||
secret: ${OIDC_CLIENT_SECRET:-""}
|
||||
scope: ${OIDC_SCOPE:-"openid email profile"}
|
||||
discoveryUri: ${OIDC_DISCOVERY_URI:-""}
|
||||
useNonce: ${OIDC_USE_NONCE:-true}
|
||||
preferredJwsAlgorithm: ${OIDC_PREFERRED_JWS:-"RS256"}
|
||||
responseType: ${OIDC_RESPONSE_TYPE:-"code"}
|
||||
disablePkce: ${OIDC_DISABLE_PKCE:-true}
|
||||
callbackUrl: ${OIDC_CALLBACK:-"http://localhost:8585/callback"}
|
||||
serverUrl: ${OIDC_SERVER_URL:-"http://localhost:8585"}
|
||||
clientAuthenticationMethod: ${OIDC_CLIENT_AUTH_METHOD:-"client_secret_post"}
|
||||
tenant: ${OIDC_TENANT:-""}
|
||||
maxClockSkew: ${OIDC_MAX_CLOCK_SKEW:-""}
|
||||
customParams: ${OIDC_CUSTOM_PARAMS:-}
|
||||
```
|
||||
# Configuration Parameters
|
||||
|
||||
## Public Key Url (publicKeyUrls):
|
||||
This needs to be updated as per different SSO providers. The default value is `http://localhost:8585/api/v1/system/config/jwks`. This is the URL where the public keys are stored. The public keys are used to verify the signature of the JWT token.
|
||||
|
||||
{%important%}
|
||||
|
||||
**Google**: https://www.googleapis.com/oauth2/v3/certs
|
||||
|
||||
**Okta**: https://dev-19259000.okta.com/oauth2/aus5836ihy7o8ivuJ5d7/v1/keys
|
||||
|
||||
**Auth0**: https://dev-3e0nwcqx.us.auth0.com/.well-known/jwks.json
|
||||
|
||||
**Azure**: https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys
|
||||
|
||||
Also if you have enabled [JWT Tokens](/deployment/security/enable-jwt-tokens) then http://localhost:8585/api/v1/system/config/jwks also needs to be there in the list with proper server url.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Client ID (id):
|
||||
The client ID provided by your OIDC provider. This is typically obtained when you register your application with the OIDC provider.
|
||||
|
||||
## Type (type):
|
||||
Specify the type of OIDC provider you are using (e.g., google, azure). This value is same as `provider` in `authenticationConfiguration`.
|
||||
|
||||
## Client Secret (secret):
|
||||
Replace with the client secret provided by your OIDC provider.
|
||||
|
||||
## Scope (scope):
|
||||
Define the scopes that your application requests during authentication. Update ${OIDC_SCOPE:-"openid email profile"} with the desired scopes.
|
||||
|
||||
{% note %}
|
||||
|
||||
It does not need to be changed in most cases. The default scopes are `openid email profile`. The openid scope is required for OIDC authentication. The email and profile scopes are used to retrieve the user's email address and profile information.
|
||||
Although, some provider only give Refresh Token if `offline_access` scope is provided. So, if you want to use Refresh Token, you need to add `offline_access` scope, like below:
|
||||
`offline_access openid email profile`.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Discovery URI (discoveryUri):
|
||||
Provide the URL of the OIDC provider's discovery document. This document contains metadata about the provider's configuration.
|
||||
|
||||
{%important%}
|
||||
|
||||
It is mostly in the format as below: https://accounts.google.com/.well-known/openid-configuration
|
||||
|
||||
**Google**: https://accounts.google.com/.well-known/openid-configuration
|
||||
|
||||
**Okta**: https://dev-19259000.okta.com/oauth2/aus5836ihy7o8ivuJ5d7/.well-known/openid-configuration
|
||||
|
||||
**Auth0**: https://dev-3e0nwcqx.us.auth0.com/.well-known/openid-configuration
|
||||
|
||||
**Azure**: https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
|
||||
|
||||
Normally it's some initial SSO provider URL followed by `.well-known/openid-configuration`
|
||||
|
||||
{%important%}
|
||||
|
||||
## Use Nonce (useNonce):
|
||||
Set to true by Default, if you want to use nonce for replay attack protection during authentication. This does not need to be changed.
|
||||
|
||||
## Preferred JWS Algorithm (preferredJwsAlgorithm):
|
||||
Specify the preferred JSON Web Signature (JWS) algorithm. Default is RS256 and need not be changed .
|
||||
|
||||
## Response Type (responseType):
|
||||
Define the response type for the authentication request. Default is code and need not be changed.
|
||||
|
||||
## Disable PKCE (disablePkce):
|
||||
Set ${OIDC_DISABLE_PKCE:-true} to true if you want to disable Proof Key for Code Exchange (PKCE). If you want to send CodeVerifier and CodeChallenge in the request, set it to false.
|
||||
|
||||
## Callback URL (callbackUrl):
|
||||
Provide the callback URL where the OIDC provider redirects after authentication. Update ${OIDC_CALLBACK:-"http://localhost:8585/callback"} with your actual callback URL.
|
||||
|
||||
{%important%}
|
||||
|
||||
The only initial part of the URL should be changed, the rest of the URL should be the same as the default one. The default URL is `http://localhost:8585/callback`.
|
||||
Also, this should match what you have configured in your OIDC provider.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Server URL (serverUrl):
|
||||
Specify the URL of your OM Server. Default is http://localhost:8585.
|
||||
|
||||
## Client Authentication Method (clientAuthenticationMethod):
|
||||
Define the method used for client authentication. Default is client_secret_post.
|
||||
|
||||
{%important%}
|
||||
|
||||
This does not need to be changed in most cases. The default value is `client_secret_post`.
|
||||
This method is used to send the client ID and client secret in the request body.
|
||||
Another possible value is `client_secret_basic`, which sends the client ID and client secret in the Authorization header.
|
||||
Depending on the OIDC provider, you may need to change this value if only one of them is supported.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Tenant (tenant):
|
||||
If applicable, specify the tenant ID for multi-tenant applications. Example in case of Azure.
|
||||
|
||||
{%important%}
|
||||
|
||||
This is only applicable for multi-tenant applications. If you are using a single tenant application, you can leave this field empty.
|
||||
For Azure SSO Provider this may be needed.
|
||||
|
||||
{%important%}
|
||||
|
||||
## Max Clock Skew (maxClockSkew):
|
||||
Define the maximum acceptable clock skew between your application server and the OIDC server.
|
||||
|
||||
## Custom Parameters (customParams):
|
||||
If you have any additional custom parameters required for OIDC configuration, specify them here.
|
||||
@ -0,0 +1,141 @@
|
||||
---
|
||||
title: Okta SSO
|
||||
slug: /security/okta
|
||||
collate: true
|
||||
---
|
||||
|
||||
# Okta SSO
|
||||
|
||||
Follow the sections in this guide to set up Okta SSO.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with Okta SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
This document will explain how to create an Okta app and configure it for OAuth. This will generate the information required for Single Sign On with Okta.
|
||||
|
||||
### Step 1: Create an Okta Account
|
||||
- Go to [Create Okta Account](https://developer.okta.com/signup/).
|
||||
- Provide the required input and click on Sign Up.
|
||||
- Else you can continue with Google or GitHub.
|
||||
|
||||
### Step 2: Create the OIDC App Integration.
|
||||
- Once done with **Signup/Sign** in, you will be redirected to the **Getting Started** page in Okta.
|
||||
{% image src="/images/v1.6/deployment/security/okta/create-oidc-app-integration.png" alt="create-oidc-app-integration" /%}
|
||||
|
||||
- Click on **Applications -> Applications** in the left navigation panel.
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-applications.png" alt="click-applications" /%}
|
||||
|
||||
- Click on the **Create App Integration** button.
|
||||
{% image src="/images/v1.6/deployment/security/okta/create-app-integration.png" alt="create-app-integration" /%}
|
||||
|
||||
### Step 3: Configuring the App
|
||||
- Once you are in the **Create a new app integration** page, select **OIDC - OpenID Connect**.
|
||||
- Next, select the **Application type -> Single-Page Application**.
|
||||
- Once selected, click **Next**.
|
||||
{% image src="/images/v1.6/deployment/security/okta/configuring-the-app.png" alt="configuring-the-app" /%}
|
||||
|
||||
- From the **General Settings** page,
|
||||
* Enter an **App integration name**
|
||||
* Select the following in **Grant type**:
|
||||
* **Authorization Code**
|
||||
* **Refresh Token** - For the refresh token behavior, it is recommended to select the option to 'Rotate token after every use'.
|
||||
* **Implicit (hybrid)** - Select the options to allow ID Token and Access Token with implicit grant type.
|
||||
* Enter the **Sign-in redirect URIs**
|
||||
* http://localhost:8585/callback
|
||||
* http://localhost:8585/silent-callback
|
||||
* Enter the **Sign-out redirect URIs**
|
||||
* Enter the **Base URIs**
|
||||
* Select the required option for **Controlled access**
|
||||
- Click **Save**.
|
||||
{% image src="/images/v1.6/deployment/security/okta/general-settings-click-save.png" alt="general-settings-click-save" /%}
|
||||
|
||||
- The app is now configured.
|
||||
{% image src="/images/v1.6/deployment/security/okta/app-is-configured.png" alt="app-is-configured" /%}
|
||||
|
||||
### Step 4: Add Authorization Server to get the Issuer URL
|
||||
#### New Authorization Server
|
||||
It is recommended to create a separate authorization server for different applications. The authorization server needs an endpoint, which'll be the Issuer URL.
|
||||
- Click on **Security -> API** in the left navigation panel.
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-security-api.png" alt="click-security-api" /%}
|
||||
|
||||
- From the **Authorization Servers** tab, click on **Add Authorization Server** button.
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-add-authorization-server.png" alt="click-add-authorization-server" /%}
|
||||
|
||||
- Enter a Name and Description.
|
||||
- While creating the authorization server, an **Audience** must be provided for the server. The Audience is the **Client ID** of the single page application that was created. Refer the next Step 7 to locate the Client ID.
|
||||
- **Save** the changes.
|
||||
{% image src="/images/v1.6/deployment/security/okta/add-auth-server-save-changes.png" alt="add-auth-server-save-changes" /%}
|
||||
|
||||
This will generate the Issuer URL.
|
||||
#### Default Authorization Server (not recommended )
|
||||
It is recommended to create a separate authorization server for different applications. The authorization server needs an endpoint, which'll be the Issuer URL.
|
||||
- Click on **Security -> API** in the left navigation panel.
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-security-api.png" alt="click-security-api" /%}
|
||||
|
||||
- From the **Authorization Servers** tab, click on **default** server.
|
||||
{% image src="/images/v1.6/deployment/security/okta/default-server.png" alt="default-server" /%}
|
||||
|
||||
|
||||
### Step 5: Change the Issuer URL from Dynamic to Okta URL
|
||||
Once the Authorization Server has been added, navigate to Security >> API >> Authorization Servers and click on the authorization server created in the previous step.
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-auth-server-from-prev-step.png" alt="click-auth-server-from-prev-step" /%}
|
||||
|
||||
The Issuer URL shows up as Dynamic by default. Change the Issuer URL to Okta URL and save the changes.
|
||||
{% image src="/images/v1.6/deployment/security/okta/change-issuer-url.png" alt="change-issuer-url" /%}
|
||||
|
||||
### Step 6: Create a Default Scope
|
||||
- To create a default scope from **Security -> API**, click on the required **Authorization Server**.
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-req-auth-server.png" alt="click-req-auth-server" /%}
|
||||
|
||||
- In the resulting page, click on the **Scopes** tab
|
||||
- Click on **Add Scope**
|
||||
{% image src="/images/v1.6/deployment/security/okta/add-scope.png" alt="add-scope" /%}
|
||||
|
||||
- Set as a **Default Scope**.
|
||||
{% image src="/images/v1.6/deployment/security/okta/set-default-scope.png" alt="set-default-scope" /%}
|
||||
|
||||
### Step 7: Add New Access Policy and Rule
|
||||
- From **Security -> API**, click on the required **Authorization Server**
|
||||
- Navigate to the **Access Policies Tab**
|
||||
- Click on **Add New Access Policy**
|
||||
{% image src="/images/v1.6/deployment/security/okta/add-new-access-policy.png" alt="add-new-access-policy" /%}
|
||||
|
||||
- To create a policy, add a Name and Description.
|
||||
- Assign the policy to the required clients.
|
||||
{% image src="/images/v1.6/deployment/security/okta/assign-policy.png" alt="" /%}
|
||||
|
||||
- Add a new **Rule** inside the policy as required. Rules can be created with just a few grant type details, such as Client Credentials, Authorization Code, Device Authorization, and Token Exchange.
|
||||
- Click on **Create Rule** to save the changes.
|
||||
{% image src="/images/v1.6/deployment/security/okta/add-rule.png" alt="add-rule" /%}
|
||||
|
||||
### Step 8: Where to Find the Credentials
|
||||
- Once the app is configured, the **Client ID** can be used.
|
||||
- You can also go to **Application -> Application** as in step 2.
|
||||
- You should be able to see your application in the list.
|
||||
{% image src="/images/v1.6/deployment/security/okta/see-your-application.png" alt="see-your-application" /%}
|
||||
|
||||
- Click on your application.
|
||||
- You will find your **Client ID** and **Okta domain**.
|
||||
- The **Client authentication** is enabled by default.
|
||||
- By clicking on the Edit **** option for General Settings, you can deselect the option for **User consent**. Save the changes.
|
||||
{% image src="/images/v1.6/deployment/security/okta/deselect-user-consent.png" alt="deselect-user-consent" /%}
|
||||
|
||||
- Click on the **Sign On** tab from the top navigation bar.
|
||||
- Click on Edit for **OpenID Connect ID Token**.
|
||||
- For **Issuer**, change from the Dynamic (based on request domain) option to the **Okta URL** option.
|
||||
- The **Audience** is the same as the Client ID.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/okta/click-edit-token.png" alt="click-edit-token" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Issuer URL
|
||||
- Client ID
|
||||
@ -0,0 +1,57 @@
|
||||
---
|
||||
title: OneLogin SSO
|
||||
slug: /security/one-login
|
||||
collate: true
|
||||
---
|
||||
|
||||
# OneLogin SSO
|
||||
|
||||
Follow the sections in this guide to set up OneLogin SSO.
|
||||
|
||||
{% note %}
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM in case you had [Basic Authentication](/deployment/security/basic-auth)
|
||||
enabled before configuring the authentication with OneLogin SSO.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens). The keys we provide
|
||||
by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create Server Credentials
|
||||
|
||||
### Step 1: Configure a new Application
|
||||
|
||||
- Login to [OneLogin](https://www.onelogin.com/) as an administrator and click on Applications
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-1.png" alt="create-account" /%}
|
||||
|
||||
- Click on the `Add App` button and search for `openid connect`
|
||||
- Select the `OpenId Connect (OIDC)` app
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-2.png" alt="create-account" /%}
|
||||
|
||||
- Change the Display Name of the app to `Open Metadata` and click `Save`
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-3.png" alt="create-account" /%}
|
||||
|
||||
- Configure the login Url (`http(s)://<domain>/signin`) and redirect URI (`http(s)://<domain>/callback`) as shown below
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-4.png" alt="create-account" /%}
|
||||
|
||||
- Configure the users in the organization that can access OpenMetadata app by clicking on the `Users`
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-5.png" alt="create-account" /%}
|
||||
|
||||
- Click on "SSO" and select `None (PKCE)` for Token Endpoint.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-6.png" alt="create-account" /%}
|
||||
|
||||
### Step 2: Where to find the Credentials
|
||||
|
||||
- Go to "SSO" and copy the Client ID
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/one-login/create-server-credentials-7.png" alt="create-account" /%}
|
||||
|
||||
You will need to share the following information with the Collate team:
|
||||
- Issuer URL
|
||||
- Client ID
|
||||
@ -0,0 +1,53 @@
|
||||
---
|
||||
title: SAML AWS SSO
|
||||
slug: /security/saml/aws
|
||||
collate: true
|
||||
---
|
||||
|
||||
# SAML AWS SSO
|
||||
|
||||
Follow the sections in this guide to set up AWS SSO using SAML.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create OpenMetadata application
|
||||
|
||||
### Step 1: Configure a new Application in AWS Console
|
||||
|
||||
- Login to [AWS Console](https://aws.amazon.com/console/) as an administrator and search for IAM Identity Center.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-1.png" alt="IAM-Identity-Center" /%}
|
||||
|
||||
- Click on `Choose your identity source` and configure as per security requirements.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-2.png" alt="identity-source" /%}
|
||||
|
||||
- After identity source is set up successfully, goto step 2 and click on `Manage Access to application` and add all the required users who need access to application.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-3.png" alt="manage-access" /%}
|
||||
|
||||
- Click on `Set up Identity Center enabled applications`, and click `Add application`, and select `Add custom SAML 2.0 application`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-4.png" alt="saml-application" /%}
|
||||
|
||||
- Set Display Name to `OpenMetadata` , and download the metadata xml file and save it someplace safe, it is needed to setup OM Server
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-5.png" alt="metadata-xml" /%}
|
||||
|
||||
- Click on `Manage assignments to your cloud applications` and select `OpenMetadata` from list of applications.
|
||||
|
||||
- Click on `Actions` and select `Edit Configurations` from list. Populate the shown values replacing `localhost:8585` with your `{domain}:{port}` and Submit.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-6.png" alt="edit-configuration" /%}
|
||||
|
||||
- Click on `Actions` again and select `Edit Attribute Mapping` from list. Populate the values as shown below and submit
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/aws/saml-aws-7.png" alt="edit-attribute" /%}
|
||||
|
||||
Send the Collate team the above information to configure the server.
|
||||
@ -0,0 +1,79 @@
|
||||
---
|
||||
title: SAML AZURE SSO
|
||||
slug: /security/saml/azure
|
||||
collate: true
|
||||
---
|
||||
|
||||
# SAML AZURE SSO
|
||||
|
||||
Follow the sections in this guide to set up Azure SSO using SAML.
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Create OpenMetadata application
|
||||
|
||||
### Step 1: Configure a new Application in Microsoft Entra ID
|
||||
|
||||
- Login to [Azure Portal](https://portal.azure.com) as an administrator and search for Microsoft Entra ID.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-1.png" alt="EnterpriseApplications" /%}
|
||||
|
||||
- Click on `Enterprise Applications` and then ` + New Application ` .
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-2.png" alt="new-application" /%}
|
||||
|
||||
- After that a new window will appear with different applications, click on `Create your own application`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-3.png" alt="create-own-application" /%}
|
||||
|
||||
- Give your application a name and select `Integrate any other application you don't find in the gallery` and then click `Create`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-4.png" alt="name-application-create" /%}
|
||||
|
||||
- Once you have the application created, open the app from list , and then click on `Single Sign-On` and then `SAML`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-5.png" alt="saml-create-single-sign-On" /%}
|
||||
|
||||
- Edit `Basic SAML Configuration` and populate the values as shown below for `EntityId` and `Assertion Consumer Service Url`. These value should match the one configured with Openmetadata Server side for `samlConfiguration.sp.entityId` and `samlConfiguration.sp.acs` respectively. After this click `Save`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-6.png" alt="edit-basic-saml-configuration" /%}
|
||||
|
||||
- Click on `Attributes and Claims` and click on the `Required Claim (NameId)`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-7.png" alt="edit-claims" /%}
|
||||
|
||||
- You will see the values as below image, we need to set the value `Source Attribute` to a user mail value claim from the IDP. Click on `Edit` and then select the `Source Attribute` as `user.mail` or `user.userprincipalname` (in some cases this is also a mail) and then click `Save`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-8.png" alt="edit-claim-value" /%}
|
||||
|
||||
- To Confirm the claim value we can navigate to user page and check the value of the user. In my case as you can see User Princpal Name is a my mail which i want to use for Openmetadata , so for me `user.userprincipalname` would be correct claim.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-9.png" alt="user-claim-value" /%}
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- You must always communicate via signed Request for both request from SP to IDP and response from IDP to SP.
|
||||
- To do so we need to add SP certificate to IDP , so that IDP can validate the signed Auth Request coming from SP.
|
||||
|
||||
- Generate the certificate using below command and then upload the certificate to IDP.
|
||||
```shell
|
||||
openssl req -new -x509 -days 365 -nodes -sha256 -out saml.crt -keyout saml.pem
|
||||
openssl x509 -in saml.crt -out samlCER.cer -outform DER
|
||||
```
|
||||
|
||||
- Under `Single Sign-On` you will see SAML Certificates, click on `Verification Certificates`.
|
||||
|
||||
{% image src="/images/v1.6/deployment/security/saml/azure/saml-azure-11.png" alt="verification-certificate" /%}
|
||||
|
||||
- You can then check the `Require Verification Certificates` and import the certification with .cer format we generated previously.
|
||||
|
||||
{% /note %}
|
||||
|
||||
Send the Collate team the above information to configure the server.
|
||||
@ -0,0 +1,79 @@
|
||||
---
|
||||
title: SAML SSO
|
||||
slug: /security/saml
|
||||
collate: true
|
||||
---
|
||||
|
||||
# SAML SSO
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **DELETE** the admin default account shipped by OM.
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) in case it is enabled.
|
||||
|
||||
{% /note %}
|
||||
|
||||
## Configuring Identity Provider and Service Provider
|
||||
|
||||
### Identity Provide (IDP) Configuration
|
||||
|
||||
- Every IDP will have the following information
|
||||
|
||||
1. EntityId/Authority -> Same as IDP Openmetadata has an Entity Id
|
||||
2. SignOn Url -> Service Provider SignOn Url
|
||||
3. X509 Certificate -> In case the SP expects (wantAuthnRequestSigned) then provide certificate for validating.
|
||||
4. Authority Url -> We just need to update the domain `localhost`.
|
||||
5. NameID: This is sent as part of request and is provided by the IDP.
|
||||
|
||||
Every IDP provides this information, we can download the XML Metadata and configure the OM taking the values from the XML.
|
||||
|
||||
### Service Provider (SP) Configuration
|
||||
|
||||
- Openmetadata is the service provider, we just update the `localhost` to the hosted URI.
|
||||
|
||||
1. EntityId/Authority -> Normally a Url providing info about the provider.
|
||||
2. SignOn Url -> Url to be used for signing purpose.
|
||||
3. X509 Certificate -> In case the SP expects a signed response from IDP, the IDP can be configured with Signing Certificate given by SP.
|
||||
4. Private Key -> In case SP expects a encrypted response from the IDP , the IDP can be configured with SPs public key for encryption and the Private Key can be used for SP for decrypting.
|
||||
|
||||
### Security Configuration
|
||||
|
||||
Security Configuration controls the SP requirement for the Security related aspects.
|
||||
The SP can be configured to send signed or encrypted or both request , and in return can also expect
|
||||
signed or encrypted or both responses from the IDP.
|
||||
|
||||
## Setup JWT Configuration
|
||||
|
||||
Jwt Configuration is mandatory for Saml SSO.
|
||||
|
||||
- Follow the guide here for JWT Configuration [Enable JWT Token](/deployment/security/enable-jwt-tokens).
|
||||
|
||||
{% note %}
|
||||
|
||||
Security requirements for your **production** environment:
|
||||
- **UPDATE** the Private / Public keys used for the [JWT Tokens](/deployment/security/enable-jwt-tokens) the ones shipped with OM are for POC only.
|
||||
|
||||
{% /note %}
|
||||
|
||||
More specific details on different IDPs can be found below:
|
||||
|
||||
{% inlineCalloutContainer %}
|
||||
{% inlineCallout
|
||||
color="violet-70"
|
||||
icon="celebration"
|
||||
bold="AWS Saml"
|
||||
href="/security/saml/aws" %}
|
||||
Configure AWS as IDP.
|
||||
{% /inlineCallout %}
|
||||
{% /inlineCalloutContainer %}
|
||||
|
||||
{% inlineCalloutContainer %}
|
||||
{% inlineCallout
|
||||
color="violet-70"
|
||||
icon="celebration"
|
||||
bold="Azure Saml"
|
||||
href="/security/saml/azure" %}
|
||||
Configure AWS as IDP.
|
||||
{% /inlineCallout %}
|
||||
{% /inlineCalloutContainer %}
|
||||
Loading…
x
Reference in New Issue
Block a user