diff --git a/content/blog/authentik-block-akadmin-internet.md b/content/blog/authentik-block-akadmin-internet.md
index cb2092b..ff070fc 100644
--- a/content/blog/authentik-block-akadmin-internet.md
+++ b/content/blog/authentik-block-akadmin-internet.md
@@ -1,27 +1,78 @@
 ---
 title: "Block Authentik admin user access from the Internet"
-tags: ["authentik", "security"]
+tags: ["authentik", "sso", "idp", "admin"]
 categories: ["recipe", "security"]
-date: 2025-03-01T01:06:12+01:00
+description: How to restrict Authentik admin access from internal networks only
+date: 2025-10-13T00:00:00+02:00
 author: "Ettore Dreucci"
-draft: true
+draft: false
 ---
 
 ## How to restrict Authentik admin access from internal networks only
 
-I've recently set up an [Authentik](https://goauthentik.io/) instance in my homelab for SSO authentication. I really like it and I've set it up for authentication with several services that I'm self-hosting, including some that are internet-facing. That required exposing Authentik too, as I need to be able to reach it from outside my network when authenticating to these services.
+I've recently set up an [Authentik](https://goauthentik.io/) instance in my homelab for SSO authentication. I really like it, and I've set it up for authentication with several services that I'm self-hosting, including some that are internet-facing. That required exposing Authentik too, as I need to be able to reach it from outside my network when authenticating to these services.
 
 Exposing to the Internet a core service like an identity provider is not a light-hearted job and even if Authentik is suggesting [some ways](https://docs.goauthentik.io/docs/security/security-hardening) to harden a deployment, I wanted to make sure that admin access is strictly restricted to internal networks only.
 
 ### Expose Authentik
 
-You may argue that the best way to access such a sensitive service like one that provides authentication and authorization would be by using a VPN tunnel, so that you don't have to expose it to the outside world at all. However, VPN adds a layer of complexity, and when hosting services used also by non tech-savy relatives, limiting the degree of difficulty in accessing those surely helps preventing sunday morning phone calls.
+You may argue that the best way to access such a sensitive service like one that provides authentication and authorization would be by using a VPN tunnel, so that you don't have to expose it to the outside world at all. However, VPN adds a layer of complexity, and when hosting services used also by non tech-savy relatives, limiting the degree of difficulty in accessing those surely helps to prevent sunday morning phone calls.
 
 In exposing internal services to the Internet I'm currently using [NGINX](https://nginx.org/) as a reverse proxy. That is the case as well for exposing my Authentik instance.  
 Using a reverse proxy I'm also able to manage the SSL context, and therefore certificates, in a single place: this makes possible enabling (and forcing) HTTPS encryption without having to configure public, trusted, SSL certificates on every service.
 
 #### Restrict admin interface
 
+As a first layer of security, a simple yet effective action could be restricting access to the Authentik admin interface from internal network only.
+
+Doing such a think is extremely easy using NGINX: in the server block I've defined a separate location for the `/if/admin/` path, allowing connections from the local network CIDR and denying the rests.
+
+```
+location /if/admin/ {
+    ...
+    allow 192.168.0.0/24;
+    deny all;
+    ...
+}
+```
+
+That two simple instructions will prevent access to any sub-path of `/if/admin/` coming from IP addresses outside `192.168.0.0/24` subnet.
+
 ### Limit admin access
 
-#### Prevent admin login from outside local networks
\ No newline at end of file
+The above method could be further extended to additional paths, however that is just preventing access to the WEB admin interface, while leaving admin API still open.
+
+Another approach that would further strengthen the security posture could be preventing the admin user(s) from logging in from external networks. 
+
+#### Prevent admin login from outside local networks
+
+In order to deny login to admin user(s) from external networks we must:
+1. **Create a policy to deny the login:**
+   1. On Authentik admin interface go to `Customization -> Policies`
+   2. Click on `Create`
+   3. Select `Expression Policy`
+   4. Under `Policy-specific settings` paste the following content in the `Expression` box:
+    ```python
+    user = context['pending_user']
+    groups = [group.name for group in user.ak_groups.all()]
+    admin_group = "authentik Admins"
+    
+    if admin_group in groups and not ak_client_ip.is_private:
+      return False
+    return True
+    ```
+2. Assign the policy to the authentication flow's login stage:
+   1. Go to `Flows and Stages -> Flows`
+   2. Click on the authentication flow you're using (i.e. `default-authentication-flow`)
+   3. Go to `Stage Bindings`
+   4. Expand the `User Login Stage`
+   5. Click on `Bind existing Policy / Group / User`
+   6. Select `Policy` and choose the one created before
+   7. Ensure the failure result is set as `Don't pass`
+   8. Click on `Create`
+
+### End
+
+Now, if you've managed to not lock you out of your own Authentik instance, admin interface and admin login should be allowed from internal network only.
+
+Would that suffice for feeling safe? Not at all. But it should at least be a valid starting point!
\ No newline at end of file