Extend Access control to allow/deny people to use OIDC (Gitea)

[mikhail5555]

Feature Request

Description

Currently if you enable OIDC connect for multiple applications every user that has access to Authelia can use it to login into that service especially applications which only support OAuth2.

I would love if the extended access control for proxying could also be used for allowing/denying people to use OIDC.

Use Case

Enable OIDC connect in Gitea (Which only supports OAuth2) and thus doesnt do any group/user validation. This means that every user now can create a Gitea (or other service) account unless that service specifically doesn't allow new user creation over OAuth2. I would like to restrict this to only users which are for example in the 'gitea' group. Disallowing access to the Gitea url is not an option because of public access which still should be present.

[JaneJeon]

OH. I was under the assumption that the audience could control which groups could get access to a given client… that’s unfortunate :(

[nightah]

I assume you're utilising the file back user backend in Authelia and not LDAP?

If so, I'm a little confused by your statement. If you only want users that are part of a specific group to have access to presumably create an account in Gitea why don't you set your login endpoint on Gitea to be behind 1FA or 2FA and that way the rest of the site is publically accessible?

If you're indeed running LDAP you can have Gitea synchronize users with the LDAP server based on specific filters and that way you can just turn off auto-account creation in Gitea.

I'm not really sure that this is a problem that should be solved in Authelia with additional controls/changes to ACL's/OIDC.

[JaneJeon]

@nightah I guess the difference would be per-URL “limiting by group/dc” vs. per-client “limiting by group/dc” which, to me, just makes more sense to me (after all, you’re limiting an OIDC client, not necessarily the endpoint); not to mention your solution is hacky in that it’s not REALLY utilising OIDC.

After all, what is the point of Authelia having LDAP backend support rather than, say, regular OIDC/SAML if it were not for the ability to essentially “filter” by groups?

[james-d-elliott]

OH. I was under the assumption that the audience could control which groups could get access to a given client… that’s unfortunate :(

This is not the purpose of the audience as far as the OpenID Connect specification reads. As far as I'm aware any OpenID Connect Provider/Relying Party implementing it in this way is not compliant with the spec, and it seems like a blatant misuse of this claim. Basically the audience is used for checking a token is actually authorized for a specific application (i.e. if it doesn't match it's invalid).

not to mention your solution is hacky in that it’s not REALLY utilising OIDC.

How is it not "REALLY utilizing OIDC"? We never claimed to be an OpenID Connect Relying Party, we only claim to be a beta OpenID Connect Provider.

To the original feature request:

While there is merit in the idea of handling RBAC in individual clients on the OpenID Connect Provider, it's rare to see OpenID Connect Relying Party's that do not handle it internally and that behavior in my opinion is strongly encouraged by the spec (i.e. not explicitly stated I don't think, but it seems implied).

Generally an RP should request the appropriate scopes so it has access to claims that are relevant in determining if a user is authorized and what they are authorized for. For example we pass the groups claim when the groups scope is requested, which Gitea should be able to utilize to assign groups to the user.

This is potentially something we'll consider down the track. However our OpenID Connect Provider implementation is in beta. It is not hacky to be cautious when implementing complex things like this, however it would be hacky to just implement something like this without thinking. This will be something that will be discussed in a team meeting once our schedules clear up a bit. Once we've discussed it we'll figure out if/how it fits into the OpenID Connect Provider Roadmap.

[mikhail5555]

@james-d-elliott thanks for your consideration. I indeed understand that this is not really an OpenID Connect Providers job to handle this kind of access control, but it would greatly increase its use with OAuth2 in my case.

@nightah I am indeed using it with the file backend but that is not the root of this feature request. It's also not a problem but I would consider it a nice to have. Setting only the login endpoint behind Authelia, even if possible without side effects (in gitea this would disable default account login) would not work for each application.

[clems4ever]

Apparently Gitea now supports OIDC according to the doc. I think it should solve your initial issue @Mikhail5555 , right?

from https://docs.gitea.io/en-us/oauth2-provider/

[mikhail5555]

@clems4ever I just rechecked the documentation. I think i pulled the plug to fast. Nothing has changed. They do support 'OIDC' in the sence that it allows you to authenticate, it still doesn't support anything more than the profile scope.

So even for Gitea this feature request is still relevent. I think renaming the issue isn't really the best idea, since Gitea is only used as an example and not the only use case for this feature.

[kaaass]

Hope for this feature! In practice, many services' OIDC integration adds new accounts automatically, and such behavior might not be configurable (for example, HedgeDoc). So currently, adding accounts to Authelia is equals to adding accounts to these services at the same time, and there's no way to limit this. I can't find any workarounds so far (other than adding proxy auth for the whole site, which is dumb), the only hope seems to be this feature.

[mikhail5555]

Hope for this feature! In practice, many services' OIDC integration adds new accounts automatically, and such behavior might not be configurable (for example, HedgeDoc). So currently, adding accounts to Authelia is equals to adding accounts to these services at the same time, and there's no way to limit this. I can't find any workarounds so far (other than adding proxy auth for the whole site, which is dumb), the only hope seems to be this feature.

That's the exact reason I indeed requested this feature :)

[james-d-elliott]

Hope for this feature! In practice, many services' OIDC integration adds new accounts automatically, and such behavior might not be configurable (for example, HedgeDoc). So currently, adding accounts to Authelia is equals to adding accounts to these services at the same time, and there's no way to limit this. I can't find any workarounds so far (other than adding proxy auth for the whole site, which is dumb), the only hope seems to be this feature.

It's something we're considering to do at some stage if there is a way to handle this in a standards compliant way.

That being said we already return sufficient information for the OpenID Connect 1.0 relying parties to do this on their own and there are lots of OpenID Connect 1.0 relying parties which do this correctly and use the identity information provided by providers in the ID Token in their RBAC process.

[mikhail5555]

Hope for this feature! In practice, many services' OIDC integration adds new accounts automatically, and such behavior might not be configurable (for example, HedgeDoc). So currently, adding accounts to Authelia is equals to adding accounts to these services at the same time, and there's no way to limit this. I can't find any workarounds so far (other than adding proxy auth for the whole site, which is dumb), the only hope seems to be this feature.

It's something we're considering to do at some stage if there is a way to handle this in a standards compliant way.

That being said we already return sufficient information for the OpenID Connect 1.0 relying parties to do this on their own and there are lots of OpenID Connect 1.0 relying parties which do this correctly and use the identity information provided by providers in the ID Token in their RBAC process.

Just thinking out loud, but wouldn't it be a decently simple implementation to have an allow/disallow list for users (in database/yaml file) for which identity_providers.oidc.clients they can/cannot be used? (Without breaking any compliance?)

[james-d-elliott]

Yeah it would be relatively simple to prevent access to the client.

But we have to return an error to the relying party so that it's clearly indicated to the relying party that the authorization request associated with the state parameter has completed (unsuccessfully) and there was an issue. We realistically have to make sure we check the spec for these kinds of scenarios (where a user cannot access one of the clients) and specifically use the corresponding error type. Without doing this we could end up in a multitude of scenarios which are not desirable. For example a loop where the relying party decides based on the error they should try another authorization type,

I have read the most likely relevant specs quite a few times and not seen anything specific, but they're vast and very boring (except for a few things like the authorization code flow, PKCE, PAR). I have yet to spend time specifically looking for how to apply this specific idea appropriately.

[mikhail5555]

Thanks for taking your time to answer it (and the detailed answer). This are indeed things I didn't think about yet. Would have expected to just handle it as if the user doesn't exist would have been a nice approach, but yeh, having some weird retry-loop would suck.

I will patiently wait if (or when) you and the team decide to tackle this feature request <3

[kaaass]

Thanks for the reply! I'm not aware that there is a standard compliant problem underlying.

As an inspiration, I investigated how Authentik achieved this. When policy binding is not matched for an Application with an OAuth Provider, Authentik shows a "Permission denied" page to stop the authentication flow without informing relying party (violate rfc6749#section-4.1.2.1).

[james-d-elliott]

Thanks for linking that area of the spec, it's one of the ones I had bookmarked to look at closely in relation to this issue (the other being here).

Authentik shows a "Permission denied" page to stop the authentication flow without informing relying party

Interestingly by the wording in the linked spec section handling it in that way is completely wrong, in fact it's the opposite of what must occur.

If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B

[kaaass]

handling it in that way is completely wrong

Yes, I agree that the relying party should be informed.

I wonder if adding a delayed redirection (say, 5s) in the "Permission denied" page to callback?error=access_denied or another error code could achieve the goal? Also, this could be a configurable feature in the case of the "authentication loop" mentioned above happened.

[james-d-elliott]

Yeah by my reading it's probably access_denied. The issue with the OAuth 2.0 landscape is there are lots of specs which often contradict other specs. This can lead to handling things completely wrong if you're not careful. I had a quick look and think about what's actually technically involved, and it's more than I initially thought since we'll have to ensure this is checked at all of the appropriate places in the flow (pre-consent, consent, authorization).

I don't think displaying a screen and delaying the redirect will be something we can rush however, as this could have a few security implications if not done very carefully. But I'll think more about it as we get through the next couple of releases which will be focused on other OpenID Connect areas and more specifically Webauthn.

[mikhail5555]

It feels like it should only be part of the "authorization" flow (and might to some point even be more user friendly, if you would after an user has attempted to login with oidc and gave convent, give them access). So 'pre-consent' and 'consent' would go as before, and during the authorization step it would throw and not_allowed error to the user (with maybe a chance to switch accounts?) And/or cancel the flow with an 'access_denied' error code

[nullus]

I've tested with Gitea 1.19.2 and it's now possible to configure Additional Scopes, Required Claim Name, and Required Claim Value for Authentication Sources.

To satisfy the requirements as originally specified, configure the options:

• Additional Scopes groups
• Required Claim Name groups
• Required Claim Value gitea

There's also some fun to be had with group mappings to administrators, restricted users, and organisations/teams.

I can still see a use to fine-grained control within Authelia, but I found my way here looking for a way to do just this.

[james-d-elliott]

Agreed that we can add some individual restrictions,but sounds like gitea supports this natively now which is the more desirable option.

[mikhail5555]

Yeh the feature implementation in Gitea is indeed awesome an I have personally been using it since it has been released.

But I know many services still don't support any kind of "required claim", so for those disallowing a user on authelia would still be very nice.

[james-d-elliott]

Linked a PR that partially addresses this, with the intention of it completely addressing this.

[bfd69]

Hello I have the same constraints ! And its great that your taking it into account. Komga and portainer offers openid but without the ability to restrict per group !