Deny administration paths externally? /if/admin/?

[rwjack]

Describe your question/ Since authentik runs as an SSO provider for external users to authenticate, it has to be exposed to the internet. In my use case, only local users should have administrator access. External users should only be using authentik to sign into preconfigured applications/services.

In order to accomplish this, which paths should be restricted to the internal network? Rather, which paths should be exposed to the internet, so external users can only authenticate, without being able to access any administration areas of authentik?

• authentik version: [2023.6]

[joriskt]

+1. It would be good to add this to the docs. I was not able to find any page on hardening an Authentik setup.

I personally expose services to myself via Tailscale (i.e.: a VPN) and this information would also be beneficial in my scenario.

[BeryJu]

The admin interface itself is just an html page so you'd need to block some API paths, however there's a decent overlap with the APIs the user interface uses so it might not have the desired result

[rwjack]

@BeryJu Guess that leaves space for improvement.

Any recommendations on the best possible solution, for the time being?

[x140x1n]

if you use a reverse proxy block access to the /if/admin/ path

i.e. nginx:

if ($request_uri ~* (/if/admin)){
        return 403;
}

would that work as a temporary solution?

[rwjack]

That would be the simplest and most elegant solution, although it was my understanding that blocking /if/admin externally would simply break authentik for regular users.

[authentik-db-cooper]

@rwjack Apologies on the delayed response.

If your talking about external users that still hit the login page, I would think it would introduce more complexities by locking down API endpoints to specific IP ranges. This could break potential upgrades in the future and it might still be possible to miss API endpoints if new admin ones are rolled out.

Instead I would highly recommend a defense in depth solution:

• Enabled and mandate MFA
• Rotate credentials
• Monitor logs from authentik for unusual or unknowns (IPs, users, routes, etc)
• Apply rate limiting at the load balancer level (or however your hosting Authentik)

[BeryJu]

You can also follow these steps here https://docs.goauthentik.io/docs/security/security-hardening, as blocking access to just /if/admin/ doesn't change anything security-wise (it's just the frontend that's being blocked, the API that frontend uses are still available)

[rwjack]

@authentik-db-cooper No worries man.

My authentik serves only a single user, which is me, so I don't have to worry about MFA, rotating creds, or monitoring the logs, as I already do that on a regular basis. Crowdsec rate limiting is enabled as well, but once I feel confident enough everything is working as it should, the goal is to share such an SSO solution with friends and family.

Even though I didn't dig into the code to fully understand how the /if/admin endpoint works, as a layman, to me it just makes sense to completely split the user and admin workflows, and make it truly defense by design, not just in depth.

This could break potential upgrades in the future and it might still be possible to miss API endpoints if new admin ones are rolled out.

This is exactly why I'm saying by design, because if admins have to fiddle around with blocking endpoints, it will end up being more of a mess than a solution.

Perhaps by hosting two separate instances? Which already seems to be the case with the provided docker compose, as it contains a main and a worker node.

To reiterate, I have no idea how the authentik works on the backend, and if such a solution is possible, feasible or even makes sense, just giving my 2 cents here.

[authentik-db-cooper]

@rwjack we sincerely value your input and appreciate any advice you send our way.

From a security standpoint, I see why it might be beneficial to break out the admin section into a entirely separate section. From a developer and org standpoint, I see why its interchanged now.

The bigger issue here is supporting all different use cases. For a singular or family use case it makes perfect sense. For a corporation with 1000's of employees and 100's of subnets, it present a bit more complication.

As much as the age old standard of sticking elevated apps behind VPN's, it does present a ongoing maintenance challenge for administrators among other network oddities that always eventually pop up and end up intermingling all the subnets just to get a solution to work.

The main point of concern here (atleast that im aware of) is a malicious actor enumerating the API endpoints. As this is always a concern, there a ton of products available to help notify when this happens (and potentially block the IP). Suricata for example can insert a block rule on the firewall if the IP is attempting to brute force.

At Authentik we view this as a level above problem (at the serving machine) were you can implement all the security measure you see fit. Not only will this yield much more fruitful data, but it leaves authentik to do what it does best - handle SSO.

We do offer IP based reputation policies, that could come into play here if you see fit.

I know its not the answer your looking for, but i hope it shed some light into the thought process on this side.

[rwjack]

The bigger issue here is supporting all different use cases. For a singular or family use case it makes perfect sense. For a corporation with 1000's of employees and 100's of subnets, it present a bit more complication.

I'm not following? How does separating the admin and user endpoints introduce complication for corporations, if that's what you're saying?

I think this use case would work better for them too, as big companies are expected to scrutinize the security of a product even more than a single homelab user.

As much as the age old standard of sticking elevated apps behind VPN's, it does present a ongoing maintenance challenge for administrators among other network oddities that always eventually pop up and end up intermingling all the subnets just to get a solution to work.

If this is what you mean by it would present a bit more complication, when separating the admin and the user endpoint; Would it not be possible to do something like this:

admin endpoint(internal) ->(rw) | -> db <-(ro) user endpoint(dmz) - where "|" is a subnet separation.

No tinkering required, all users are allowed to the external/dmz endpoint, and only the admin subnet can access the admin instance and functionalities.

The main point of concern here (atleast that im aware of) is a malicious actor enumerating the API endpoints.

Far more from that, they can just look the endpoints up since Authentik is open source. The issue I'm thinking of, is if it's exposed, it's prone to risk.

My main point, with an abstract example: If I'm never going to leave my home, I don't ever need a keyhole on the outside of my door. Translated to this use case: If nobody is going to be accessing the admin endpoints externally, then there should be no need of having the admin endpoint functionalities available externally.

Although thinking about it now, if your main customer are businesses, which will likely be operating in the cloud, then it kind of makes sense to group all the functionality into one place, since those admins will likely be accessing the interface from "outside" the "cloud" infrastructure anyways, and since businesses are be the ones that actually pay licensing fees, it makes sense to look out for their needs primarily, but still, I think my solution, if possible to implement without rewriting the whole thing, would fit the needs of both sides.

Anyways, I'm sure you guys will think of something good. I'm not seeing anything else simple/good/secure/well functioning in the open source SSO field, so you still have a head start I'd say.