search

vzakharchenko / keycloak-radius-plugin

Make the radius server as part of keycloak SSO
Apache License 2.0
188 stars 46 forks source link

Default Reject, Accept if member of group #652

Open clstrickland opened 2 years ago

clstrickland commented 2 years ago

Is your feature request related to a problem? Please describe. I have multiple groups. For this, I only worry about "WiFi" and "VPN". In my domain, there are some accounts that shouldn't have access to any networking, some that should have WiFi but not VPN, and some that have both.

Describe the solution you'd like I would like to have groups like so:

User's Group Membership Effect
None REJECT all requests (optionally excluding requests missing the Connect-Info attribute)
WiFi REJECT all except Connect-Info == "WiFi"
VPN REJECT all except Connect-Info == "VPN"
WiFi, VPN REJECT all except Connect-Info == "WiFi" or "VPN"

Describe alternatives you've considered I have tried every combination of REJECT_RADIUS, REJECT_Connect-Info, and ACCEPT_Connect-Info that I can think of, but I cannot get this behavior working. I cannot seem to handle the case of users who have no membership (users who do not have access to anything).

clstrickland commented 2 years ago

If someone could just point me to the part of the code where the group membership check happens, I'm sure I can do this myself. If there is also a place where I could put a checkbox to enable or disable my modification, I can add that too.

allahshukur-ahmadzada commented 2 years ago

@clstrickland I wonder did you find workaround for it? we are having same exact issue.

clstrickland commented 2 years ago

@clstrickland I wonder did you find workaround for it? we are having same exact issue.

I found where the default decision is made in the source code. I need to look into adding a gui option to change it. If someone could help with that I'd appreciate it.

It is line 111 in keycloak-plugins\radius-plugin\src\main\java\com\github\vzakharchenko\radius\radius\handlers\attributes\AbstractKeycloakAttributes.java

allahshukur-ahmadzada commented 2 years ago

Thank you for reply, unfortunately not capable enough to help on this.

klasyc commented 2 months ago

One possible workaround, I found, is to evaluate the permission on the RADIUS client side: You assign a custom attribute to a certain user role, and configure the RADIUS client so that this attribute is required.

For example, I am using RADIUS to authenticate VPN users on Mikrotik router. I created a vpn-role in Keycloak and assigned a custom attribute Mikrotik-Group = vpn-l2tp-lan. Mikrotik interprets this attribute as the name of the PPP profile to be used. Then I configured the default PPP profile name to a "black hole" profile, which leads to nowhere. This way, users not belonging to the vpn-role can still connect the VPN, but it simply does not work. It's not a perfect solution, but for me, it's better than assigning users to a radius-reject role...