dignajar / another-ldap

Another LDAP is a form-based authentication for Active Directory / LDAP server. Provides Authentication and Authorization for your applications running in Kubernetes.
MIT License
53 stars 14 forks source link
authentication form-based form-based-authentication ingress kubernetes ldap ldap-authentication

Another LDAP

Another LDAP is a form-based authentication for Active Directory / LDAP server.

Another LDAP provides Authentication and Authorization for your applications running on Kubernetes.

Another LDAP works perfect with NGINX ingress controller via (External OAUTH Authentication), HAProxy (haproxy-auth-request) or any webserver/reverse proxy with authorization based on the result of a subrequest.

Docker image Kubernetes YAML manifests codebeat badge release license

Alt text

Features

Installation

git clone https://github.com/dignajar/another-ldap.git
cd another-ldap/kubernetes
kubectl apply -f .

Configuration

Example 1: Authentication

The following example provides authentication for the application my-app.

---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: my-app
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/auth-url: https://another-ldap.another.svc.cluster.local/auth
    nginx.ingress.kubernetes.io/server-snippet: |
      error_page 401 = @login;
      location @login {
        return 302 https://another-ldap.testmyldap.com/?protocol=$pass_access_scheme&callback=$host;
      }
spec:
  rules:
  - host: my-app.testmyldap.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 80

Example 2: Authentication and Authorization

The following example provides authentication and authorization for the application my-app.

---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: my-app
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/auth-url: https://another-ldap.another.svc.cluster.local/auth
    nginx.ingress.kubernetes.io/auth-snippet: |
      proxy_set_header Ldap-Allowed-Groups "DevOps production environment";
    nginx.ingress.kubernetes.io/server-snippet: |
      error_page 401 = @login;
      location @login {
        return 302 https://another-ldap.testmyldap.com/?protocol=$pass_access_scheme&callback=$host;
      }
spec:
  rules:
  - host: my-app.testmyldap.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 80

Example 3: Authentication, Authorization and response headers

The following example provides authentication and authorization for the application my-app and calls the application with the headers x-username and x-groups.

With the headers you can do increase the authorization in the application or display the user logged.

---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: my-app
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/auth-url: https://another-ldap.another.svc.cluster.local/auth
    nginx.ingress.kubernetes.io/auth-response-headers: "x-username, x-groups"
    nginx.ingress.kubernetes.io/auth-snippet: |
      proxy_set_header Ldap-Allowed-Groups "DevOps production environment, DevOps QA environment";
    nginx.ingress.kubernetes.io/server-snippet: |
      error_page 401 = @login;
      location @login {
        return 302 https://another-ldap.testmyldap.com/?protocol=$pass_access_scheme&callback=$host;
      }
spec:
  rules:
  - host: my-app.testmyldap.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 80

Available parameters

All parameters are defined in the config-map and secret manifests.

All values type are string.

The parameter LDAP_SEARCH_FILTER supports variable expansion with the username, you can do something like this (sAMAccountName={username}) and {username} is going to be replaced by the username typed in the login form.

The parameter LDAP_BIND_DN supports variable expansion with the username, you can do something like this {username}@TESTMYLDAP.com or UID={username},OU=PEOPLE,DC=TESTMYLDAP,DC=COM and {username} is going to be replaced by the username typed in the login form.

The parameter COOKIE_DOMAIN define the scope of the cookie, for example if you need to authentication/authorizate the domain testmyldap.com you should set the wildcard .testmyldap.com (notice the dot at the beginning).

Supported HTTP request headers

The variables send via HTTP headers take precedence over environment variables.

HTTP response headers