New openid app - saml required?

lebernd · June 14, 2020, 2:26pm

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

damrose · June 16, 2020, 8:09pm

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.

lw3234 · July 7, 2020, 9:20am

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?

damrose · July 7, 2020, 2:03pm

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.

lw3234 · July 7, 2020, 2:43pm

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
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)

fbartels · July 7, 2020, 9:46pm

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.

fbartels · July 10, 2020, 9:06am

While searching for something else I found a howto for changing the fqdn for saml: Configure SAML Single Sign-On as single server solution

lw3234 · July 21, 2020, 11:50am

@fbartels
Thx for the advice and reference. While reading through it this seems to be a bit drastic and disruptive to change the FQDN of sso itself.
I was looking therefore into the possibility to reverse proxy from id.domain.com to ucs-sso.intern.domain.com.

So far I was not able to get a working config. I tried this one https://help.univention.com/t/o365-sso-tagliches-login/13031, which is supposed to work:

<VirtualHost *:443>
	ServerName		id.domain.com
	
	ServerSignature		on

	SSLEngine		on
	SSLProxyEngine		on
	SSLProtocol 		All -SSLv2 -SSLv3

	SSLCertificateFile		"crt"
	SSLCertificateKeyFile		"key"

	
	<ifModule mod_security2.c>
	       	SecRuleEngine off
	</ifModule>
	
	ProxyRequests Off
	ProxyPreserveHost On

	<Proxy *>
               Order deny,allow
               Allow from all
       </Proxy>

	ProxyPass / https://ucs-sso.intern.domain.com/ 
	ProxyPassReverse / https://ucs-sso.intern.domain.com/ 

	ErrorLog        "/var/log/httpd/error_ucs-sso_log"
        CustomLog       "/var/log/httpd/access_ucs-sso_log" combined

</virtualHost>

However the config leads to an endless loop where apache creates worker processes until the limit is reached and the whole application is blocked.

UPDATE:
In order to minimize sources of errors I redirected to http:// instead of https:// now I just get an error page in my browser saying “redirection error” instead of an endless loop.

lw3234 · July 31, 2020, 1:01pm

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.

Where would I find the required value ? My config looks as follows for the authority:

authorities:
- name: ucs-konnect
  default: true
  iss: https://id.domain.com
  client_id: kopano-meet
  client_secret: zXKrYPMBRunRQIoEcCEwj73NMLCi0BIo
  authority_type: oidc
  response_type: id_token
  scopes:
  - openid
  - profile
  - email
  trusted: true
  end_session_enabled: true

PS.: I did not find any solution which worked for a reverse proxy so there is no other chance than trying to disable the saml part.

fbartels · July 31, 2020, 1:52pm

ah, my bad. What I remembered as required is actually called default.

I can’t speak for SAML but OIDC is quite sensitive about urls used to connect so it makes sense that just adding a reverse proxy in front will not lead to a working system. I would still rather recommend to change the url of the saml provider with the provided howto.

pan · August 6, 2020, 9:42am

@lw3234
I’m in the same situation and I also think that this is not a corner case
After not finding any suitable workaround, I decided to downgrade openid-connect-provider.
I do know that it is no permanent solution but for now it’s ok for me. For anyone having the same problem and looking for a temporary workaround:

univention-app remove kopano-meet
univention-app remove openid-connect-provider
univention-app install openid-connect-provider=1.0-konnect-0.23.3
univention-app install kopano-meet

Cheers,
Manuel

lw3234 · August 6, 2020, 2:06pm

Exactly the same here.

Setting the default value to false in konnectd-identifier-registration.yaml still calls the ucs-sso page when accessing openid-connect first and then redirects to openid-connect. Thus it does not solve the problem for connecting from outside the company network where ucs-sso is not available publicly.
I had no luck with reverse proxying ucs-sso.intern.domain.com to somewhere else in order to make it available from the internet.
The only probably working solution would be to change to ucs-sso.intern.domain.com to something else like sso.domain.com. However if you look at the guide provided it seems to me risky with a high probability that one will crash Kerberos or other services currently not thought of.

In the end only the downgrade helped for me.