This authentication system hits two HTTP endpoints to check and verify the existence of users:
Existance endpoint:
GET http://endpoint/ with Authorization: Basic (username:) =>
Returns 200 if the username/email exists, 4** otherwise
Verification endpoint:
GET http://endpoint/ with Authorization: Basic (username:password) =>
Returns 200 and a signed JWT with the user's username and email address if the username+password validates, 4** otherwise with the body containing an optional error message
The JWT produced by the endpoint must be issued with an issuer matching that configured in the config.yaml, and the audience must be "quay.io/jwtauthn". The JWT is signed using a private key and then validated on the Quay.io side with the associated public key, found as "jwt-authn.cert" in the conf/stack directory.
This resolves an issue where the custom-git trigger's public facing
schema was not the same as the internal metadata schema. Instead of
breaking users, we rework the internal metadata schema to be the same as
the custom-git JSON schema. This commit also updates everything that
used `metadata.commit_sha` including the test database.
This fixes the issue whereby attempting to pull a public repository as an authenticated user with anonymous access disabled caused an unexpected 401. This change also adds tests for a few other use cases to verify we haven't broken anything.
Fixes two issues found with our LDAP handling code. First, we now follow referrals in both LDAP calls, as some LDAP systems will return a referral instead of the original record. Second, we now make sure to handle multiple search result pairs properly by further filtering based on the presence of the 'mail' attribute when we have multiple valid pairs. This CL also adds tests for all of the above cases.
Currently, we use the Quay username via `verify_user` when we go to create the encrypted password. This is only correct if Quay has not generated its own different username for the LDAP user, and fails if it has. We therefore add a new method `confirm_existing_user`, which looks up the federated login for the LDAP user and then runs the auth flow using that username.
