You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/authentication/README.md
+8-1
Original file line number
Diff line number
Diff line change
@@ -25,6 +25,10 @@ DataHub provides 3 mechanisms for authentication at login time:
25
25
In subsequent requests, the session token is used to represent the authenticated identity of the user, and is validated by DataHub's backend service (discussed below).
26
26
Eventually, the session token is expired (24 hours by default), at which point the end user is required to log in again.
27
27
28
+
DataHub also supports Guest users to access the system without requiring an explicit login when enabled. The default configuration disables guest authentication.
29
+
When Guest access is enabled, accessing datahub with a configurable URL path logs the user in an existing user that is designated as the guest. The privileges of the guest user
30
+
are controlled by adjusting privileges of that designated guest user.
31
+
28
32
### Authentication in the Backend (Metadata Service)
29
33
30
34
When a user makes a request for Data within DataHub, the request is authenticated by DataHub's Backend (Metadata Service) via a JSON Web Token. This applies to both requests originating from the DataHub application,
@@ -40,12 +44,15 @@ more about Personal Access Tokens [here](personal-access-tokens.md).
40
44
41
45
To learn more about DataHub's backend authentication, check out [Introducing Metadata Service Authentication](introducing-metadata-service-authentication.md).
42
46
43
-
Credentials must be provided as Bearer Tokens inside of the **Authorization** header in any request made to DataHub's API layer. To learn
47
+
Credentials must be provided as Bearer Tokens inside of the **Authorization** header in any request made to DataHub's API layer.
44
48
45
49
```shell
46
50
Authorization: Bearer <your-token>
47
51
```
48
52
53
+
As with the frontend, the backend also can optionally enable Guest authentication. If Guest authentication is enabled, all API calls made to the backend
54
+
without an Authorization header are treated as guest users and the privileges associated with the designated guest user apply to those requests.
55
+
49
56
Note that in DataHub local quickstarts, Authentication at the backend layer is disabled for convenience. This leaves the backend
50
57
vulnerable to unauthenticated requests and should not be used in production. To enable
51
58
backend (token-based) authentication, simply set the `METADATA_SERVICE_AUTH_ENABLED=true` environment variable
Copy file name to clipboardexpand all lines: docs/authentication/concepts.md
+49-2
Original file line number
Diff line number
Diff line change
@@ -60,14 +60,17 @@ There can be many types of Authenticator. For example, there can be Authenticato
60
60
and more! A key goal of the abstraction is *extensibility*: a custom Authenticator can be developed to authenticate requests
61
61
based on an organization's unique needs.
62
62
63
-
DataHub ships with 2 Authenticators by default:
63
+
DataHub ships with 3 Authenticators by default:
64
64
65
65
-**DataHubSystemAuthenticator**: Verifies that inbound requests have originated from inside DataHub itself using a shared system identifier
66
66
and secret. This authenticator is always present.
67
67
68
68
-**DataHubTokenAuthenticator**: Verifies that inbound requests contain a DataHub-issued Access Token (discussed further in the "DataHub Access Token" section below) in their
69
69
'Authorization' header. This authenticator is required if Metadata Service Authentication is enabled.
70
70
71
+
-**DataHubGuestAuthenticator**: Verifies if guest authentication is enabled with a guest user configured and allows unauthenticated users to perform operations as the designated
72
+
guest user. By default, this Authenticator is disabled. If this is required, it needs to be explicitly enabled and requires a restart of the datahub GMS service.
73
+
-
71
74
## What is an AuthenticatorChain?
72
75
73
76
An **AuthenticatorChain** is a series of **Authenticators** that are configured to run one-after-another. This allows
@@ -124,4 +127,48 @@ Today, Access Tokens are granted by the Token Service under two scenarios:
124
127
> At present, the Token Service supports the symmetric signing method `HS256` to generate and verify tokens.
125
128
126
129
Now that we're familiar with the concepts, we will talk concretely about what new capabilities have been built on top
127
-
of Metadata Service Authentication.
130
+
of Metadata Service Authentication.
131
+
132
+
## How do I enable Guest Authentication
133
+
134
+
The Guest Authentication configuration is present in two configuration files - the `application.conf` for DataHub frontend, and
135
+
`application.yaml` for GMS. To enable Guest Authentication, set the environment variable `GUEST_AUTHENTICATION_ENABLED` to `true`
136
+
for both the GMS and the frontend service and restart those services.
137
+
If enabled, the default user designated as guest is called `guest`. This user must be explicitly created and privileges assigned
138
+
to control the guest user privileges.
139
+
140
+
A recommended approach to operationalize guest access is, first, create a designated guest user account with login credentials,
141
+
but keep guest access disabled. This allows you to configure and test the exact permissions this user should have. Once you've
142
+
confirmed the privileges are set correctly, you can then enable guest access, which removes the need for login/credentials
143
+
while maintaining the verified permission settings.
144
+
145
+
The name of the designated guest user can be changed by defining the env var `GUEST_AUTHENTICATION_USER`.
146
+
The entry URL to authenticate as the guest user is `/public` and can be changed via the env var `GUEST_AUTHENTICATION_PATH`
0 commit comments