De afgelopen jaren heb ik te maken gehad met verschillende SSO oplossing met één van de belangrijkste redenen dat er te veel systemen zijn met een eigen wachtwoord. Na verloop van tijd worden er nieuwe systemen ingezet binnen een organisatie en heb je opeens 20 wachtwoorden te onthouden. Natuurlijk moeten die 20 wachtwoorden allemaal voldoen aan de eisen van een lastig te raden reeks tekens. Naast al die andere arbitraire feitjes zoals telefoonnummers, bankrekeningnummer, verjaardagen en adressen is dit een hele opgave. Hoe meer er geklaagd wordt over al deze wachtwoorden hoe meer er nagedacht wordt over een SSO-oplossing.

Een SSO-oplossing lost het authenticatie probleem (wie ben jij?) op en niet het autorisatie probleem (wat mag jij doen?). Veel SSO-oplossingen zijn niet een Single-Sign-On (eenmalige aanmelden), maar een Shared Sign On oplossing.

De meest gebruikte oplossingen zijn:

1. Het centraliseren van de wachtwoorden. Bij elke gebruiker op het systeem wordt een wachtwoord manager geïnstalleerd waar een master wachtwoord op zit. Zodra een gebruiker een extern systeem gaat gebruiken, en een wachtwoord nodig heeft, wordt de wachtwoord manager aangesproken om het wachtwoord voor dat systeem op te halen. Voordat de wachtwoord manager het wachtwoord vrij geeft moet de gebruiker het master wachtwoord invoeren. De gebruiker hoeft hierdoor maar één wachtwoord te onthouden, maar onderwater kan elk systeem wel zijn eigen wachtwoord gebruiken. Dit is een veel gebruikte manier voor portal omgevingen. Een gebruiker meldt zich aan bij de portal en de portal gebruikt de al eerder ingevulde wachtwoorden voor de achterliggende systemen. Als een organisatie dit niet infrastructureel inzet kan een individuele gebruiker ook zelf een wachtwoord manager gebruiken om al zijn wachtwoorden af te schermen. Er zijn een heel aantal open source/freeware wachtwoord managers te vinden op het internet (PasswordSafe, KeePass, enz.).
2. Het centraliseren van de credential store. Met andere woorden alle systemen moeten een ander systeem gebruiken om de gebruikersnaam en wachtwoord combinatie (credentials) te controleren. Iedere applicatie heeft nog wel een aanmeldscherm, maar het wachtwoord is overal hetzelfde. Vaak is de credential store een LDAP waar de gebruiker in opgezocht kan worden of waar de gebruiker zich aan kan melden. Binnen Finalist is deze manier van SSO zeer lang toegepast. De Windows Active Directory is als een LDAP te benaderen waardoor de Windows domein gebruikersnaam ook te gebruiken is voor LDAP authenticatie om de gebruiker te controleren. Ook onder deze oplossing valt OpenID waarmee je op verschillende sites kunt inloggen.
3. Gecentraliseerde authentication servers (Federated authentication). Met deze oplossing delegeren systemen de authenticatie naar een extern systeem. De gebruiker en het systeem, dat wordt benaderd, vertrouwen de authentication server. De authentication server bepaalt de identiteit van de gebruiker en maakt deze kenbaar aan het systeem. Als een gebruiker naar een tweede systeem gaat die ook de authentication server gebruikt dan hoeft de identiteit van de gebruiker niet meer bepaald te worden. De authentication server hoeft alleen de identiteit kenbaar te maken aan het tweede systeem. De gebruiker hoeft maar één keer aan te melden bij de authentication server. De oplossingen die hier onder vallen zijn ruw te verdelen in twee groepen. De eerste groep is voornamelijk gericht op web-based applicaties en de tweede groep is gericht op LAN-based applicaties zoals email, ssh, telnet, subversion, cvs, file-shares, enz. Bekende systemen voor Single-Sign-On zijn CAS (http://www.jasig.org/cas), Shibboleth (http://shibboleth.internet2.edu), OpenSSO, A-Select (o.a. DigID) en Kerberos.

Naast dat een SSO oplossing veel voordelen biedt op gebruikersgemak is er ook een groter risico dat de identiteit van een gebruiker gestolen wordt. Nu is er nog maar één wachtwoord nodig om je voor te doen als een gebruiker. Het master wachtwoord moet nog beter geheim gehouden worden en de wachtwoordpolicy moet nog strikter zijn dan het geval is voor de meeste afzonderlijke systemen. Het beste is dan ook om het master wachtwoord te combineren met een smartcard of one-time-password (OTP) token.

Ook zijn alle systemen afhankelijk van de authentication server waardoor uitval van de server betekent dat alle andere systemen niet gebruikt kunnen worden. Het beheren van identiteiten wordt makkelijker, maar de investering per applicatie om SSO te integreren is hoger dan wanneer de applicatie de authenticatie zelf regelt.

Zoals hierboven te lezen is kun je nog veel kanten op met SSO. Ook zijn verschillende oplossingen naast elkaar te gebruiken. Een oplossing die niet vaak gekozen wordt, is kerberos-based terwijl vanaf java 5 dat standaard ondersteund wordt door JAAS en de Java GSS-API. JAAS is de Java Authentication en Authorization Service en levert een LoginModule voor Kerberos. De GSS-API is een Generic Security Service API gedefinieerd door de IETF om authenticatie en beveiligde communicatie niet afhankelijk te laten zijn van de gebruikte technologie. De Java implementatie van de GSS-API gebruikt standaard kerberos als technologie.

Naast dat Java standaard Kerberos ondersteunt hebben veel organisaties een Microsoft Active Directory (AD) staan waar Kerberos ook standaard als authenticatie protocol wordt gebruikt. Met minimale inspanning kan een Java 5 applicatie een gebruiker authenticeren tegen een AD. Om bijvoorbeeld een web applicatie in Tomcat te beveiligen hoef je alleen maar een paar dingen te configureren.

1. De web applicatie moet beveiligd worden met security-constraints in de web.xml.
2. De web applicatie moet een JAASRealm gebruiken voor de authenticatie.
3. JAAS moet geconfigureerd worden met de Kerberos LoginModule.
4. De LoginModule moet geconfigureerd worden met de Kerberos configuratie.
5. Java moet de jaas config en kerberos config bestanden kunnen vinden.

De simpelste web.xml die werkt voor mijn Finalist windows gebruiker is als volgt. Merk op dat de role mijn gebruikersnaam is waarbij het domein in hoofdletters is. Ook heb je een login.jsp nodig met het standaard j_security_check formulier.

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
   version="2.5">
  <login-config>
    <auth-method>FORM</auth-method>
    <realm-name>Kerberos</realm-name>
    <form-login-config>
      <form-login-page>/login.jsp</form-login-page>
      <form-error-page>/login-error.jsp</form-error-page>
    </form-login-config>
  </login-config>
  <!-- Anyone with one of the listed roles may access this area -->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>all files</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>nico@FINALIST.NL</role-name>
    </auth-constraint>
  </security-constraint>
  <!-- Security roles referenced by this web application -->
  <security-role>
    <role-name>nico@FINALIST.NL</role-name>
  </security-role>
</web-app>

Een realm is in Tomcat op verschillende plekken neer te zetten. We willen één applicatie beveiligen dus het beste is om het realm in de context.xml van de web applicatie te zetten. Om bijvoorbeeld de ROOT applicatie te beveiligen moet er een bestand worden gemaakt in $TOMCAT_HOME/webapps/ROOT/META-INF/context.xml. De inhoud is als volgt.

<?xml version="1.0" encoding="UTF-8"?>
<Context>
        <Realm className="org.apache.catalina.realm.JAASRealm"
                 appName="Tomcat"
                 userClassNames="javax.security.auth.kerberos.KerberosPrincipal"
                 roleClassNames="javax.security.auth.kerberos.KerberosPrincipal"
                 useContextClassLoader="true"
                 debug="99"/>
</Context>

Om JAAS in te stellen voor Kerberos is een $TOMCAT_HOME/conf/jaas.conf bestand nodig. De naam van de LoginModule is gelijk aan de appName in het realm. De inhoud ziet er als volgt uit:

Tomcat {
  com.sun.security.auth.module.Krb5LoginModule required debug=true;
};

En als laatste configuratie bestand hebben we de kerberos configuratie nodig. Deze configuratie wordt gebruikt om de kerberos distribution center (KDC) te kunnen vinden. In ons geval is dat de Active Directory. De standaard locatie is op Windows c:\windows\krb5.ini en op Linux /etc/krb5.conf. Omdat dit een demonstratie is zet ik hem onder $TOMCAT_HOME/conf/krb5.conf.

[libdefaults]
	default_realm = FINALIST.NL
	default_tkt_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc des3-cbc-sha1
	default_tgs_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc des3-cbc-sha1

[realms]
	FINALIST.NL = {
		kdc = fina2003.finalist.nl:88
		admin_server = fina2003.finalist.nl
		default_domain = FINALIST.NL
	}

[domain_realm]
	.finalist.nl = FINALIST.NL
	FINALIST.NL = FINALIST.NL

En als laatste moeten er wat Java system properties worden meegegeven zodat de JVM de configuratie bestanden kan vinden. In de Shell waar tomcat gestart gaat worden moet het volgende eerst even uitgevoerd worden

set JAVA_OPTS=%JAVA_OPTS% -Djava.security.krb5.conf=%CATALINA_HOME%/conf/krb5.conf -Djava.security.auth.login.config=%CATALINA_HOME%/conf/jaas.conf

Na het starten van tomcat worden de credentials door de web applicatie via Kerberos gecontroleerd. De gebruikersnaam en wachtwoord gaan nog steeds in tekst naar Tomcat, maar dat is de volgende stap in een veiliger netwerk. De manier om veilig de credentials te communiceren naar Tomcat is om SPNEGO te gebruiken en een Negotiate challenge te sturen naar de browser. Maar uitleggen hoe SPNEGO werkt is genoeg stof voor een heel nieuw artikel.