Here is a noob question. How can I add a user to D...
# troubleshoot
p
Here is a noob question. How can I add a user to DataHub? I installed DataHub in my kubernetes cluster, and joined to DataHub web application with default username/password. However, I didn’t see any admin console or something like that in order to add/list/remove users.
b
Currently users must be added via batch ingestion (eg. for LDAP). Which system do you use to store company users? There is no way to create users / groups via the UI today. I'm assuming this is something that would benefit you folks?
Also, you can setup OIDC authentication that will allow your company users to login, but will not currently "create" new users searchable on DataHub
The final way you could do it is by hitting the Rest API directly, which i can send examples for
g
Hi John, I need to add user to DataHub too.
Could you please send examples of Restful API? Thanks
b
Copy code
curl '<http://localhost:8080/entities?action=ingest>' -X POST --data '{
   "entity":{
      "value":{
         "com.linkedin.metadata.snapshot.CorpUserSnapshot":{
            "aspects":[
               {
                  "com.linkedin.identity.CorpUserInfo":{
                     "active":true,
                     "displayName":"Foo Bar",
                     "fullName":"Foo Bar",
                     "email":"<mailto:fbar@linkedin.com|fbar@linkedin.com>"
                  }
               }
            ],
            "urn":"urn:li:corpuser:foobarusername"
         }
      }
   }
}'
This will create a new user with username "foobarusername"
g
where is the password specified?
b
However, they will not be able to log in automatically- you'll need to setup SSO
Currently DataHub does not manage local password authentication
You must plug in an Identity Provider
Most often via OIDC
That authenticates the user and resolvers the DataHub username'
That being said, adding local username-password (beyond file based) is something we are considering
g
Got it. Thanks. One more question, how do I disable default user
datahub
?
b
Yes of course
Let me send a doc
You'll have to edit the "user.props" file
plus1 1
Which sets a master username and password
You can also disable JAAS configuration altogether by settting the AUTH_JAAS_ENABLED=false flag in your
datahub-frontend
docker.env
g
Got it. Thanks!
p
Thank you @big-carpet-38439! I appreciate your support
b
Of course 🙂 let me know if there are other questions around this! It’s actually something I’m taking a close look at in the next week. We’d love any feedback about feedback about the experience you’d expect!
p
Indeed, we are creating a DataHub PoC to data teams. In order to show the capabilities of DataHub, I would like to add a user and add ownership to this user accordingly.
It seems that I need to integrate Okta database/users to DataHub.
https://datahubproject.io/docs/how/auth/sso/configure-oidc-react-okta/ -> Would it be enough for adding ownership to my colleague? I think it’s just for login, right?
b
Yes this is just for logging users in. The expectation is that you already ingested your users in the metadata ingestion framework (from ldap). Does your Okta sit on top of an underlying LDAP store?
p
I’m not sure, I need to check with IT department
what I know is that everything is integrated with Okta :)
b
Got it... So I think for you guys ideally there'd be an Okta connector 🙂
I'll actually be diving into research on this today
Other folks also want it
p
Thanks John! :)
I will also talk to IT department for further information about Okta integration
if it is working on the top of LDAP or anything else
b
thatd be super helpful!!
p
Ok, here is what I’ve learned. Our source of truth for users is Okta. Every user account/roles are persisted in Okta in the first place. Okta implements OAuth2 and OIDC protocol in order to provide user authentication/authorization. Due to lack of Okta (OIDC, OAuth2) integration for some tools, Okta replicates user data to LDAP server asynchronously.
from user data migration perspective, I’m not sure that what’s the best way to do that via Okta
b
But it's an Okta-managed LDAP instance correct?
Like you aren't deploying Okta anywhere?
p
Okta is SaaS, and its agent is emitting the data to the specified LDAP server as far as I understand
b
I see - do you know where the specified LDAP server lives?
p
Yes, in our private network
I can ingest users data from there as well, however I need Okta integration at some point for Superset or Looker
b
Okay got it.. So your superset and looker users are basically from okta
As long as the usernames align, we should be able to match things up!