search

ManageIQ / manageiq

ManageIQ Open-Source Management Platform
https://manageiq.org
Apache License 2.0
1.35k stars 898 forks source link

Najdorf.1-3 - OIDC with ADFS - oidc_retrieve_claims_from_userinfo_endpoint fails #22406

Open marcel-kondermann opened 1 year ago

marcel-kondermann commented 1 year ago

Hi all,

I'm running the ManageIQ Operator (Najdorf-1.3) on a Ubuntu Microk8s Kubernetes 1.20 environment.

I configured Authentication with openid-connect, where an ADFS Instance serves as the Authentication Provider. See the below (anonymized) specification of the ManageIQ: 

apiVersion: manageiq.org/v1alpha1
kind: ManageIQ
metadata:
  name: myName
  namespace: manageiq
spec:
  applicationDomain: myapplicationDomain
  httpdAuthenticationType: openid-connect
  oidcProviderURL: https://myURL/adfs/.well-known/openid-configuration
  oidcAuthIntrospectionURL: https://myURL/adfs/oauth2/token
  oidcClientSecret: miq-adfs-secret
  oidcCaCertSecret: oidc-cacert-secret
  #enableSSO: true
  enableApplicationLocalLogin: true
  httpdAuthenticationType: openid-connect
  imagePullSecret: myimagePullSecret
  memcachedImage: myImageReg/manageiq-memcached:1.5
  orchestratorImage: myImageReg/manageiq-orchestrator:najdorf-1.3
  httpdImage: myImageReg/manageiq/httpd:2
  postgresqlImage: myImageReg/manageiq-postgresql:10.19
  uiWorkerImage: myImageReg/manageiq-ui-worker:najdorf-1.3
  webserverWorkerImage:  myImageReg/manageiq-webserver-worker:najdorf-1.3
  baseWorkerImage: myImageReg/manageiq-base-worker:najdorf-1.3
  databaseVolumeCapacity: 10Gi
  storageClassName: microk8s-hostpath
  tlsSecret: mytlsSecret

In ManageIQ the according group has been created and given a role. The group-name is exactly the same as in ADFS/AD.

When I try to login via the blue 'Login to corporate System' Button in the ManageIQ UI, the User (member of the MIQ- as well as the AD-Group) is getting signed in successfully but automatically getting logged out as well (Immediately).

The according Error Message in the STDOUT of the httpd-Pod of ManageIQ is like this:

_[Tue Mar 14 10:17:16.751279 2023] [auth_openidc:error] [pid 14:tid 140137014990592] [client ipaddress:port] oidc_retrieve_claims_from_userinfoendpoint: resolving user info claims with the existing/provided access token failed, nothing will be stored in the session, referer: https://url/

In ADFS we are getting the below logs.

The session cookies were successfully deleted using the OAuth logout path : Event ID 552 The specified redirect URL was validated successfully. URL: https://myURL : Event: 553

We cross-checked the whole authentication-part of the configuration and we are quite sure that everything is ok there (secrets, certifications etc.) So we assume that the OIDC-Claim/-Assertion is blocking us.

We specified the Claim on ADFS side according this documentation https://www.manageiq.org/docs/reference/latest/auth/openid_connect.html - where we tried to map the Keycloak Specifications to ADFS. So the claim at ADFS side is looking like this: 

 username
 email
 firstname
 lastname
 fullname
 groups

Do you have an idea why we still fail?

Thanks for your input and support!

Best regards, Marcel.

kbrock commented 1 year ago

Hello Marcel,

The documentation that you linked is for the Appliance (useful in a vm environment). This should be generally useful for both appliances and pods.

Since you are using kubernetes, I would guess that you are running a container/pod environment. Have you gotten the chance to look at the documentation specific to containers?

There are just so many configuration combinations that I'm not sure how well tested the ActiveDirectory configuration is with pods.

There are a lot of moving parts, and the apache oidc connector requires special privileges to connect to sssd over DBUS. This is normal when you are setting up apache on a linux box, but a little strange in the podified world as the goal is to not grant any special privileges.

Fryguy commented 1 year ago

Please also take a look at https://www.manageiq.org/blog/2020/09/troubleshooting-containerized-oidc/ and https://www.manageiq.org/blog/tags/tutorials/ for more troubleshooting tips.

marcel-kondermann commented 1 year ago

Hello Keenan,

Thanks a lot for your input!

Regarding our testing with OIDC and ADFS (in fact it's not Active Directory but ADFS, which sits between ManageIQ and Active Directory) we are one step further in the meantime.

We now can say that the specific ADFS-Instance doesn't provide an Introspection-URL at all. This leads us to the question if MangeIQ supports a setup where the OIDC-Authentication Provider (ADFS in this case) doesn't provide such a Introspection-URL? Or if ManageIQ is only able to work with an existing one? See according error in the operator-log when no Introspection-URL is found:

_{"level":"info","ts":1679930050.170085,"logger":"controller_manageiq","msg":"Reconciling the HTTPD resources..."} {"level":"error","ts":1679930050.304293,"logger":"controller-runtime.controller","msg":"Reconciler error","controller":"manageiq-controller","request":"manageiq/miq","error":"failed to get the OIDCOAuthIntrospectionURL from https://url/adfs/.well-known/openid-configuration - introspectionendpoint is missing from the Provider metadata","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(Controller).reconcileHandler\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.0/pkg/internal/controller/controller.go:258\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(Controller).processNextWorkItem\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.0/pkg/internal/controller/controller.go:232\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.0/pkg/internal/controller/controller.go:211\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\t/root/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:155\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\t/root/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:156\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/root/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:133\nk8s.io/apimachinery/pkg/util/wait.Until\n\t/root/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:90"}

We also checked the documentation that you provided to configure alternate authentication types. Is that maybe a misunderstanding? Because we do not intend to configure the apache oidc connector to go over sssd - Since that would lead to LDAP as the user account database - wheragainst we intend to use ADFS.

Thanks and best regards, Marcel.

marcel-kondermann commented 1 year ago

Hello Jason,

Also, Thanks a lot for your input!

In addition to what we tried based on Keenans input, we also set up a second scenario:

Steps 1 and 2 provide us a access-token. But Step 4 gives us this output:

_> { [5 bytes data]

So conclusion would be:

Does that lead us any further?

Thanks and best regards, Marcel.

marcel-kondermann commented 1 year ago

Hello again everyone,

may I emphasize this question again (see above):

" ... We now can say that the specific ADFS-Instance doesn't provide an Introspection-URL at all. This leads us to the question if MangeIQ supports a setup where the OIDC-Authentication Provider (ADFS in this case) doesn't provide such a Introspection-URL? ... "

For us it's currently the main qeustion. Can it be answered from a MIQ design perspective?

Thanks a lot and best regards, Marcel.