New openid app - saml required?

Hi,

can anyone tell me if the latest update of openid-connect will require saml working for the domain or is it another possibility?
Can I update without changing my settings or do I have to configure it with saml-access?

Best,
Bernd

The latest OIDC App update to version 2.0 indeed requires the SAML IdP to be reachable and working in the domain. The OIDC App tries to configure the correct SAML Settings for the UCS domain based on the configuration of the UCS system it is installed on. The configuration can be further adapted in the App Settings.

The SAML IdP will be set up to interact with the OIDC identity provider when the App is installed or updated, there should be no need for additional configuration on that end.

Is there any way to prevent this ?

e.g. Kopano Meet now redirects on login to ucs-sso.intern.domain.com instead of id.domain.com where openid connect is available.

I understand the approach to stream line single login but I do not understand why an login attempt via openid connect redirects to the saml login page?

To prevent the integration with the SAML IdP as the authentication backend? That is currently not planned with our OpenID Connect Provider App. Our goal is to have a single point of authentication, in UCS that is the SAML Identity Provider (although the idp can be set up with a failover configuration). Users should only be required to authenticate once, and then use all services configured in the UCS domain. Having the OIDC provider make use of SAML logins is a big step in that direction.

To avoid that, the OIDC app can be downgraded to immediately revert to the old behavior. If the SAML login should not be used in the domain, i would suggest to manually set up a Kopano konnect instance on UCS and use its LDAP backend.

Using the SAML IdP as backend seems no problem to me because in this case the user should not be redirected to the SAML login page but see the openid connect login as frontend which communicates with the SAML BACKEND :slight_smile:
However the diagram here https://www.univention.de/blog-de/2020/06/single-sign-on-integration-saml-und-openid-connect/ suggests that for all genuine openid connect application the login is just redirected to SAML hence making openid connect obsolete. (Despite compatibility for services offering only openid connect and no SAML which so far is just Kopano Meet)

I would think, that my use case is occurring more often:

  • SAML provider only available inside the cooperate network.
  • Kopano Meet available from the outside for meetings with other companies etc.

As I suspect that this behavior is not going to change back the question is:
What options do I have to make the internal SAML provider ucs-sso.intern.domain.com available via reverse proxy under id.domain.com to coexist with openid connect ? (A simple proxypass for “/simplesamlphp” in apache leads to an endless loop)

Another quick workaround is to go into the konnectd-identifier-registration.yaml and simply flip the “required” value to false for the authority entry in there.

But it’s certainly possible to use a domain other than ucs-sso. I have seen that before.