Zugriffssteuerung für Webapps per Single Sign On

Konfiguration einer Single-Sign-On-Umgebung für eine Webapp - hier Alterra PIM/MDM

Aufgabenstellung: Benutzer, die mit einer Webanwendung wie Alterra MDM/PIM arbeiten, sollen der Webanwendung über ihr bereits vollzogenes Windows/Linux/Android/Apple Login bekannt sein und mit dem entsprechenden Benutzer-Account in der Webapp arbeiten können.

Passwörter sollen dabei nicht über das Netz übertragen werden, sondern die Vertrauensstellung per Anfrage beim Kerberos-Server (unter Windows: Active Directory Server) geklärt werden.

Vorteile:

Sicherheit: Passwörter können nicht von Dritten abgegriffen werden.

Verwaltung: Systemadministratoren müssen Zugriffsberechtigungen nur einmal zentral verwalten und können diese auch zentral wieder entziehen.

Beteiligte Komponenten:

Clients: Windows PC, Mac, Linux PC, Android

Windows Domain-Contoller (alternativ Kerberos Server unter Linux)

Webanwendung - hier das webbasierte Alterra PIM auf Apache Webserver.

 

Schaubild: Single-Sign-On - die Vertrauensstellung wird über den Kerberos-Server (hier Active Directory Server) sichergestellt.

Szenario: Windows-PC - Active Directory Server - Webserver (Linux Apache)

 A: Client-Rechner (PC, Smartphone, Tablet) mit Browser (Firefox, Chrome/Chromium oder Internet Explorer)

B: 

DC: MS-Active Directory (=Kerberos)

KDC: MIT-Kerberos-Server

C: Apache Webserver (mit mod auth_kerb) und  Samba-Server und Kerberos-Client:

Konfiguration Kerberos Client (Webserver)

/etc/krb5.keytab

[libdefaults]
    default_realm = SEPIA.DE
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
    fcc-mit-ticketflags = true
    default_keytab_name = FILE:/etc/krb5.keytab 

[realms]
   SEPIA.DE = {
          kdc = dc.sepia.de
          default_domain = sepia.de
          ktpasswd_server = dc.sepia.de
     }
 
[domain_realm]
     .sepia.de = SEPIA.DE

Konfiguration SAMBA (auf Linux Webserver):

 

Konfiguration SAMBA (zur Aufnahme des Servers in eine Windows Domain)
Dies ist wichig, weil nur ein  Server, der in der Windows Domäne registriert ist, als vertrauenswürdig eingestuft wird:

netbios name = www
realm = SEPIA.DE
security = ADS
encrypt passwords = yes
password server = pdc.sepia.de
workgroup = INTERNAL

Der Windows Domäne beitreten:

www:~# net ads join -U Administrator
Using short domain name -- INTTEST
Joined 'WWW' to realm 'sepia.de'

KEYTAB-Datei erzeugen:  Entweder auf dem Windows Active Directory Server per:

ktpass -out apache2.keytab \
   -mapuser www\
   -princ HTTP/www.sepia.de@SEPIA.DE \
   -pass login123 \
   -ptype KRB5_NT_PRINCIPAL \
   -crypto RC4-HMAC-NT \

 

Unter Linux ein Ticket ziehen:

kinit -p www@sepia.de

Oder von Linux (Webserver) aus mit den Samba-Tools:

www:~# net ads keytab add HTTP -U Administrator
Processing principals to add...
Enter administrator's password:

Nun befinden sich in /etc/krb5.keytab die "service principals" für HTTP/www.sepia.de.

Auf dem Webserver checken, ob die Keys vorhanden sind mit ktutil:

www:~# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1   19               HTTP/www.sepia.de@SEPIA.DE
2   19               HTTP/www.sepia.de@SEPIA.DE
3   19               HTTP/www.sepia.de@SEPIA.DE
4   19                        HTTP/www@SEPIA.DE
5   19                        HTTP/www@SEPIA.DE

Berechtigungen für apache für die Keytab-Datei:

www:~# chmod 740 /etc/krb5.keytab
www:~# chgrp www-data /etc/krb5.keytab

Konfiguration Apache Webserver

Per mod-auth-gssapi

# Debian:
sudo apt-get install libapache2-mod-auth-gssapi
# on RHEL-based distrubtions:
sudo dnf install mod_auth_gssapi
sudo a2enmod auth_kerb

