Rootmanual:CAS

CAS står för Central Authentication Service, och är ett protokoll för Single Sign On. Kort går det ut på att användaren med sin webbläsare besöker en webbtjänst, som, ifall du saknar en cas-ticket, skickar vidare anv. till CAS-servern där anv. får autentisera sig. Därefter skickas anv. tillbaks till webbtjänsten denne ville logga in på. Webbtjänsten tar då den ticket som användarens webbläsare skickar med anropet och kontrollerar denna mot CAS-servern. Om CAS svarar att den är prima vara så är användaren nu autentiserad mot webbtjänsten.

Något kort om AAA

AAA står för "authentication, authorization and accounting". Vad gäller Lysators webbtjänster är kanske främst de två första A:na intressanta.

Autentisering

Autentisering är alltså processen att någon verifierar att denna någon är den den utger sig för att vara. Det vill säga, användaren foo skriver in sitt användarnamn och lösenord och systemet verifierar att dessa stämmer.

Auktorisering

Auktorisering har med vad användaren får göra i ett system beroende på vilka roller denne antagit. T.ex. Så har kanske en oautentiserad besökare inte rätt se mer än ett inloggningsformulär på en webbplats. En inloggad, autentiserad, användare utan någon roll utöver just vanlig användare kanske har rätt att se och ändra sina egna uppgifter. En användare med andra roller, t.ex. administratör, har kanske rätt att se och ändra uppgifter för andra användare också, utöver sina egna uppgifter.

CAS används enbart för autentisering.

Hur CAS är uppsatt på Lysator

Lysator kör Jasig CAS, som är referensimplementationen. CAS-servern begagnar sig i vårt fall av RADIUS för att autentisera vid inloggningar, och radius-servern ifråga går i sin tur mot Lysators kerberos.

"Varför går inte CAS direkt mot Kerberos?", undrar du då. Svaret är att det verkade något mer involverat att sätta upp, medan freeradius var ganska trivialt att sätta upp. Att ställa in CAS att fråga radius-servern var också i sin tur ganska enkelt.

Freeradius

RADIUS är ett nätverksprotokoll som klarar av alla tre delarna av ovan nämnda AAA. Då denna radius-server bara går mot vår Kerberos så handlar det främst om det första A:et i det här fallet (Kerberos är ju för övrigt också ett nätverksprotokoll för autentisering -- börjar det bli mycket protokoll nu?). Nåväl, för det här syftet är freeradius uppsatt på följande vis (hjälpsam guide även om man kör t.ex. debian):

• Du behöver en gnu/linux-server. I den här listan heter den <server>. Du behöver en kerberos-kdc (och en sådan har lysator ju).
• Installera freeradius, freeradius-krb5, freeradius-utils
• skapa en keytab (du behöver vara kerberosadmin, f.ö.).
  

$ kadmin -p <user>/admin
kadmin: ank -randkey radius/<server>.lysator.liu.se@LYSATOR.LIU.SE

• Förmodligen behöver du även en host-principal.
  

kadmin: ank -randkey host/<server>.lysator.liu.se@LYSATOR.LIU.SE

• Skapa själva keytab:en
  

ktadd -k /etc/krb5.keytab radius/<server>.lysator.liu.se@LYSATOR.LIU.SE
ktadd -k /etc/krb5.keytab host/<server>.lysator.liu.se@LYSATOR.LIU.SE

• Testa att skapa tickets
  

ktadd -k -t radius/<server>.lysator.liu.se@LYSATOR.LIU.SE
ktadd -k -t host/<server>.lysator.liu.se@LYSATOR.LIU.SE

• Nu är det dags att konfigurera radius-servern. Få filen /etc/freeradius/modules/krb5 att se ut typ så här (detta konfigurerar själva autentiseringen, så att radiusservern vet vilken principal den ska använda):
  

krb5 {
        keytab = /etc/krb5.keytab
        service_principal = radius/<server>.lysator.liu.se
}

• Efter det så konfigurerar vi själva klienten. Det går att ställa in för remote-klienter om man vill, men man kan gott nöja sig i det här steget med att ställa in localhost. /etc/freeradius/clients.conf heter filen och "client localhost" kan se ut ungefär såhär:
  

client localhost {
        ipaddr = 127.0.0.1
        require_message_authenticator = no
        secret = <NÅGON JÄTTEHEMLIG SAMLING AV RANDOM TECKEN HÄR>
        nastype = other
}

• För att ställa in att default är att autentisera mot kerberos, redigera /etc/freeradius/sites-available/default och lägg in följande i authenticate-blocket:
  

        Auth-Type Kerberos {
             krb5
        }

• Starta om freeradius. Kan vara en bra idé att testa att det fungerar också (kom ihåg att 'inte' spara bash-historiken (och för den delen, skapa en testkerberosprincipal, du kan ju alltid förstöra den senare) för detta steg om du är rädd om ditt lösenord, vilket du ju borde vara):
  

$ radtest <användarnamn> <lösenord> localhost 0 <den där hemligheten från clients.conf>

• • Om användaruppgifterna var riktiga bör du få tillbaks en Access-Accept, i annat fall får du en Access-Reject. Går det helt åt skogen så får du nog laga det själv ;)

CAS

Med en radiusserver att autentisera mot är nu nästa steg att bygga en CAS-server.

