Cannot integrate with Windows ADFS about oauth-server HOT 15 CLOSED

Hello, I am having the same issue here... and willing to help.
What's the status of the RFE? (https://issues.redhat.com/browse/RFE-700) it seems I cannot access it...

from oauth-server.

Now I realize that it's taken a very long time, but you might be interested in an enhancement that I put up today in order to address this issue: openshift/enhancements#590

from oauth-server.

There is also an RH bug tracker entry for that issue: https://bugzilla.redhat.com/show_bug.cgi?id=1812206
Our customers are impacted by this problem and we should try to fix that asap! This kind of feature regression is hurting the reputation of Openshift 4.x and should be taken seriously.

from oauth-server.

There is also an RH bug tracker entry for that issue: https://bugzilla.redhat.com/show_bug.cgi?id=1812206
Our customers are impacted by this problem and we should try to fix that asap! This kind of feature regression is hurting the reputation of Openshift 4.x and should be taken seriously.

@mriedmann Thank you for the information. I am still tracking for this feature and I think the best fix should just implement back what OpenShift3.11 did by allowing us to choose what claims for creating identities. BTW, I have a hack by forking the oauth-server hardcoded to use sid instead of sub claim. By unmanaged the authentication-operator, I am able to deploy the custom oauth-server to integrate with ADFS without any support, see if you interested.

Customized oauth-server source code: https://github.com/theodor2311/oauth-server
Customized oauth-server image: https://hub.docker.com/repository/docker/theodor2311/oauth-server
OpenShift 3.11 OIDC: https://docs.openshift.com/container-platform/3.11/install_config/configuring_authentication.html#OpenID

I found an easier workaround for the issue. After you set the operator to unmanaged, you can simply edit the "v4-0-config-system-cliconfig" configmap in the openshift-authentication project. There you can set all the parameters for the oauth-server.

oc patch authentication.operator/cluster  --type=merge -p '{"spec":{"managementState":"Unmanaged"}}'
oc edit -n openshift-authentication cm/v4-0-config-system-cliconfig

The problem with that solution is of course, that you have to revert to the 'Managed' state when you want to update the cluster.

I also had troubles with the userinfo endpoint of ADFS. It only worked when I added the extra parameter resource with the value 'urn:microsoft:userinfo' and this in turn removed all my extra claims I got in the id_token of the authentication endpoint. The workaround for is to remove the userinfo url from v4-0-config-system-cliconfig. @theodor2311 Did this work for you?

from oauth-server.

/remove-lifecycle stale

from oauth-server.

There is also an RH bug tracker entry for that issue: https://bugzilla.redhat.com/show_bug.cgi?id=1812206
Our customers are impacted by this problem and we should try to fix that asap! This kind of feature regression is hurting the reputation of Openshift 4.x and should be taken seriously.

@mriedmann Thank you for the information. I am still tracking for this feature and I think the best fix should just implement back what OpenShift3.11 did by allowing us to choose what claims for creating identities. BTW, I have a hack by forking the oauth-server hardcoded to use sid instead of sub claim. By unmanaged the authentication-operator, I am able to deploy the custom oauth-server to integrate with ADFS without any support, see if you interested.

Customized oauth-server source code: https://github.com/theodor2311/oauth-server
Customized oauth-server image: https://hub.docker.com/repository/docker/theodor2311/oauth-server
OpenShift 3.11 OIDC: https://docs.openshift.com/container-platform/3.11/install_config/configuring_authentication.html#OpenID

from oauth-server.

Thank you very much! I will have a look. Maybe we can work out a PR to reenable this. Another idea we had is to implement a proper encoding mechanism if the sub-claim is no valid k8s-name. If we only apply this to invalid names this would solve the problem and also don't (massively) affect current installations. I am still puzzled why there is so little outcry about this.

from oauth-server.

Thank you very much! I will have a look. Maybe we can work out a PR to reenable this. Another idea we had is to implement a proper encoding mechanism if the sub-claim is no valid k8s-name. If we only apply this to invalid names this would solve the problem and also don't (massively) affect current installations. I am still puzzled why there is so little outcry about this.

Create a PR required adding fields to the CRDs and adding logic for using the claim, I had a hard time to locate where to put the CRD source code before and I finally gave up. I think encoding is not a good way as many encoding algorithms also included unusable characters, also it will not compatible with previously unless you add a flag like "encoded: false" or like you said 'only applied to invalid names' and it will be very messy. I am also surprised not many people yelling about this.

from oauth-server.

Let's see, we got some experienced people on our team, but I agree that using encoding is not a very clean way to deal with that. The main reason to not make the id configurable is that there is a comment in the cluster-authentication-operator that states that this feature was removed due to security concerns. Do you (or someone else) happen to know what kind of attack or problem comes with not using the sub-claim as a user reference?

from oauth-server.

Understand the sub claim is very important for the OIDC and some of the identity providers like ADFS do not allow to tamper the value of the sub claim but other claims are able to modify by using claim rules. Based on this, my first guess will be ADFS admin able to log in as other users by manipulating claim rules. Having said that, I think we should state the security concerns by using non-sub claims or we should find a way to using the sub claim as you said.

Claim Rules: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claim-rules

from oauth-server.

@webner Thank you for sharing, I am not going to hack the oauth-server further as I will not get the support I wanted. I am just hoping we will have the official solution someday.

from oauth-server.

FYI @baldator

from oauth-server.

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from oauth-server.

awesome, thanks @stlaz !

from oauth-server.

Excellent news!
cc @baldator

from oauth-server.