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

Radius provider #5262

Closed
electrofloat opened this issue Apr 15, 2023 · 2 comments
Closed

Radius provider #5262

electrofloat opened this issue Apr 15, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@electrofloat
Copy link

Is your feature request related to a problem? Please describe.
I see that in 2023.4 there's a new radius provider, although I don't exactly understand some of the docs related to it here:
https://goauthentik.io/docs/providers/radius/

For example. It is stated that "The RADIUS provider only supports the clear-text protocol:" I can only assume that by protocol it means authentication protocol. And if that is what that means then the only auth protocol which is clear-text is PAP. AFAIK all the others are encrypted (one way or another). So does that above sentence mean only PAP is supported?

The next sentence I don't really understand, is this one:
" However as all protocols besides Clear-text, EAP-MD5 and EAP-PWD require the password to be stored in the database in clear text, they are not supported."

So which one is not supported? Clear-text (there is no auth protocol named clear-text, maybe this should be PAP?), EAP-PWD - as the table suggests above - supports (at least in theory) the password being Salted SHA1, or unix-crypt-ed (that is theory, because in my experience only clear-text password is supported for the devices I tried) or EAP-MD5 which is the one that only supports password stored in clear-text. So that sentence should be clarified a bit.

Anyways... the usual way to handle this kind of nonsense of radius requiring password in cleartext is that there's a secondary pass/key that can be set by the user (and clearly stated that is not a usual password and stored in plaintext) which will only be used by radius authentication. That way the "real" password (which is used by authentik everywhere else) can still be hashed with whatever way it seems necessary, and radius could still be used with that key stored as cleartext.

Describe the solution you'd like
I'd like to have a way to define - for every user - a radius key (I would not call it a password, so users don't confuse it with one), which would only be used for authenticating to the radius server.
Users would be able to change this of course for themselves, it would be a cleartext entry, clearly stated that it is stored as cleartext, don't use anything that would be used for a password.
Maybe even put a button next to it, to autogenerate a simple, memorable key (eg. not too long X random words)

Describe alternatives you've considered
There's just no alternative to radius clear-text requirement nonsense for now, not until they start to think about passwords needing to be stored hashed everywhere, always.

Additional context
I'd really like to use authentik's radius server with eap-pwd auth.

@electrofloat electrofloat added the enhancement New feature or request label Apr 15, 2023
@BeryJu
Copy link
Member

BeryJu commented Apr 16, 2023

Hi,

indeed what's referred to as clear-text in the docs is meant to be PAP. The reason nothing besides PAP is supported currently is that https://github.com/layeh/radius doesn't support any of the EAP-* protocols

I previously considered having an explicit clear text key for this use-case, however that would require a bunch of additional logic since we still want the Radius outpost to use the flow executor

@BeryJu
Copy link
Member

BeryJu commented May 2, 2024

See layeh/radius#120 and #8949 and #5328

@BeryJu BeryJu closed this as completed May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants