Hello. https://github.com/caddyserver/caddy/issues/2894 is closed citing this project's existence. Nginx' auth_request directive (https://nginx.org/en/docs/http/ngx_http_auth_request_module.html) works with a simple HTTP response code. Is this kind of functionality available? If yes, can you please direct me to the relevant documentation.

Another question while we're at it. It seems caddy-security is now a single module that includes the former authorize and portal components. Is it still possible to build it without the portal for people who already have an external authentication system in place?

Previously utilizing caddy-authorize, this line for roles worked

allow roles User Admin

How would this be implemented in caddy-security, the docs don't seem to be updated yet. The repo's description includes this snippet, allow roles authp/admin authp/user, but am unsure how to implement this in my existing Caddyfile, specifically I am using organizr's jwt, https://docs.organizr.app/features/server-authentication

New to Caddy, new to OAuth & OIDC so brace yourselves. I'm trying to add OAuth/OIDC authentication to a site. I'm using this config file as a reference. Things are going ok to start with, here's where (I think) I'm at:

1. It looks like Caddy is hitting my metadata_url and finding the jwks_uri field.
2. Once it hits the jwks_uri, it appears to be reading the first key in the array whose kty (key type) is EC.
3. Then I get this message and exit with code 1:

provision security: backend configuration for "myportal" portal failed: failed to fetch jwt keys for OAuth 2.0 authorization server: invalid jwks key: unsupported key type EC for <my_key>

where <my_key> is the EC key found at the jwks_uri. So my questions are:

1. Is the EC kty (keytype) supported?
2. If not, can I direct Caddy to use another key from the jwks_uri?
3. Have I misunderstood this completely?

Describe the issue I'm trying to migrate my config over to Caddy Security, and I think I have most things working now, but I'm getting this message constantly spammed in Caddy's log:

{"level":"error","ts":1642791051.2186432,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed"}

The interesting thing is, it doesn't seem to affect the functionality, because I'm able to login just fine.

Configuration

{ # Global configuration
    acme_dns cloudflare REDACTED
    email REDACTED
    order authorize before reverse_proxy
    order authenticate before authorize
    security {
        credentials email smtp.sendgrid.net {
            address smtp.sendgrid.net:587
            protocol smtp
            username {env.SMTP_USERNAME}
            password {env.SMTP_PASSWORD}
        }
        authentication portal myportal {
            crypto default token lifetime 3600
            # crypto key sign-verify {env.JWT_SECRET}
            backend local /etc/caddy/auth/local/users.json local
                    cookie domain haddock.cc
            ui {
                links { # Icons here -> https://icons8.com/line-awesome
                    "Cloud" https://cloud.haddock.cc icon "las la-cloud"
                    "Media" https://media.haddock.cc icon "las la-photo-video"
                    "Get TV Shows" https://tv.haddock.cc icon "las la-tv"
                    "Get Movies" https://movies.haddock.cc icon "las la-video"
                }
            }
            transform user {
                match origin local
                action add role authp/user
                ui link "Portal Settings" /settings icon "las la-cog"
            }
        }
        authorization policy mypolicy {
            set auth url https://auth.haddock.cc/
            allow roles authp/admin authp/user
        }
    }
    # }
    # crowdsec {
    #     api_url http://crowdsec:8180/
    #     api_key REDACTED
    #     ticker_interval 15s
    # }
}

auth.haddock.cc {
    authenticate * with myportal
}

cloud.haddock.cc {
    authorize with mypolicy
        reverse_proxy nextcloud:80 {
        header_down Strict-Transport-Security "max-age=15552000; includeSubDomains"
    }
    rewrite /.well-known/carddav /remote.php/dav
    rewrite /.well-known/caldav /remote.php/dav
}

media.haddock.cc {
    authorize with mypolicy
    reverse_proxy jellyfin:8096
}

indexers.haddock.cc { # Prowlarr
    authorize with mypolicy
    reverse_proxy prowlarr:9696
}

tv.haddock.cc { # Sonarr
    authorize with mypolicy
    reverse_proxy sonarr:8989
}

movies.haddock.cc { # Radarr
    authorize with mypolicy
    reverse_proxy radarr:7878
}

localhost:8112 { # QBittorrent
    reverse_proxy torrent:8080
}

Version Information

crowdsec v0.2.0
dns.providers.cloudflare v0.0.0-20210607183747-91cf700356a1
http.authentication.providers.authorizer v1.0.1
http.handlers.authenticator v1.0.1
http.handlers.crowdsec v0.2.0
layer4 v0.0.0-20201230212151-6587f40d4eb6
layer4.matchers.crowdsec v0.2.0
layer4.matchers.ip v0.0.0-20201230212151-6587f40d4eb6
security v1.0.1

Expected behavior The Caddy log isn't filled up with the error.

This is a continuation of https://github.com/greenpau/caddy-auth-portal/issues/227#. I think it would be a useful feature to be able to login to Nextcloud with Caddy Security account, and for Caddy Security to automatically create new Nextcloud users based on Caddy Security users. This can be done with OIDC, correct?

Trying to get email working for user registration. I do not see any errors in the logs, but get email error when a user tries to register. Below is the relevant config I am using. Guessing I don't quite have the config correct, but not sure what I am missing.

	security {
		credentials [email protected] {
			username [email protected]
			password <app_passowrd>
		}
		messaging email provider gmail {
			address smtp.gmail.com:587
			protocol smtp
			credentials [email protected]
			sender [email protected] "My Auth Portal"
		}
		authentication portal myportal {
			enable source ip tracking
			cookie lifetime 86400
			crypto default token lifetime 3600
			crypto key sign-verify <redacted>
			cookie domain mydomain.net
			backend local /config/caddy/users.json local
			transform user {
				match roles registered
				require mfa
			}
			registration {
				dropbox /config/caddy/registrations.json
				title "User Registration"
				code "Test"
				require domain mx
				email provider gmail
			}
...

A clear and concise description of what you want to accomplish.

I am trying to authenticate to an (apparently) broken oauth2 server which does not provide the kid in the id_token.

The error in the logs is this:

{"level":"warn","ts":1647959353.70759,"logger":"security","msg":"Authentication failed","session_id":"lbcuPQRrdw8Sdwi7jCuohVyiLsViBe8wXoPGY0zsGrylm","request_id":"759dd92c-3464-4568-9dc8-6e90ffd6b93b","error":"failed validating OAuth 2.0 access token: OAuth 2.0 failed to parse id_token: OAuth 2.0 kid not found in id_token"}

I have verified the id_token (by enabling debug in the caddy config), it does not contain the kid - see the id_token header below:

{
  "typ": "JWT",
  "alg": "RS256"
}

PS: Github and gitlab configurations are working just fine, but I do get the kid in their id_token. PPS: I also had a look on #48 and tried required_token_fields access_token with no luck. I get the same error.

A clear and concise description of what you want to accomplish.

Hi, can we configure the plugin to skip the UI portal and directly redirect the unauthenticated user to OIDC provider login page?

Thanks

Describe the issue

After logging in at https://auth.MYDOMAIN.com, the auth portal sets a cookie without a Max-Age or expires attribute set, meaning it only lives as long as the session. Example set-cookie header in the response of /oauth2/github/authorization-code-callback?code=OAUTH_CODE... after logging in with github:

set-cookie: access_token=eyJhbGciOiJI....; Domain=MYDOMAIN.com; Path=/; Secure; HttpOnly;

Also, the access token itself doesn't seem to work at all with my current configuration, and I get a 401 on the example domain of this config https://sonarr.MYDOMAIN.com, with error logs like:

{"level":"debug","ts":1642792571.8178122,"logger":"security","msg":"token validation error","session_id":"cO9Fu3cuNuNg5ufIugXgZphXU5MSzEFhfByBX0ojPb8","request_id":"26a2f6a9-51fb-4be8-92ac-85f40eefbfd5","error":"token validator: invalid token: keystore: failed to parse token"}
{"level":"error","ts":1642792571.8178322,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed"}

and it just redirects to https://sonarr.MYDOMAIN.com/?redirect_url=https%3A%2F%2Fsonarr.MYDOMAIN.com%2F, rather than redirecting to https://auth.MYDOMAIN.com as I'd expect.

My very very similar config previously using caddy-authorize and caddy-auth-portal worked fine, I've basically just moved around the attributes to be inline with how the new config format looks, and I used the jumpcloud config as my example.

Configuration

{
        debug
        order authorize before basicauth
        email {$CF_EMAIL}
        auto_https ignore_loaded_certs

        security {
                authentication portal mainportal {
                        crypto default token lifetime 2419200
                        crypto key sign-verify {$CADDY_AUTH_TOKEN_SECRET}
                        cookie domain {$DOMAIN}
                        backend local {$CADDY_AUTH_USERS_PATH} local
                        backend github {$CADDY_GITHUB_OAUTH_CLIENT_ID} {$CADDY_GITHUB_OAUTH_CLIENT_SECRET}
                        transform user {
                                exact match sub github.com/johnpyp
                                action add role authp/admin
                                action add role superadmin
                        }
                        transform user {
                                match email [email protected]

                                action add role authp/admin
                                action add role superadmin
                        }
                }

                authorization policy mainpolicy {
                        set auth url https://auth.{$DOMAIN}
                        allow roles admin superadmin authp/admin
                        crypto key verify {$CADDY_AUTH_TOKEN_SECRET}
                }
        }
}

(cf_tls) {
        tls {
                issuer zerossl {
                        resolvers 1.1.1.1
                        dns cloudflare {$CF_API_TOKEN}
                }
        }
}

auth.{$DOMAIN} {
        import cf_tls
        route {
                authenticate * with mainportal
        }
}

(protected_route) {
        {args.0}.{$DOMAIN} {
                import cf_tls
                authorize with mainpolicy
                route {
                        reverse_proxy {args.1}
                }
        }
}

import protected_route sonarr sonarr:8989
// ...

Version Information

Should be latest everything, just pulled a few minutes ago with this docker image:

FROM caddy:2-builder AS builder

RUN xcaddy build \
    --with github.com/greenpau/caddy-security \
    --with github.com/caddy-dns/cloudflare

FROM caddy:2

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

@greenpau, thank you for your awesome work!

Everything seems to be working correctly talking to a quaint oauth2 server.

To have a complete and useful setup, there is one piece of the puzzle that is left for me and that is how do I inject custom headers to downstream from the userinfo object.

And of course, I would really like to be able to use those details in the caddy auth policies.

In my setup I currently use vouch to get additional information from the userinfo object.

I have attempted inject header "X-Custom-Projects" from projects with no success (I get no error either, but I don't seem to get the new header).

I do see two additional headers when I add inject headers with claims to the config, unfortunately that is not quite enough for my setup.

Also inject header "X-Custom-Roles" from roles works (although I get the caddy-secutiry roles, not the ones in the userInfo object).

Below is an example of userInfo:

{
    "sub": "37",
    "email": "[email protected]",
    "email_verified": true,
    "name": "john.doe.developer",
    "preferred_username": "john.doe.developer",
    "zoneinfo": "Europe\\/Berlin",
    "profile": {},
    "display_name": "John Doe",
    "groups": [
        "PROJ1",
        "PROJ2",
        "PROJ3",
        "mailhog",
        "snapshots",
        "developer:dev-004",
        "developer:mailhog",
        "developer:snapshots",
        "developer:PROJ1",
        "developer:PROJ2",
        "developer:PROJ3"
    ],
    "departments": [
        "DEPT1"
    ],
    "projects": [
        "PROJ1",
        "PROJ2",
        "PROJ3",
    ],
    "services": [
        "dev-004",
        "mailhog",
        "snapshots"
    ],
    "roles": [
        "authenticated",
        "nomfa"
    ]
}

Thank you for this awesome project, unfortunately I am having some issues with getting it to run with an LDAP backend:

Describe the issue

An attempt to log in over Caddy Security with an LDAP backend consisting of glauth-ui for management and glauth (https://github.com/glauth/glauth) as the LDAP provider fails with right credentials. The credentials were succesfully used by other means of connecting to glauth

Configuration

Paste full Caddyfile below:

(Domain names and unrelated services cut out)

{
  acme_ca https://acme-v02.api.letsencrypt.org/directory
  email   [...]
  debug

  security {
    authentication portal myportal {
      crypto default token lifetime 3600
      crypto key sign-verify [...]
       
      backends {
        ldap_backend {
          method ldap
          realm [...]
          servers {
            ldap://login_system_glauth_1:389 ignore_cert_errors posix_groups
          }
          attributes {
            name givenname
            surname sn
            username name
            #member_of primarygroup #memberOf
            email mail
          }
          username "CN=[...],DC=[...],DC=[...],OU=[...]"
          password "[...]"
          search_base_dn "DC=[...],DC=[...],OU=[...]"
          search_filter "(|(name=%s)(mail=%s))"
          groups {
            "CN=people,OU=[...],DC=[...],DC=[...]" people
            "CN=5501,OU=[...],DC=[...],DC=[...]" people2
          }
        }
      }

      cookie domain [...]
      ui {
        links {
          "My Website (super secret)" [...]/foo
          "My Identity" "/whoami"
        }
      }
    }

    authorization policy mypolicy {
      set auth url /auth/
      crypto key sign-verify [...]
      allow roles people people2
    }
  }
}

[...]:443/* {
  #Protected super secret part of website
  redir /foo /foo/
  handle_path /foo/* {
    route {
      authorize with mypolicy
    }
    respond * "foobar website" 200
  }

  handle {
    route /auth* {
      authenticate * with myportal
    }

    #unprotected landing page
    reverse_proxy nginx:80
  }
}

Version Information

Provide output of caddy list-modules -versions | grep git below:

Caddy version is v2.4.6 running in docker. Above command yields no results with grep git. Without it it looks like

[...] 

  Standard modules: 83

http.authentication.providers.authorizer v1.0.6
http.handlers.authenticator v1.0.6
security v1.0.6

  Non-standard modules: 3

  Unknown modules: 0

Expected behavior

A successful login

Additional context

Caddy logs:

[Note: User entry follows]
caddy_1  | {"level":"debug","ts":1643228260.8880885,"logger":"security","msg":"LDAP dialer setup succeeded","server":"ldap://login_system_glauth_1:389"}
caddy_1  | {"level":"debug","ts":1643228260.8909764,"logger":"security","msg":"LDAP binding succeeded","server":"ldap://login_system_glauth_1:389"}
caddy_1  | {"level":"debug","ts":1643228260.8923666,"logger":"security","msg":"LDAP search succeeded","server":"ldap://login_system_glauth_1:389","entry_count":0,"search_base_dn":"DC=[...],DC=DE,OU=[...]","search_user_filter":"(|(name=[foo])(mail=[foo]))","users":[]}
caddy_1  | {"level":"debug","ts":1643228260.9456468,"logger":"security","msg":"user authorization sandbox","sandbox_id":"AGrfuqfC377A6TzZYt6mYPFlKR9gK3YF8b93QH11stXLMh","sandbox_secret":"Edtvxjl3AIukviHXjEjstxPimZRzFRgEdQgjKUPU","sandbox_partition":"","checkpoints":[{"name":"Authenticate with password","type":"password"}]}
caddy_1  | {"level":"debug","ts":1643228260.9464517,"logger":"security","msg":"next user authorization checkpoint","session_id":"pAJ0OR8hQL5NuWH0638JbOpq7JozxxTp6zfjm7","request_id":"5ce045e3-cdb6-4c07-8940-a615318dca25","data":{"action":"auth","title":"Password Authentication","view":"password_auth"}}

[Note: Password entry]
caddy_1  | {"level":"debug","ts":1643228269.0140665,"logger":"security","msg":"user authorization sandbox","sandbox_id":"AGrfuqfC377A6TzZYt6mYPFlKR9gK3YF8b93QH11stXLMh","sandbox_secret":"Edtvxjl3AIukviHXjEjstxPimZRzFRgEdQgjKUPU","sandbox_partition":"password-auth","checkpoints":[{"name":"Authenticate with password","type":"password"}]}
caddy_1  | {"level":"debug","ts":1643228269.0155284,"logger":"security","msg":"LDAP dialer setup succeeded","server":"ldap://login_system_glauth_1:389"}
caddy_1  | {"level":"debug","ts":1643228269.01613,"logger":"security","msg":"LDAP binding succeeded","server":"ldap://login_system_glauth_1:389"}
caddy_1  | {"level":"warn","ts":1643228269.0173078,"logger":"security","msg":"user authorization checkpoint failed","session_id":"pAJ0OR8hQL5NuWH0638JbOpq7JozxxTp6zfjm7","request_id":"3a4848b6-9f80-47c5-bca7-e8bab3a71cf2","error":"Password authentication failed. Please retry"}

Structure of glauth users:

  name = "fbar"
  givenname = "foo
  sn = "bar"
  mail = "[email protected]"
  unixid = 5003
  primarygroup = 5501
  passsha256 = "foofoobarbar"
  otherGroups = [ 5551 ]

glauth output:

glauth_1      | 19:45:40.200821 Bind ▶ DEBU 025  "level"=6 "msg"="Bind request"  "basedn"="dc=[...],dc=de,ou=[...]" "binddn"="cn=[management user specified in Caddyfile],dc=[...],dc=de,ou=[...]" "src"={"IP":"172.28.0.7","Port":38570,"Zone":""}
glauth_1      | 19:45:40.201705 Bind ▶ DEBU 026  "level"=6 "msg"="Bind success"  "binddn"="cn=[management user specified in Caddyfile],dc=[...],dc=de,ou=[...]" "src"={"IP":"172.28.0.7","Port":38570,"Zone":""}
glauth_1      | 19:45:40.202217 Search ▶ DEBU 027  "level"=6 "msg"="Search request"  "basedn"="dc=[...],dc=de,ou=[...]" "binddn"="cn=[management user specified in Caddyfile],dc=[...],dc=de,ou=[...]" "filter"="(|(name=[foo])(mail=[foo]))" "scope"=2 "searchbasedn"="dc=[...],dc=de,ou=[...]" "src"={"IP":"172.28.0.7","Port":38570,"Zone":""}
glauth_1      | 19:45:40.203287 Search ▶ DEBU 028  "level"=6 "msg"="AP: Search OK"  "filter"="(|(name=[foo])(mail=[foo]))"
glauth_1      | 19:45:44.544377 Bind ▶ DEBU 029  "level"=6 "msg"="Bind request"  "basedn"="dc=[...],dc=de,ou=[...]" "binddn"="cn=[management user specified in Caddyfile],dc=[...],dc=de,ou=[...]" "src"={"IP":"172.28.0.7","Port":38572,"Zone":""}
glauth_1      | 19:45:44.544462 Bind ▶ DEBU 02a  "level"=6 "msg"="Bind success"  "binddn"="cn=[management user specified in Caddyfile],dc=[...],dc=de,ou=[...]" "src"={"IP":"172.28.0.7","Port":38572,"Zone":""}
glauth_1      | 19:45:44.544891 Search ▶ DEBU 02b  "level"=6 "msg"="Search request"  "basedn"="dc=[...],dc=de,ou=[...]" "binddn"="cn=[management user specified in Caddyfile],dc=[...],dc=de,ou=[...]" "filter"="(|(name=nobody)(mail=nobody))" "scope"=2 "searchbasedn"="dc=[...],dc=de,ou=[...]" "src"={"IP":"172.28.0.7","Port":38572,"Zone":""}
glauth_1      | 19:45:44.545011 Search ▶ DEBU 02c  "level"=6 "msg"="AP: Search OK"  "filter"="(|(name=nobody)(mail=nobody))"

A clear and concise description of what you want the system to do.

Add api key directive for user setup.

Currently, there is no way to setup API key as part of user definition.

What are the Caddyfile directives that need to be added.

Add Caddyfile directive:

{
        security {
                local identity store localdb {
                        realm local
                        path /etc/caddy/users.json
                        user jsmith {
                                name John Smith
                                email [email protected]
                                password "bcrypt:10:$2a$10$dq8cptF.px6vu58EvfV.S.endhEsPz94u9ufusSAWeU.xagRJcSDi" overwrite
                                roles authp/admin authp/user
                                api key "MyKey" "bcrypt:10:$2a$10$qOZSVOxX4COg.owU1iRSAeGbNyAd0f372EiR7qARADv0xeac4Zzua"
                        }
                }
        }
}

The above api key directive should create an entry similar to the below in /etc/caddy/users.json for jsmith user.

"api_keys": [
  {
    "id": "fRQV7eGqQYeXeLT9KtiNhHXHimSi9DfNTMrvcmQU",
    "prefix": "iGYv8a6e45ny0Y2x04hrvIAp",
    "usage": "api",
    "comment": "MyKey",
    "payload": "$2a$10$qOZSVOxX4COg.owU1iRSAeGbNyAd0f372EiR7qARADv0xeac4Zzua",
    "expired_at": "0001-01-01T00:00:00Z",
    "created_at": "2022-12-29T20:38:12.154720627Z",
    "disabled_at": "0001-01-01T00:00:00Z"
  }
],

Hello! I have a use-case wherein I am looking to both verify and validate (expiry) a JWT on Caddy. I was wondering if there is a way to check if an incoming JWT is still valid or is expired. From what I understand, the Token Verification only verifies the signature (?) and while the ACLs seem to be a promising place for the token expiry validation, the documentation mentions no such capability within the "condition" block.

An idea could be to support a comparison operator within the "condition" block and compare "exp" field to current time via placeholder {time.now.unix} and allow or deny request based on the result.

Would greatly appreciate any inputs or direction with this. Thank you!

A clear and concise description of what you want to accomplish.

Or passkeys without the key-keepers :)

Passkeys are password less logins and I would like to support this

hanko is a golang implementation that has a web gui template and allows you to have the passkeys saved on your server rather than the Apple, google, Microsoft gatekeepers .

https://www.hanko.io/

https://github.com/teamhanko

Banks are already starting to integrate this. It’s not perfect yet .

Would be awesome if we could have this .

A clear and concise description of what you want to accomplish.

I use Caddy for authorization with Azure Active directory. In the original access token I see a upn claim field that I want to use later in a header field (using: inject header "X-User" from upn). But it seems I cannot get access to the claim fields. How can I add more original claim fields to the access token information generated by Caddy?

use case

the first attribute from a ldap groups dn is already the role attribute we want, eg: cn=Role1,ou=Groups,dc=example,dc=com

suggested implementation

instead of

groups {
	"ou=mathematicians,dc=example,dc=com" authp/admin
	"ou=scientists,dc=example,dc=com" authp/user
}

allow the config syntax

groups auto_map

the underlying code should then pull the first attribute from each retrieved ldap group into a role, eg:

• "ou=mathematicians,dc=example,dc=com" –> mathematicians
• "ou=scientists,dc=example,dc=com" –> scientists

this can be done by extracting the text between the first '=' (equal) and the first ',' (comma) signs.

alternative

for some people it might be better to pull the entire dn into a role, eg:

• "ou=mathematicians,dc=example,dc=com" –> ou=mathematicians,dc=example,dc=com
• "ou=scientists,dc=example,dc=com" –> ou=scientists,dc=example,dc=com

allow the config syntax for this:

groups auto_dn_map