semaphoreui
oAuth2 / OpenID connect authentication using oauth2-proxy
Idea I was digging into semaphore code, but see that user management is either local or LDAP. What about supporting a oauth2-proxy https://oauth2-proxy.github.io/oauth2-proxy/docs/ instance in front of semaphore instance and then extracting the authenticated username (and role) out of the HTTP-header JWT-token coming from oauth2-proxy. As the JWT-token has to be signed by the IdP-privatekey, Semaphore would just need IdP-publickey to ensure JWT-token was not tempered before extracting the user's details.
Impact
- No more user-list in token-based auth
- Support for decoding JWT-token and a config entry for the JWT-decoder to read the IdP-publickey. Also mapping from JWT-role/claim to internal role may be necessary...again ideally in the JWT-decoder config-section.
- Rights management / Authoriziation to run Ansible playbook should be roled based (rather than user-based) such that any user providing a decodable JWT-token will have or not the right to execute the playbooks based on it JWT-roles/claims.
Note: oauth2-proxy may just be one such proxy, in a K8s deployment, Istio may just do the same https://getindata.com/blog/OAuth2-based-authentication-on-Istio-powered-Kubernetes-clusters/.
Great request! Pomerium is also one of the well known authentication proxies. https://www.pomerium.com/docs/production/security#user-identity-and-context
After reading the existing login code, it may already work as HTTP Header 'Authorization bearer' is already extracted https://github.com/ansible-semaphore/semaphore/blob/f674738f54258b976265f53fe228d45f8ba7efc5/api/auth.go#L21 into a userID: "userID = token.UserID". Basically Semaphore has the concept of local and remote user. Local user are only existing within the DB and are managed by their password as store in the DB (encrypted using 'access_key_encryption'). Remote user, are authenticated using LDAP and exists in the DB without any password. The entered password in the login-mask is used to connect to LDAP server using the provided username/password. If user information are read, userid get extracted from 'uid' mapped field. A user is created in the DB with this uid with flag remote. From there on, this user and rights can be managed within semaphore. Thus for OpenId-Connect/OAuth2, if a token exists in the Header, it may just need to be added to the DB if not yet existing, similar to LDAP.
Extending on existing Nginx proxy to provide HTTPS, one could just follow https://dev.to/apisix/api-security-with-oidc-by-using-apache-apisix-and-microsoft-azure-ad-50h3 to see if this works in front of Semaphore.
- No more user-list in token-based auth
Generally, applications create a user in db when they first see them so they can manipulated by admins (added to teams, linked to builds...).
