It would also be good to be able to change this for every OpenID Connect Relying Party Service (oidc/rpservice), so it could also work if service A uses RS256 and service B PS256.
Same goes for the groups: how can I allow only users of group X to use OpenID Connect for service A and group Y to use OpenID Connect for service B?
Fine if this is still missing, I just want to make sure I understand everything correctly.
No problem. Unfortunately I see no way to configure the signing algorithm per service, only globally.
Regarding permissions: As the OIDC Provider is configured against SAML some permissions can be achieved via the SAML settings of groups:
With SAML authentication, the authorization for the use of the OpenID Connect Provider and thus for all apps connected via OIDC can be controlled via SAML authorizations. By default, the group domain users is enabled for access when the app is installed. If this permission should be removed, the corresponding option must also be activated in the app settings so that the permission is not automatically added again.
So if I have a OpenID Connect Relying Party Service for service A and service A is configured to use it, it will work with all configured SAML Identity Providers, not only openid-connect-provider. Correct?
Unfortunately not: That would mean that your connected services would still rely on SAML. When using the OIDC Provider SAML is used between that and the SAML Identity Provider of your domain, therefore permissions given via the right to use the openid-connect-provider will enable access to all OIDC services and additional SAML providers have no effect on the OIDC flow.
Theoretically you could try to operate multiple OIDC providers, but that would lead to heavy constraints. As another note you can of course use SAML and OIDC simultaneously.
So then the following would work only with multiple OIDC providers?
How can I allow only users in group X to use OpenID Connect for service A and users in group Y to use OpenID Connect for service B?
I would love to use SAML, but the two services support only OIDC. Don’t worry, it’s so far more a theoretical/understanding question and nothing urgent (couldn’t get OIDC working with the other service anyway).
Yes, exactly.
Another possible solution would be to bind access to an extended attribute, but that would require to delegate the approval to the service, which seems unlikely to achieve.