Hello all, has anyone succesfully configured OIDC ...
# ui
i
Hello all, has anyone succesfully configured OIDC authentication using azure AD?
b
Just want to confirm you successfully got this working!
i
I have :), it was mostly IT configuration which I had to request support for.
b
Wonderful
a
Good to know. thinking about to give it a try.
g
Hi all, sorry to jump directly to this conversation. I also work on similar things. Can we also use Azure AD for authorization so we can manage the user roles in Azure AD? Thanks.
b
@green-train-47894 today no. But we are considering adding this actively. What exactly would you want to pull from AD? User and group definitions, what else? Roles probably won’t apply because the permissions will be datahub specific right?
g
Thanks for the reply @big-carpet-38439!! If we pull the use and and group, can we map between group in Azure AD and user group in DataHub? The goal is to put the user management in one place (Azure AD), so we don't have to manage user/group in multiple place. For instance, if there is a new employee, the admin just need to add a new user and assign group in AD, then DataHub pull this information and setup a relevant permission without the admin need to add or assign new user and group in DataHub. Does it make sense? 😄
b
Absolutely! The part about syncing users and groups totally makes sense. When having a new user or group datahub will associate them with a ‘default’ role. To change this (add or remove permissions), an admin would need to go to Datahub directly. I think this aligns with what you had mind, correct?
👍 1
One more follow up. Something I’m considering is whether a connector to AD should be polling batches of users / groups on some schedule, or triggered by some event vs just pulling what it needs when a user logs in (lazy loading users and the groups they are in). Do you have opinions here?
g
Hi @big-carpet-38439 Thanks for the responses, sorry for late reply. Yes totally agree. This "_When having a new user or group datahub will associate them with a ‘default’ role._" will be very helpful. I haven't thought about the mechanism that far 😄, but in my opinion the first option is more common. Thanks!!
s
Hi! Sorry for resurrecting this old/ish post. Is there any update on syncing between users and groups in AAD?
b
Yes - we have a batch ingestion source to get users and groups out of AD!
this is useful for seeding users and groups in the platform proactively, or before your company users have logged in. Happy to chat more on this @stale-jewelry-2440!
s
Hi John! Just found instructions on the ingestion in the docs. Thank you!
I have a question about my usecase. In our AD we have more than 100k users (public school, every student/teacher has an account...), but I just need to give access to DataHub to the ones which belong to few groups (R&D, etc.). So, basically I don't need to ingest all of the users/groups, but just the concerned ones, and refuse access to the rest of them. Is there an easy way to accomplish this, or can you please give me few hints on how to implement this? Thank you!
b
@incalculable-ocean-74010 or @stale-jewelry-2440 Do you mind sending me your DataHub frontend env varas for reference? Trying to help out someone else with Azure AD
i
My setup is based on K8s in Azure so it may be different on how to setup OIDC which is cloud specific IIRC. If that is done, the the following configuration should work (assuming secret values are adjusted that is): I've defined a Secret resource that is activated only if OIDC auth is required (this template is not part of DataHub's base helm chart I think):
Copy code
{{- if (index .Values "datahub-frontend" "auth" "oidc" "enabled")}}

apiVersion: v1
kind: Secret
metadata:
  name: auth-oidc-secrets
  labels:
    app: {{ include "datahub.fullname" . }}
    chart: {{ include "datahub.chart" . }}
type: Opaque
data:
  AUTH_OIDC_CLIENT_ID: {{ (index .Values "datahub-frontend" "auth" "oidc" "clientId") | b64enc | quote }}
  AUTH_OIDC_CLIENT_SECRET: {{ (index .Values "datahub-frontend" "auth" "oidc" "clientSecret") | b64enc | quote }}
  AUTH_OIDC_DISCOVERY_URI: {{ (index .Values "datahub-frontend" "auth" "oidc" "discoveryUri") | b64enc | quote }}

{{- end}}
My values.yaml enables this secret like so:
Copy code
datahub-frontend:
  resources:
    limits:
      cpu: 300m
      memory: 600Mi
    requests:
      cpu: 300m
      memory: 600Mi

  ingress:
    enabled: true
    annotations:
      <http://kubernetes.io/ingress.class|kubernetes.io/ingress.class>: nginx
    hosts:
      - host: ****************
        paths: ["/"]

  auth:
    oidc:
      enabled: true
      clientId: "{{DATAHUB-OIDC-CLIENT-ID}}"
      clientSecret: "{{DATAHUB-OIDC-CLIENT-SECRET}}"
      discoveryUri: "<https://login.microsoftonline.com/*******-****-****-****-************/v2.0/.well-known/openid-configuration>"

  extraEnvs:
    - name: JAAS_ENABLED # Disable /login url with dummy validation
      value: "false"
    - name: AUTH_OIDC_ENABLED
      value: "true"
    - name: AUTH_OIDC_BASE_URL
      value: "https://****************"
    - name: AUTH_OIDC_CLIENT_ID
      valueFrom:
        secretKeyRef:
          name: auth-oidc-secrets
          key: AUTH_OIDC_CLIENT_ID
    - name: AUTH_OIDC_CLIENT_SECRET
      valueFrom:
        secretKeyRef:
          name: auth-oidc-secrets
          key: AUTH_OIDC_CLIENT_SECRET
    - name: AUTH_OIDC_DISCOVERY_URI
      valueFrom:
        secretKeyRef:
          name: auth-oidc-secrets
          key: AUTH_OIDC_DISCOVERY_URI
The double brackets template is to retrieve the actual values from an internal key vault. Anonymized potentially sensitive data. Does it help?
Please bare in mind that this might be out of date, I'm still on an old version of DataHub (helm charts v0.2.1, docker images v0.6.1 🐵 😅)
b
Thank you!
s
Hi, I have a docker-compose project, ant the variables in the FE are: AUTH_OIDC_ENABLED=true AUTH_OIDC_JIT_PROVISIONING_ENABLED=true AUTH_OIDC_PRE_PROVISIONING_REQUIRED=false AUTH_OIDC_EXTRACT_GROUPS_ENABLED=true AUTH_OIDC_GROUPS_CLAIM=groups and of course the addresses, in AUTH_OIDC_CLIENT_ID , AUTH_OIDC_CLIENT_SECRET, AUTH_OIDC_DISCOVERY_URI, AUTH_OIDC_BASE_URL
b
okay awesome.. thank you! do you happen to use
AUTH_OIDC_CLIENT_AUTHENTICATION_METHOD=client_secret_post
?