# Authentication Methods Via Dex
Useful Definitions
**Authentication -** Authentication is the process of verifying the identity of a user.
**Authorization** - Authorization is the process of determining if an identified user has access to a particular resource or not.
**Connectors** - When a user logs in through Dex, the user’s identity is usually stored in another user-management system: a LDAP directory, a GitHub org, etc. Dex acts as a shim between a client app and the upstream identity provider. A connector is a strategy used by Dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP and SAML.
**Dex** - Dex is an identity service that uses [OpenID Connect ](https://openid.net/connect/)to drive authentication for other apps. Dex acts as a portal to other identity providers through connectors (see previous definition). This lets Dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to Dex, then Dex handles the protocols for a given backend. For more information about Dex, [click here](https://dexidp.io/docs/).
**LDAP/AD** **Auth Protocol** - Lightweight Directory Access Protocol (LDAP) is an open and cross-platform application protocol for directory services authentication. Directory services, such as Active Directory (AD), store user information, account information, and security information like passwords. The service then allows the information to be shared with other devices on the network.
**OIDC Auth Protocol** - OpenID Connect (OIDC) is an authentication protocol based on the OAuth2 protocol (which is used for authorization). OIDC uses the standardized message flows from OAuth2 to provide identity services. It allows clients to confirm an end user's identity using authentication by an authorization server.
**T4K Auth Support** - T4K supports authentication via KubeConfig files and via Dex, which is an identity service IDP plugin that uses OpenID Connect to drive authentication for multiple applications, by deferring authentication to other identity providers like LDAP.
### Introduction
Trilio For Kubernetes (T4K) uses **Dex** as a portal to other identity providers through **connectors**. For more information about these services, refer to the **Useful References** section at the top of this page.
.png?alt=media)
A **connector** is a strategy used by Dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP.
### Pre-Requisites
1. ***LDAP / AD***: LDAP protocol requires one read-only user who can perform LDAP searches to fetch users and groups.
2. ***OpenShift***: By default, OpenShift clusters already have ***Login Via OpenShift*** configured during the Trilio installation. T4K does not require any additional user input for that.
### Configuration
**STEP 1:** Configure your OIDC authentication provider to allow authentication for T4K Web. Create a new application on the authentication provider portal, then use the T4K callback URL `http(s):///dex/callback` in the OIDC provider portal, and finally, generate client and secret keys.\
\
The following are links to achieve this for the most popular OIDC authentication providers:
{% hint style="info" %}
The dex callback URL should contain a custom path in it for a custom path. for example\
custom path is "/t4k/" then dex callback URL will be http(s):///t4k/dex/callback.
{% endhint %}
{% tabs %}
{% tab title="Google" %}
1. Navigate to the Google application's API [Credentials](https://console.developers.google.com/apis/credentials) page.
2. Click **+ Create Credentials**.\
3. From the dropdown displayed, click **OAuth client ID**.
4. In the **Application type** field, use the dropdown menu to select **Web application**.\
5. Type a meaningful **Name** for the OAuth ID.
6. Add authorized redirect URIs as the TVK call back URL. For example, for the NodePort use and for the LoadBalancer use: \
7. Click **Create**.
8. Copy **Your** **Client ID** and **Your Client Secret** values displayed.\
{% endtab %}
{% tab title="GitHub" %}
Navigate to the GitHub application:
Create a new application on the authentication provider portal, then use the TVK callback URL `http(s):///dex/callback` in the OIDC provider portal, and finally, generate client and secret keys.
{% endtab %}
{% tab title="LinkedIn" %}
Navigate to the LinkedIn application: [https://developer.linkedin.com/](https://developer.linkedin.com)
Create a new application on the authentication provider portal, then use the TVK callback URL `http(s):///dex/callback` in the OIDC provider portal, and finally, generate client and secret keys.
{% endtab %}
{% tab title="GitLab" %}
Navigate to the GitLab application:
Create a new application on the authentication provider portal, then use the TVK callback URL `http(s):///dex/callback` in the OIDC provider portal, and finally, generate client and secret keys.
{% endtab %}
{% tab title="LDAP" %}
1. Ensure that the LDAP server is deployed and configured.
2. Retrieve the following details from the LDAP server, as these are used in the next steps:
* LDAP server host IP or FQDN e.g. *ldap.tvkdemo.org*
* DNS domain name e.g. *tvkdemo.org*
* bindDN: *cn=username,dc=tvkdemo,dc=org*
* bindPW: *password*
{% endtab %}
{% tab title="Azure" %}
1. Navigate to the Azure **Home** > **App registrations** > **Register an application:**()\
2. Type a meaningful name for application; i.e. *TVK-UI-LOGIN.*
3. From the radio button options, choose who can use this application or access this API.
4. Select **Web** from the dropdown menu.
5. Type the redirect URI .
6. Click **Register**.
7. Note down the following two details:
* **Application (client) ID**, e.g. `27920363-a70c-4f26-8fb3-a89c57683a4f`
* Token endpoint -
8. In Azure's left menu panel, select **Certificates & Secrets**.\
9. On the screen displayed, select **+ New client secret.**
10. In the pop-up window displayed, type a meaningful **Description** for your client secret, e.g. *TVK UI Login Secret*. Also set an expiry period.\
11. Click **Add**.
12. The Client secrets tab automatically displays available secrets. Copy the **Value** for the secret just added.\
13. Using the copied value from the previous step, configure the TVK Management Console access over HTTPS. Refer to the following documentation guide: [Here](https://docs.trilio.io/kubernetes/5.2.x/advanced-configuration/accessing-the-ui#access-over-https-prerequisite)
{% endtab %}
{% tab title="OpenShift" %}
By default, OpenShift clusters already have ***Login Via OpenShift*** configured during the Triliovault installation. TVK does not require any additional user input for that, so Step 1 can be skipped for OpenShift.
{% endtab %}
{% tab title="KeyCloak" %}
1. Login into Keycloak Management portal.
2. Select the realm which use for authentication.
3. Navigate to the Client Tab and copy Client name for ClientID
4. Select the client and configure it with TVK URL and callback URL **https\://\/dex/callback**.
5\. Go to Credential tab and Copy **Your Client Secret** values displayed.
{% endtab %}
{% endtabs %}
**Step 2:** Prepare a *secret.yaml* file with the name `triliovault-dex` that has all the copied details of the authentication provider from Step 1 (**Your Client ID** and **Your Client Secret**). Refer to the relevant tab below to guide you how to form your *secret.yaml* for each of the main providers.\
\
You can choose other authentication providers and you can determine what details should be included in the associated *secret.yaml* file by reviewing the most common options below.
{% tabs %}
{% tab title="Google" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: google
id: google
name: Google
config:
clientID: xxxxx.apps.googleusercontent.com
clientSecret: yyyyyyyyyyyyyyyyyyyy
redirectURI: http:///dex/callback
```
{% endtab %}
{% tab title="GitHub" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: github
id: github
name: GitHub
config:
clientID: xxxxxxxxxxxxxxxxxxxxx
clientSecret: yyyyyyyyyyyyyyyyyyyyyyyy
redirectURI: http:///dex/callback
```
{% endtab %}
{% tab title="LinkedIn" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: linkedin
id: linkedin
name: LinkedIn
config:
clientID: 786xxxxxxxxxx
clientSecret: 2myyyyyyyyyyy
redirectURI: http:///dex/callback
```
{% endtab %}
{% tab title="GitLab" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: gitlab
id: gitlab
name: Gitlab
config:
clientID: xxxxxxxxxxxxxxxxxxxxxxxxxxx
clientSecret: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
redirectURI: http:///dex/callback
```
{% endtab %}
{% tab title="LDAP" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: ldap
id: ldap
name: "LDAP"
config:
host:
startTLS: false
insecureNoSSL: true
insecureSkipVerify: true
bindDN: "cn=admin,dc=trilio,dc=io"
bindPW:
usernamePrompt: "Username"
userSearch:
baseDN: "dc=trilio,dc=io"
filter: ""
username: cn
idAttr: cn
emailAttr: cn
nameAttr: cn
groupSearch:
baseDN: "dc=trilio,dc=io"
filter: ""
userAttr: cn
groupAttr: cn
nameAttr: cn
```
The following is a more detailed example with LDAP on SSL with multiple groups:
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
labels:
triliovault.trilio.io/secret: triliovault-dex
type: Opaque
stringData:
TVK_URL: https://cust1-trilio.scc.digital-tw.in
TVK_DEX_CONFIG: |-
connectors:
- type: ldap
id: ldap
name: "LDAP"
config:
host: vse.triliostaging.com:636
rootCAData:
usernamePrompt: "Username"
userSearch:
baseDN: "cn=users,cn=compat,dc=triliostaging,dc=com"
filter: ""
username: uid
idAttr: uid
emailAttr: cn
nameAttr: cn
groupSearch:
baseDN: "cn=groups,cn=compat,dc=triliostaging,dc=com"
filter: "(|(cn=group1)(cn=group2))"
userAttr: uid
groupAttr: memberuid
nameAttr: cn
```
{% endtab %}
{% tab title="Azure" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: oidc
id: azure
name: azure
config:
insecureSkipEmailVerified: true
issuer: https://login.microsoftonline.com/0d4a2397-be27-42b5-9613-6650908518bc/v2.0
clientID: xxxxxxxxxx
clientSecret: yyyyyyyyyyyyy
redirectURI: http:///dex/callback
```
{% endtab %}
{% tab title="OpenShift" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: openshift
id: openshift
name: OpenShift
config:
issuer:
clientID: system:serviceaccount:openshift-operators:
clientSecret: yyyyyyyyyyyyyyyyy
redirectURI: http:///dex/callback
insecureCA: true
```
{% endtab %}
{% tab title="OIDC" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: oidc
id: azure
name: azure
config:
insecureSkipEmailVerified: true
issuer: https://
clientID: xxxxxxxxxxxxx
clientSecret: yyyyyyyyyyyyyyyyyyyyyy
redirectURI: http:///dex/callback
```
{% endtab %}
{% tab title="KeyCloak" %}
```
apiVersion: v1
kind: Secret
metadata:
name: triliovault-dex
namespace:
type: Opaque
stringData:
TVK_DEX_CONFIG: |-
connectors:
- type: oidc
id: keycloak
name: keycloak
config:
issuer: https://
clientID: XXXXXXX
clientSecret: yyyyyyyyyyyyyyyyyyyy
redirectURI: https:///dex/callback
scopes:
- openid
- profile
- email
insecureSkipEmailVerified: true
insecureEnableGroups: true
insecureSkipVerify: true
userIDKey: email
userNameKey: email
```
{% endtab %}
{% endtabs %}
Refer [this doc](https://dexidp.io/docs/connectors/) for all other configuration details of all other connectors and any customer configurations required.
**Step 3 (Optional)** - Only if using 'Port Forwarding' or 'NodePort', update your *secret.yaml* file created in Step 1 with an additional key **T4K\_URL.** This provides your custom URL with a port to access the T4K dashboard.
* Insert a new line in the *secret.yaml* file immediately after code line 9 (applies to all examples given in Step 1) and insert the following:\
`TVK_URL: http://:1234`
* Save the secret YAML file using the same name as before.
**Step 4**: Apply the new *secret.yaml* in the namespace of the k8s cluster where T4K is installed.
```
kubectl apply -f -n
```
This causes the creation of the T4K Dex deployment, which will reflect changes on the T4K Management Console UI. You will now find another way of logging in, according to what you have just configured, i.e. **Login Via Github.**
**Step 5:** Create a cluster role binding using the below command, making sure to replace the *user* with your user/email ID and the *clusterrolebinding* name, since it must be unique:
```
kubectl create clusterrolebinding admin-binding-1 --clusterrole=cluster-admin --user=
```
**Step 6**: Navigate to the Management Console UI login page. You will now see an additional login method, which corresponds to what you have just configured in the previous steps; e.g. **Login Via Github.**
.png?alt=media)
{% hint style="info" %}
For LDAP, you will be prompted for your **Username** and **Password**.
{% endhint %}
8. In Azure's left menu panel, select **Certificates & Secrets**.\
9. On the screen displayed, select **+ New client secret.**
10. In the pop-up window displayed, type a meaningful **Description** for your client secret, e.g. *TVK UI Login Secret*. Also set an expiry period.\
11. Click **Add**.
12. The Client secrets tab automatically displays available secrets. Copy the **Value** for the secret just added.\
13. Using the copied value from the previous step, configure the TVK Management Console access over HTTPS. Refer to the following documentation guide: [Here](https://docs.trilio.io/kubernetes/5.2.x/advanced-configuration/accessing-the-ui#access-over-https-prerequisite)
{% endtab %}
{% tab title="OpenShift" %}
By default, OpenShift clusters already have ***Login Via OpenShift*** configured during the Triliovault installation. TVK does not require any additional user input for that, so Step 1 can be skipped for OpenShift.
{% endtab %}
{% tab title="KeyCloak" %}
1. Login into Keycloak Management portal.
2. Select the realm which use for authentication.
3. Navigate to the Client Tab and copy Client name for ClientID
.png?alt=media)