CAS-servern kommer inte riktigt "turn-key" för autentisering mot något annat än det enklast möjliga (vilket jag har för mig är att kolla att anv och lösen är samma sak, åtminste för 3.x). Jasig rekommenderar en metodik som kallas overlay för konfigurering av CAS. Det går i princip ut på att man överlagrar de filer man vill ändra på, och de andra kommer från de maven-artefakter som projektet beror på. Jasig rekommenderar egentligen att man checkar ut något av de exempelprojekt för detta på t.ex. github som finns länkat från deras webbplats. När jag installerade detta fungerade detta lite halvdant, så jag körde på att skapa en egen overlay från scratch istället. Det kan dock vara värt att prova några av de alternativ som finns ändå först. Nedanstående är baserat på 3.x, då 4.x var alldeles ny i skrivande stund och de inte uppdaterat dokumentationen i någon större utsträckning just när detta skrivs.

• Du behöver: en java-jdk, tomcat, maven, så installera detta. (Tomcat kan vara en idé att installera vid sidan av serverns pakethanteringssystem för att få en som är något mer up-to-date. I detta exempel packades den upp till /opt/tomcat)

Jasig CAS

• Skapa dig en arbetskatalog, t.ex. ~/lys-cas
• Skapa en pom.xml som ser ut ungefär så här i den katalogen:
  

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd ">
    <modelVersion>4.0.0</modelVersion>
    <groupId>se.lysator.cas</groupId>
    <artifactId>lys-cas</artifactId>
    <packaging>war</packaging>
    <version>1.0-SNAPSHOT</version>
 
    <build>
        <plugins>
            <plugin>
                 <artifactId>maven-war-plugin</artifactId>
                             <configuration>
                                 <warName>cas</warName>
                             </configuration>
            </plugin>
        </plugins>
    </build>
 
    <dependencies>
        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-webapp</artifactId>
            <version>${cas.version}</version>
            <type>war</type>
            <scope>runtime</scope>
        </dependency>       
    </dependencies>
 
    <properties>
        <cas.version>3.5.2</cas.version>
    </properties>
 
        <repositories>
             <repository>
                  <id>ja-sig</id>
                  <url>http://oss.sonatype.org/content/repositories/releases/ </url>
             </repository>
        </repositories>
</project>

• kör mvn clean package
• Förhoppningsvis går allt bra och du har en cas.war i target/ nu. Om inte så behöver du åtgärda de fel som maven skriver ut. För egen del hade jasigs repository problem och vägrade låta maven ladda ner jar- och pom-filer, så jag fick populera delar av ~/.m2/repository manuellt.
• Förutsatt att allt gick bra så har du en ganska oanvändbar CAS-server som du kan deploya. Anledningen till detta är att den ju inte frågar radius om användaruppgifterna stämmer. Lägg därför in följande dependency under dependencies i pom.xml:
  

        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-support-radius</artifactId>
            <version>${cas.version}</version>
            <type>jar</type>
            <scope>runtime</scope>
        </dependency>

• Utöver att lägga till den som dependency behöver du konfigurera CAS. Du borde ha en deployerConfigContext.xml i target/lys-cas-1.0-SNAPSHOT/WEB-INF/ (om inte, plocka den typ härifrån, modulo versionsnummer). Hur som helst, skapa en katalogstruktur src/main/webapp/WEB-INF, lägg filen där och öppna den i din favoriteditor.
• Någonstans i denna fil borde det finnas en rad som ser ut ungefär så här: <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />.
• Ersätt den med följande:
  

<bean
    class="org.jasig.cas.adaptors.radius.authentication.handler.support.RadiusAuthenticationHandler">
    <property
        name="servers">
        <list>
            <bean
                class="org.jasig.cas.adaptors.radius.JRadiusServerImpl">
                <constructor-arg index="0" value="127.0.0.1" />
                <constructor-arg index="1" value="<MINNS DU DEN DÄR HEMLIGA NYCKELN I /etc/freeradius/clients.conf? INTE? HUR SOM HELST, DEN SKA IN HÄR>" />
                <constructor-arg index="2">
                    <bean
                        class="net.jradius.client.auth.PAPAuthenticator" />
                </constructor-arg>
            </bean>
        </list>
    </property>
</bean>

• Kör mvn clean package igen. Om allt går som det ska så har du nu en cas.war i target/ som kommer gå mot radius-servern när den deployats i Tomcat.

Tomcat

Tomcat är en servlet container.

• Du behöver se till att den lyssnar på SSL, och du ska förstås ha ett ssl-certifikat. Det finns många guider på nätet om hur du sätter upp detta, det är kanske rekommenderat att köra med APR för detta.
• När du ändå redigerar $TOMCAT_HOME/conf/server.xml, se till att servern lyssnar på portarna 80 och 443 också, istället för 8080 resp 8443 (och glöm inte att ändra detta för redirect-attributet för port 80-connectorn också). Connectorn för port 80 ska med andra ord se ut ungefär såhär:
  

    <Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="443" />

och

• I slutet av $TOMCAT_HOME/conf/web.xml lade jag till (innan </web-app>):

<security-constraint>
    <web-resource-collection>
        <web-resource-name>/</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>

    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

• • Detta för att allt in på http ska omdirigeras till https.
• När du tycker att tomcat-servern fungerar tillräckligt bra så är det bara att kopiera cas.war från tidigare steg till $TOMCAT_HOME/webapps/. WAR-filen kommer därefter packas upp automagiskt av Tomcat (givet att den är igång), och när det väl deployats så kan du surfa till <server>.lysator.liu.se/cas och prova hur bra autentiseringen fungerar.

Och sedan...

Därefter återstår förstås att, om man vill, byta utseende på webbsidorna som CAS-servern serverar användaren, men i det stora hela har man nu en fungerande SSO-lösning klar att använda nu. Det finns cas-klienter för de allra flesta webbramverken, och det brukar inte vara några större besvär att begagna sig av dem.