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

I'm using the recommended config but endpoints are always authorized #308

Open
alphajoza opened this issue Jan 13, 2024 · 0 comments
Open
Assignees
Labels
need triage question Further information is requested

Comments

@alphajoza
Copy link

I got the the example config provided over here and modified it as following:

  • I changed the default http and https ports.
  • I removed tls_config section so that caddy itself request for certificates.
  • I commented out password_recovery_enabled yes because with that, authp gave me this error:
INFO    using adjacent Caddyfile
Error: adapting config using caddyfile: parsing caddyfile tokens for 'security': unsupported subdirective for security.authentication.portal.ui: password_recovery_enabled, at Caddyfile:31

So my Caddyfile is like this (I've change the domains here obviously):

{
	http_port 80
	https_port 443
	debug

	order authenticate before respond
	order authorize before basicauth

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

		oauth identity provider github {env.GITHUB_CLIENT_ID} {env.GITHUB_CLIENT_SECRET}

		authentication portal myportal {
			crypto default token lifetime 3600
			crypto key sign-verify {env.JWT_SHARED_KEY}
			enable identity store localdb
			enable identity provider github
			cookie domain example.com
			ui {
				links {
					"My Website" https://test.example.com:443/ icon "las la-star"
					"Guests" https://test.example.com:443/guests icon "las la-star"
					"Users" https://test.example.com:443/users icon "las la-star"
					"Admins" https://test.example.com:443/admins icon "las la-star"
					"My Identity" "/whoami" icon "las la-user"
				}
				# password_recovery_enabled yes
			}
			transform user {
				match origin local
				action add role authp/user
				ui link "Portal Settings" /settings icon "las la-cog"
			}
			transform user {
				match realm github
				match sub github.com/greenpau
				action add role authp/user
			}
		}

		authorization policy guests_policy {
			# disable auth redirect
			set auth url https://auth.example.com:443/
			allow roles authp/admin authp/user
			crypto key verify {env.JWT_SHARED_KEY}
			acl rule {
				comment allow guests only
				match role guest authp/guest
				allow stop log info
			}
			acl rule {
				comment default deny
				match any
				deny log warn
			}
		}

		authorization policy users_policy {
			set auth url https://auth.example.com:443/
			allow roles authp/admin authp/user
			crypto key verify {env.JWT_SHARED_KEY}
			acl rule {
				comment allow users
				match role authp/user
				allow stop log info
			}
			acl rule {
				comment default deny
				match any
				deny log warn
			}
		}

		authorization policy admins_policy {
			set auth url https://auth.example.com:443/
			allow roles authp/admin authp/user
			crypto key verify {env.JWT_SHARED_KEY}
			acl rule {
				comment allow users
				match role authp/user
				allow stop log info
			}
			acl rule {
				comment default deny
				match any
				deny log warn
			}
		}
	}
}




auth.example.com {
	route {
		authenticate with myportal
	}
}

test.example.com {
	route /guests* {
		authorize with guests_policy
		respond * "assetq - guests only" 200
	}

	route /users* {
		authorize with users_policy
		respond * "assetq - users" 200
	}

	route /admins* {
		authorize with admins_policy
		respond * "assetq - admins" 200
	}

	route {
		respond "assetq is running"
	}
}

I can access auth.example.com and login with the initial credentials created by caddy but even if I sign out, all the routes under test.example.com are still accessible and they never get redirected to auth.example.com (even with different IPs and browsers without cached cookies)

@alphajoza alphajoza added need triage question Further information is requested labels Jan 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need triage question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants