Running portal on path rather than subdomain

[darox]

Hi

I wonder whether it is possible to run the portal on the same subdomain but using a path like /auth and protect a path /documents?

Thank you.

[greenpau]

@darox , yes. It is done with “route” directive. what is the config you are currently using?

[terefang]

i have the some problem, i have this working config:

{
	http_port 8080
    https_port 8443
	# debug

	order authenticate before respond
	order authorize before basicauth

	security {
		local identity store localdb {
			realm local
			path users.json
		}


		authentication portal myportal {
			crypto default token lifetime 3600
			crypto key sign-verify 12345678901234567890123456789012
			enable identity store localdb
			cookie domain 127.0.0.1
			ui {
                theme basic
				links {
					"My Website" / icon "las la-star"
				}

    		}
			transform user {
				match origin local
				action add role authp/user
				ui link "Portal Settings" /settings icon "las la-cog"
			}
		}

		authorization policy users_policy {
			set auth url /auth
			allow roles authp/admin authp/user
			crypto key verify 12345678901234567890123456789012
			acl rule {
				comment allow users
				match role authp/user
				allow stop log info
			}
			acl rule {
				comment default deny
				match any
				deny log warn
			}
		}

	}
}

http://127.0.0.1:8080 {
	route /auth* {
		authenticate with myportal
	}

	route {
		authorize with users_policy
		respond * "assetq - admins" 200

	}
}

once i change to this config i get 404 for the login portal

{
	http_port 8080
    https_port 8443
	# debug

	order authenticate before respond
	order authorize before basicauth

	security {
		local identity store localdb {
			realm local
			path users.json
		}


		authentication portal myportal {
			crypto default token lifetime 3600
			crypto key sign-verify 12345678901234567890123456789012
			enable identity store localdb
			cookie domain 127.0.0.1
			ui {
                theme basic
				links {
					"My Website" / icon "las la-star"
				}

    		}
			transform user {
				match origin local
				action add role authp/user
				ui link "Portal Settings" /settings icon "las la-cog"
			}
		}

		authorization policy users_policy {
			set auth url /secure-auth
			allow roles authp/admin authp/user
			crypto key verify 12345678901234567890123456789012
			acl rule {
				comment allow users
				match role authp/user
				allow stop log info
			}
			acl rule {
				comment default deny
				match any
				deny log warn
			}
		}

	}
}

http://127.0.0.1:8080 {
	route /secure-auth* {
		authenticate with myportal
	}

	route {
		authorize with users_policy
		respond * "assetq - admins" 200

	}
}

[greenpau]

@terefang , try this and report the outcome

	route /secure-auth* {
		authenticate /secure-auth* with myportal
	}

[terefang]

@terefang , try this and report the outcome

	route /secure-auth* {
		authenticate /secure-auth* with myportal
	}

still

[j0dan]

This worked great for me. It should be a config example!

[greenpau]

@darox , @j0dan @terefang , I am looking to add testimonial sections to https://authcrunch.com. Could you please write one and send it to me at [email protected]?

[phil3741]

I am facing the exact same issue as @terefang . It seems neither "authenticate /secure-auth* with myportal" nor "authenticate with myportal" will work under a path rather than a subdomain.

The issue is, when i use a subdomain, I can only get an authorization cookie for either the exakt subdomain of the login portal (which is not useful), or for the whole domain including all subdomains. This interferes with other services under my domain and I can only log into some services after deleting the cookies. Specifying a different subdomain for the cookie in the auth portal still issues a wildcard cookie for the whole domain. So it seems I have to route the login portal via a path to get a cookie for this specific subdomain only.

The documentation on this is very sparse and I'm not sure what caddy-security is implicitly assuming or allowing me to do, the approach outlined here does not work for me.

[phil3741]

Ok nevermind I was able to fix it and want to leave my solution here for anyone else facing this problem:

Two things:

• Auth under Path rather than subdomain. Every path apparently has to be under a route {}, be careful where to place your "authenticate" and "authorize" directives. Only place them under the routes, not outside.

• Cookies for Subdomain: Wildcard cookies are apparently issued automatically when you re-use the portal und policy for other subdomains. I created a specific portal and policy for a specific subdomain, and now only cookies for the specific subdomain is set.

So everything works fine now. Here's my obfuscated working config with pocket-ID as OIDC provider:

{
    order authenticate before respond
    order authorize before basicauth

	security {
		oauth identity provider pocketid {
			realm pocketid
			driver generic
			client_id XXX
			client_secret XXX
			scopes openid email profile
			metadata_url "https://XXX.YYY.ZZZ/.well-known/openid-configuration"
		}

		authentication portal admin_auth {
			enable identity provider pocketid
			crypto key sign-verify XXX
			crypto default token lifetime 86400
			cookie lifetime 300
			cookie domain sub.domain.com
		}

		authorization policy admin_policy {
			set auth url /auth
			crypto key verify XXX
			allow roles admin
			validate bearer header
			inject headers with claims
		}
	}
}

sub.domain.com {
	route /auth* {
		authenticate /auth* with admin_auth
	}
	route /api* {
		authorize with admin_policy
		reverse_proxy http://x.y.z.w:3001
	}
	route {
		authorize with admin_policy
		reverse_proxy http://x.y.z.w:82
	}
}