<LOCATION /abgesichert-gsapi >
AuthType GSSAPI
AuthName "Kerberos GSAPI Login"
GssapiCredStore keytab:/etc/keytabs/pim.keytab
GssapiLocalName On
#Require valid-user
require user user1 user2
</LOCATION>

 

Alternativ mod-auth-kerb (etwas älter):

# on Debian-based distributions:
sudo apt-get install libapache2-mod-auth-kerb
# on RHEL-based distrubtions:
sudo dnf install mod_auth_kerb
sudo a2enmod auth_kerb

<Location /abgesichert>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd Off
  KrbAuthRealms SEPIA.DE
  Krb5KeyTab /etc/krb5.keytab
#  require valid-user

   require user user1 user2
</Location>

 

Konfiguration Browser

Single Sign On im Browser aktivieren

 

Beim Windows-PC im Firefox wird diese Einstellung vorgenommen:
URL:   about:config:  network.negotiate-auth.trusted-uris   = .sepia.de  (Beispiel)

ODER:

Click auf Menü
Auswahl Einstellungen
Privatsphäre und Sicherheit > Logins and Passwörter
Aktivieren: “Erlauben Windows Single Sign-on ”

 

Debugging

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn, error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
# LogLevel trace8 ssl:warn LogLevel info auth_kerb:debug ssl:warn

 

Ergebnis

Nachdem beim Zugriff auf eine URL per Browser - analog zum den hier gelisteten Einstellungen wäre dies  http::/www.sepia.de/abgesichert/ -  die Kerberos-Authentisierung (siehe Schaubild oben) erfolgreich gelaufen ist, teilt der Webbrowser dem Webserver den Anmeldenamen des entfernten Benutzers mit. Dieser ist dann dem Webserver über die Umgebungsvariable REMOTE_USER bekannt. Dass der Benutzer die Webseite nutzen darf, ist sichergestellt, da der Domain Controller über die Information verfügt, dass der Benutzer über das Login auf seinem Rechner zuvor registriert worden war.

Optional: Benutzergruppen per LDAP

Möchte man Benutzer zentral in Gruppen zusammenfassen, um die Berechtigungen der Zielsysteme genau abbilden zu können, so ist auf dem Webserver ein LDAP-Client (Apache mod_ldap) mit Zugriff auf einen LDAP-Server einzurichten, auf dem die Benutzergruppen verwaltet werden. Unter Windows beinhaltet der Active Directory Server einen LDAP-Service, sodass kein separater Server aufgesetzt werden muss.

Konfiguration des Apache Webservers als LDAP-Client

Apache Module installieren: ldap, authnz_ldap

In der Apache Konfigurationsdatei:

//Authentisierung über LDAP aktivieren:

AuthzLDAPAuthoritative on

//URL zum LDAP-Server angeben:
AuthLDAPURL "ldap://dc.sepia.de/dc=sepia,dc=de?userPrincipalName"

//Bindung für den Benutzer (pim) setzen, der Zugriff auf den LDAP-Server hat:
AuthLDAPBindDN "cn=pim,cn=Users,dc=sepia,dc=de"

//Passwort für den User (pim) zur Anmeldung beim LDAP-Server
AuthLDAPBindPassword  *******

//Mitteilen, dass ein Benutzer in  LDAP den Gruppen AlterraPIMAccess und Users angehören muss, damit er das System verwenden darf:

Require ldap-group cn=AlterraPIMAccess,cn=Users,dc=sepia,dc=de

Über LDAP lassen sich natürlich noch andere viel komplexere Einstellungen abbilden, die mit dieser Grundfunktion verwendet werden können.

Spezielle Einstellungen für Alterra MDM/PIM 

Konfigurationseinstellung des SSO Moduls über die zenrtale Konfigurationsdatei:
$_config[ "module" ][ "single_sign_on" ] = array( "remote_user" => getenv("REMOTE_USER"));
 
Login als Administrator oder anderer Benutzer ist optional möglich über:
[pimurl]/web/manage.php;

Über diese URL gelangen Sie nach erfolgreicher Kerberos-Authentisierung  zum Alterra Login-Dialog, der beim Single Sign On nicht benötigt wird, da man in der Regel als der Benutzer automatisch angemeldet wird, der auf dem Client System angemeldet ist.