Univention Bugzilla – Bug 57016
OpenID-Connect Login at Portal
Last modified: 2024-01-31 14:54:35 CET
The Portal server could be a standalone OpenID Connect Relying Party, which offers authentication redirections via Authorization Code Flow and logout instead of re-using the UMC session, which is based on that the cookies on the same host are used for both UMC and portal. For the portal scalability is important, therefore we could try to not store session state on the server but move e.g. the tokens into a encrypted cookie. This required frontchannel logout as we have to reset cookies of the client - no backchannel logout possible without keeping a list of denied access tokens. OAuth supports token impersonation, which we could use to let the access tokens which the portal receives be limited in scope and let the server exchange it with a more privileged token which has a audience(+azp) allowed to contact UDM-REST-API / UMC / LDAP. https://datatracker.ietf.org/doc/html/rfc8693 https://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange. https://www.scottbrady91.com/oauth/delegation-patterns-for-oauth-20 It's important that user agents don't get the tokens as with them you can authorize against UDM REST API, UMC and OpenLDAP. If we keep the token wheak enough it might also just be a idea to implement it as public client. We could also try to replace the navigation-god-mode with bearer authentication instead of basic authentication. (And maybe with user impersonation). +++ This bug was initially created as a clone of Bug #49006 +++