Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OIDC: Client RBAC/Access Control over users and groups #2621

Closed
mikhail5555 opened this issue Nov 23, 2021 · 23 comments · Fixed by #5486
Closed

OIDC: Client RBAC/Access Control over users and groups #2621

mikhail5555 opened this issue Nov 23, 2021 · 23 comments · Fixed by #5486
Labels
area/openid-connect OpenID Connect 1.0 / OAuth 2.0 related features/bugs priority/4/normal Normal priority items status/ready Is ready to try/merge type/feature Request for adding a new feature

Comments

@mikhail5555
Copy link

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.

@mikhail5555 mikhail5555 added the type/feature Request for adding a new feature label Nov 23, 2021
@JaneJeon
Copy link

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

@nightah
Copy link
Member

nightah commented Nov 25, 2021

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
Copy link

JaneJeon commented Nov 25, 2021

@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
Copy link
Member

james-d-elliott commented Nov 25, 2021

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.

@james-d-elliott james-d-elliott added status/needs-design Requires formal design process via a discussion or feature request priority/4/normal Normal priority items labels Nov 25, 2021
@mikhail5555
Copy link
Author

@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
Copy link
Member

clems4ever commented Jan 11, 2022

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

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

@clems4ever clems4ever changed the title OIDC Access control Extend Access control to allow/deny people to use OIDC (Gitea) Jan 11, 2022
@mikhail5555
Copy link
Author

@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.
image
image

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.

@james-d-elliott james-d-elliott added the area/openid-connect OpenID Connect 1.0 / OAuth 2.0 related features/bugs label Aug 7, 2022
@kaaass
Copy link

kaaass commented Jan 5, 2023

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

james-d-elliott commented Jan 5, 2023

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
Copy link
Author

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
Copy link

kaaass commented Jan 6, 2023

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
Copy link
Member

james-d-elliott commented Jan 6, 2023

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
Copy link

kaaass commented Jan 6, 2023

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
Copy link
Member

james-d-elliott commented Jan 6, 2023

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
Copy link
Author

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

@james-d-elliott james-d-elliott changed the title Extend Access control to allow/deny people to use OIDC (Gitea) OIDC: Client RBAC/Access Control over users and groups Jan 13, 2023
@nullus
Copy link

nullus commented Jun 1, 2023

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
Copy link
Member

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

@mikhail5555
Copy link
Author

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
Copy link
Member

james-d-elliott commented Jun 1, 2023

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

james-d-elliott added a commit that referenced this issue Jul 31, 2023
This adds support to adjust the authorization policy on specific clients per subject in a reusable way.

Closes #2621

Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
@james-d-elliott james-d-elliott added status/ready Is ready to try/merge and removed status/needs-design Requires formal design process via a discussion or feature request labels Jul 31, 2023
@bfd69
Copy link

bfd69 commented Nov 15, 2023

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 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/openid-connect OpenID Connect 1.0 / OAuth 2.0 related features/bugs priority/4/normal Normal priority items status/ready Is ready to try/merge type/feature Request for adding a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants