Shibboleth IdP

Z PIONIER.Id
Wersja z dnia 22:43, 26 mar 2015 autorstwa federacja>Mgw
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Przejdź do nawigacji Przejdź do wyszukiwania

Instalacja Shibboleth IdP 2.4.X

UWAGA: Zgodnie z informacją na stronie [https://shibboleth.net/community/news/20141104.html https://shibboleth.net/community/news/20141104.html, zaleca się instalację wersji 2.4.3.

Wymagania wstępne:

Pobieramy pakiet Shibboleth IdP 

cd /opt/
wget http://shibboleth.net/downloads/identity-provider/2.4.3/shibboleth-identityprovider-2.4.3-bin.tar.gz
tar zxfv shibboleth-identityprovider-2.4.3-bin.tar.gz

Pobieramy MySQL Connector/J i umieszczamy w katalogu shibboleth-identityprovider-2.4.3/lib. Na stronie http://dev.mysql.com/downloads/connector/j/ można sprawdzić, jaka wersja jest najnowsza. Dla bieżącej wersji (5.1.34) wykonujemy: 

wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.34.tar.gz
tar zxvf mysql-connector-java-5.1.34.tar.gz
cp mysql-connector-java-5.1.34/mysql-connector-java-5.1.34-bin.jar /opt/shibboleth-identityprovider-2.4.3/lib

A następnie: 

cd shibboleth-identityprovider-2.4.3/
./install.sh

W czasie wykonania skryptu install.sh zatwierdzamy wszystkie pytania. Shibboleth IdP zainstaluje się w katalogu /opt/shibboleth-idp/. Zostanie wygenerowany certyfikat self-sign, który będzie używany do podpisywania i szyfrowania transmitowanych danych (wg protokołu SAML).

Definiujemy usługę shibboleth-idp w kontenerze tomcat. Poniższe instrukcje zakładają, że pliki konfiguracyjne tomcata znajdują się w /etc/tomcat, a użytkownik i grupa procesu to tomcat. W zależności od wersji systemu operacyjnego czy tomcata, może to być katalog /etc/tomcat7 i użytkownik/grupa tomcat7. Tworzymy plik /etc/tomcat/Catalina/localhost/idp.xml z następującą zawartością 

<Context docBase="/opt/shibboleth-idp/war/idp.war" 
    privileged="true" 
    antiResourceLocking="false"
    antiJARLocking="false" 
    unpackWAR="false"
    swallowOutput="true" />

W pliku konfiguracyjny tomcata /etc/tomcat/server.xml edytujemy definicję elementu Connector dla portu 8009: 

<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
request.tomcatAuthentication="false" address="127.0.0.1" />

Ustalamy prawa własności katalogów logów oraz metadanych: 

chown tomcat:tomcat /opt/shibboleth-idp/logs/
chown tomcat:tomcat /opt/shibboleth-idp/metadata/

  i restartujemy serwis tomcat

W konfiguracji httpd definiujemy korzystanie z proxy_ajp 

echo 'ProxyPass /idp/ ajp://localhost:8009/idp/' > /etc/httpd/conf.d/proxy_ajp.conf

Konfigurujemy usługę https - certyfikat używany do połączenia musi być poświadczony przez ogólnie znane CA (np. TCS).

Restartujemy serwis httpd


Załóżmy, że nazwa skonfigurowanego serwera to http://login.example.pl.

Metadane usługi IdP dostępne są pod adresem https://login.example.pl/idp/shibboleth

Konfiguracja Shibboleth IdP

Dostosowanie plików konfiguracyjnych

Pliki konfiguracyjne znajdują się w katalogu /opt/shibboleth-idp/conf/.
W przedstawionej poniżej konfiguracji zakładamy, że bazą użytkowników jest LDAP. W punkcie opisano, jak skonfigurować IdP, gdy dane użytkowników są umieszczone w bazie MySQL, a w punkcie Współpraca Shibboleth IdP z usługą CAS przedstawiona jest sytuacja, gdy Shibboleth IdP ma współpracować z CAS-em.

relying-party.xml

Podstawowa konfiguracja Shibboleth IdP.

Istotna jest sekcja "Metadata Configuration" - w niej są umieszczane wskazania metadanych, z których korzysta IdP, np. 

<!-- Metadane IdP -->
<metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:ChainingMetadataProvider">
    <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetadataProvider"
          metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml"
          maxRefreshDelay="P1D" />
<!-- PIONIER.Id Test SP -->
    <metadata:MetadataProvider id="TESTSP" xsi:type="metadata:FileBackedHTTPMetadataProvider"
          metadataURL="https://aai.pionier.net.pl/test/module.php/saml/sp/metadata.php/default-sp"
          backingFile="/opt/shibboleth-idp/metadata/testsp.xml">
    </metadata:MetadataProvider>
    <!-- eduGAIN metadata -->
    <metadata:MetadataProvider id="EDUGAIN" xsi:type="metadata:FileBackedHTTPMetadataProvider"
          metadataURL="http://aai.pionier.net.pl/pionierid-edugain-sp-feed.xml"
          backingFile="/opt/shibboleth-idp/metadata/pionierid-edugain-sp-feed.xml">
         <metadata:MetadataFilter xsi:type="ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata">
         <metadata:MetadataFilter xsi:type="SignatureValidation" xmlns="urn:mace:shibboleth:2.0:metadata"
              trustEngineRef="eduGAIN.MetadataTrustEngine"
              requireSignedMetadata="true" />
         </metadata:MetadataFilter>
    </metadata:MetadataProvider>
</metadata:MetadataProvider>

W deklaracji dostawcy metadanych "EDUGAIN" podany został filtr o typie SignatureValidation z referencją eduGAIN.MetadataTrustEngine. Niezbędne jest wówczas umieszczenie w konfiguracji definicji tego źródła: 

<security:TrustEngine id="eduGAIN.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
        <security:Credential id="eduGAINCredentials" xsi:type="security:X509Filesystem">
            <security:Certificate>/opt/shibboleth-idp/credentials/pionieridsigner.cer</security:Certificate>
        </security:Credential>
</security:TrustEngine>

W pliku /opt/shibboleth-idp/credentials/pionieridsigner.cer umieszczamy certyfikat pobrany ze strony Informacje techniczne PIONIER.Id

Szczegółowe informacje o możliwościach znajdują się na stronie https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider

relying-party.xml to wzorcowy plik konfiguracji podstawowej IdP.

attribute-resolver.xml

W tym pliku są umieszczone definicje atrybutów oraz połączeń do źródeł danych, takich jak LDAP czy mySQL.Definicja atrybutu zawiera typ (xsi:type), identyfikator (id), atrybut źródłowy - czyli ten, na podstawie którego tworzony jest dany atrybut (sourceAttribute), wskazanie źródła, z którego jest pobierany atrybut (resolver:Dependency), wskazanie sposobów kodowania atrybutu (resolver:AttributeEncoder), a także, opcjonalnie, nazwy (resolver:DisplayName) i opisy (resolver:DisplayDescription) atrybutu w potrzebnych językach. Przykładowo: 

<resolver:AttributeDefinition xsi:type="ad:Simple" id="uid" sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
        <resolver:DisplayName xml:lang="en">User identifier</resolver:DisplayName>
        <resolver:DisplayName xml:lang="pl">Identyfikator użytkownika</resolver:DisplayName>
        <resolver:DisplayDescription xml:lang="en">User identifier</resolver:DisplayDescription>
        <resolver:DisplayDescription xml:lang="pl">Identyfikator użytkownika</resolver:DisplayDescription>
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:uid" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1"  friendlyName="uid" />
</resolver:AttributeDefinition>

Definicja źródła, z którego są pobierane atrybuty ma postać, w przypadku LDAP-a: 

 
<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
        ldapURL="ldap://localhost"
        baseDN="ou=users,dc=test-org,dc=pl"
        principal="cn=admin,dc=test-org,dc=pl"
        principalCredential="1qaz2wsx">
        <dc:FilterTemplate>
            <![CDATA[
                (uid=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
</resolver:DataConnector>

W tym pliku jest definiowany atrybut persistent ID oraz sposób jego generowania i powiązanie z bazą mySQL (źródło storedID).

attribute-resolver.xml jest wzorcowym plikiem przemapowań atrybutów.

attribute-filter.xml

Zawiera ustalenia dotyczące filtrowania atrybutów na podstawie nazw atrybutów, ich wartości. Umożliwia  precyzyjną  kontrolę dostępu poprzez wskazanie dozwolonych odbiorców atrybutów.

Przykładowo definicja: 

 
<afp:AttributeFilterPolicy id="releaseEPPNToAnyone">
      <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
          <afp:AttributeRule attributeID="eduPersonPrincipalName">
          <afp:PermitValueRule xsi:type="basic:ANY" />
      </afp:AttributeRule>
</afp:AttributeFilterPolicy>

oznacza, że atrybut eduPersonPrincipalName jest udostępniany wszystkim dostawcom usług (wskazuje to xsi:type="basic:ANY"), niezależnie od wartości atrybutu.

Z kolei definicja: 

 
<afp:AttributeFilterPolicy id="releaseeduPersonEntitlementtosp12example">
        <afp:PolicyRequirementRule xsi:type="basic:OR">
            <basic:Rule xsi:type="basic:AttributeRequesterString"
                        value="https://sp1.example.pl" />
            <basic:Rule xsi:type="basic:AttributeRequesterString"
                        value="https://sp2.example.pl" />
        </afp:PolicyRequirementRule>
        <afp:AttributeRule attributeID="eduPersonEntitlement">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
</afp:AttributeFilterPolicy>

określa, że atrybut eduPersonEntitlement będzie przekazywany do usług https://sp1.example.pl i https://sp2.example.pl.

Można również ustalić, że o przekazywaniu atrybutów będzie decydowała deklaracja w metadanych dostawcy usługi akceptacji Kodeksu Postępowania (Code of Conduct) 

      
<afp:AttributeFilterPolicy id="releaseToCoC">
     <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
          attributeName="http://macedir.org/entity-category"
          attributeValue="http://www.geant.net/uri/dataprotection-code-of-conduct/v1"/>
     <afp:AttributeRule attributeID="displayName">
     <afp:PermitValueRule xsi:type="basic:ANY"/>
     </afp:AttributeRule>
     <afp:AttributeRule attributeID="sn">
     <afp:PermitValueRule xsi:type="basic:ANY"/>
     </afp:AttributeRule>
 .....
</afp:AttributeFilterPolicy>

Wszystkie możliwości konfiguracji filtrowania atrybutów opisane są na stronie https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttributeFilter

attribute-filter.xml jest wzorcowym plikiem ustawień filtrów atrybutów.

login.config

Plik ten określa sposób realizacji uwierzytelniania. Wskazuje moduł odpowiedzialny za logowanie. Jeśli korzystamy z LDAP-a, należy umieścić w nim odwołanie do LdapLoginModule zawierające: nazwę serwera LDAP (host), nazwę korzenia drzewa danych (baseDN), nazwę użytkownika uprawnionego do realizowania operacji odczytu (bindDN), hasło tego użytkownika (bindCredential), informację czy są realizowane bezpieczne połączenia (tls), czy jest przeszukiwane całe poddrzewo (subtreeSearch) i jakie pole jest używane do realizacji wyszukania (userField). 

ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="localhost"
baseDn="ou=Users,dc=test-org,dc=pl"
bindDn="cn=admin,dc=test-org,dc=pl"
bindCredential="1qaz2wsx"
tls="false"
subtreeSearch="true"
userField="uid";
}

login.config jest wzorcowym plikiem definicji logowania.

handler.xml

W tym pliku należy wskazać handler obsługujący logowanie. Domyślnie włączony jest LoginHandler o type RemoteUser. Jeśli korzystamy z bazy LDAP jako źródła danych użytkowników, należy zakomentować sekcję: 

<ph:LoginHandler xsi:type="ph:RemoteUser">
       <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
</ph:LoginHandler>

i uaktywnić typ UsernamePassword 

<ph:LoginHandler xsi:type="ph:UsernamePassword" 
    jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">          
   <ph:AuthenticationMethod>
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
   </ph:AuthenticationMethod> 
</ph:LoginHandler>

handler.xml jest wzorcowym plikiem definicji handlerów w systemie.

logging.xml

W tym pliku definiuje się poziomy logowania oraz miejsce logowania. Domyślnie Shibboleth IdP loguje do pliku /opt/shibboleth-idp/logs/idp-process.log. Aby zwiększyć poziom logowania należy w odpowiednich blokach logger ustawić logger="DEBUG". Np. w celu debugowania etapu logowania via LDAP, należy ustawić: 

<logger name="edu.vt.middleware.ldap" level="DEBUG"/>

Aby analizować otrzymywane przez IdP zlecenia (REQUEST) oraz wysyłane z IdP odpowiedzi (RESPONSE) należy podać: 

<logger name="PROTOCOL_MESSAGE" level="DEBUG"/>

Uwaga: Jeśli chcemy analizować pakiety zawierające odpowiedzi, należy czasowo zmienić w pliku relying-party.xml wartości parametru encryptAssertions. Domyślna wartość "conditional" powinna zostać zmieniona na "never".

Przygotowanie źródeł danych

Baza użytkowników LDAP

Patrz Baza użytkowników IdP

Baza MySQL do przechowywania persistent ID

Instalujemy i uruchamiamy serwis mysql. Tworzymy bazę danych: 

CREATE DATABASE IF NOT EXISTS shibboleth CHARACTER SET=utf8;

oraz tablicę shibpid w tej bazie, tablicy nadajemy uprawnienia: 

CREATE TABLE IF NOT EXISTS shibpid (
  localEntity TEXT NOT NULL,
  peerEntity TEXT NOT NULL,
  principalName VARCHAR(255) NOT NULL DEFAULT '',
  localId VARCHAR(255) NOT NULL,
  persistentId VARCHAR(36) NOT NULL,
  peerProvidedId VARCHAR(255) DEFAULT NULL,
  creationDate timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
    ON UPDATE CURRENT_TIMESTAMP,
  deactivationDate TIMESTAMP NULL DEFAULT NULL,
  KEY persistentId (persistentId),
  KEY persistentId_2 (persistentId, deactivationDate),
  KEY localEntity (localEntity(16), peerEntity(16), localId),
  KEY localEntity_2 (localEntity(16), peerEntity(16),
    localId, deactivationDate)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
GRANT ALL ON shibboleth.* TO 'shibboleth'@'localhost' identified by '...wybrane_hasło...';
FLUSH PRIVILEGES;

Namiary na bazę i nadane uprawnienia muszą zostać wpisane do pliku konfiguracyjnego attribute-resolver.xml, w bloku 

<resolver:DataConnector xsi:type="dc:StoredId" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
..
</resolver:DataConnector

Po wykonanej konfiguracji robimy ponownie restart tomcata 

service tomcat restart

Współpraca Shibboleth IdP z bazą MySQL

Jeśli dane użytkowników znajdują się w bazie MySQL, wygodnym rozwiązaniem jest zastosowanie modułu com.tagish.auth.DBLogin oraz konfiguracji login.conf - komponenty znajdują się w tym pliku: tagish.tgz.

Moduł akceptacji zasad korzystania oraz zatwierdzania atrybutów przekazywanych dostawcy usługi (SP)

Aby Shibboleth IdP mógł przekazywać logującym się użytkownikom zapytanie o zgodę na zasady korzystania z usług federacyjnych (Terms of Use) oraz zgode na przekazanie dostawcy potrzebnych atrybutów, należy włączyć moduł uApprove: https://www.switch.ch/aai/support/tools/uApprove.html Moduł ten został przygotowany przez sieć krajową Szwajcarii - SWITCH.

Instalacja i konfiguracja

Pobieramy aktualną wersję uApprove ze strony https://forge.switch.ch/redmine/projects/uapprove/files

Szczegółowy przebieg instalacji jest opisany na stronie: <a href="https://www.switch.ch/aai/downloads/uApprove-manual/">https://www.switch.ch/aai/downloads/uApprove-manual/</a>

Ustawiamy zmienne środowiskowe i kopiujemy pliki do środowiska IdP: 

export IDP_INSTALL=/opt/shibboleth-identityprovider-2.4.3
export IDP_HOME=/opt/shibboleth-idp
export UAPPROVE_INSTALL=/opt/uApprove-2.6.0
cp $UAPPROVE_INSTALL/lib/*.jar $IDP_INSTALL/lib
cp $UAPPROVE_INSTALL/lib/jdbc/*.jar $IDP_INSTALL/lib

Kopiujemy pliki konfiguracyjne do katalogu /opt/shibboleth-idp/conf 

cp $UAPPROVE_INSTALL/manual/configuration/uApprove.xml $IDP_HOME/conf
cp $UAPPROVE_INSTALL/manual/configuration/uApprove.properties $IDP_HOME/conf

Tworzymy katalog aplikacji uApprove i kopiujemy do niego pliki aplikacji: 

mkdir $IDP_INSTALL/src/main/webapp/uApprove
cp $UAPPROVE_INSTALL/webapp/* $IDP_INSTALL/src/main/webapp/uApprove

Tworzymy bazę danych uApprove, użytkownika oraz potrzebne tabele: 

CREATE DATABASE uApprove;
GRANT ALL ON uApprove.* TO 'uApprove'@'localhost' identified by '0okm9ijn;';
CREATE TABLE AttributeReleaseConsent (
 userId         VARCHAR(104)                           NOT NULL,
 relyingPartyId VARCHAR(104)                           NOT NULL,
 attributeId    VARCHAR(104)                           NOT NULL,
 valuesHash     VARCHAR(256)                           NOT NULL,
 consentDate    TIMESTAMP    DEFAULT CURRENT_TIMESTAMP NOT NULL,

 PRIMARY KEY (userId, relyingPartyId, attributeId)
);
CREATE TABLE ToUAcceptance (
 userId         VARCHAR(104)                           NOT NULL,
 version        VARCHAR(104)                           NOT NULL,
 fingerprint    VARCHAR(256)                           NOT NULL,
 acceptanceDate TIMESTAMP    DEFAULT CURRENT_TIMESTAMP NOT NULL,

 PRIMARY KEY (userId, version)
);

Modyfikujemy plik $IDP_INSTALL/src/main/webapp/WEB-INF/web.xml

  • W parametrze contextConfigLocation dodajemy $IDP_HOME$/conf/uApprove.xml
  • Na końcu pliku, przed tagiem zamykającym web-app dodajemy filtry i serwlety:
    <!-- uApprove Filter and Servlets -->  
    <filter>
        <filter-name>uApprove</filter-name>
        <filter-class>ch.SWITCH.aai.uApprove.Intercepter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>uApprove</filter-name>
        <url-pattern>/profile/Shibboleth/SSO</url-pattern>
        <url-pattern>/profile/SAML1/SOAP/AttributeQuery</url-pattern>
        <url-pattern>/profile/SAML1/SOAP/ArtifactResolution</url-pattern>
        <url-pattern>/profile/SAML2/POST/SSO</url-pattern>
        <url-pattern>/profile/SAML2/POST-SimpleSign/SSO</url-pattern>
        <url-pattern>/profile/SAML2/Redirect/SSO</url-pattern>
        <url-pattern>/profile/SAML2/Unsolicited/SSO</url-pattern>
        <url-pattern>/Authn/UserPassword</url-pattern>
    </filter-mapping>
    <servlet>
        <servlet-name>uApprove - Terms Of Use</servlet-name>
        <servlet-class>ch.SWITCH.aai.uApprove.tou.ToUServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>uApprove - Terms Of Use</servlet-name>
        <url-pattern>/uApprove/TermsOfUse</url-pattern>
    </servlet-mapping>
    <servlet>
        <servlet-name>uApprove - Attribute Release</servlet-name>
        <servlet-class>ch.SWITCH.aai.uApprove.ar.AttributeReleaseServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>uApprove - Attribute Release</servlet-name>
        <url-pattern>/uApprove/AttributeRelease</url-pattern>
    </servlet-mapping>

web.xml jest wzorcowym plikiem aplikacji uApprove.

  • Dostosowujemy ustawienia w pliku /opt/shibboleth-idp/conf/uApprove.xml:
 Zmieniamy wartość location w context:property-placeholder

    <context:property-placeholder location="file:/opt/shibboleth-idp/conf/uApprove.properties" />
  
 uApprove.xml zawiera wzorcowe ustawienia.
  • Dostosowujemy ustawienia w pliku /opt/shibboleth-idp/conf/uApprove.properties
 m.in. wpisujemy dane do połączenia z bazą mySQL.
 uApprove.properties zawiera wzorcowe ustawienia.
  • Kopiujemy plik zawierający opis zasad korzystania z usługi
  cp $UAPPROVE_INSTALL/manual/examples/terms-of-use.html $IDP_HOME/conf/terms-of-use.html

Dostosowujemy ten plik.

Po wykonaniu powyższych czynności uruchamiamy skrypt instalacyjny: 

cd /opt/shibboleth-identityprovider-2.4.3/
./install.sh

Zatwierdzamy wszystkie pytania i na koniec restart tomcata. 

service tomcat restart

Przy kolejnym logowaniu powinno pojawić się pytanie o zgodę na warunki użytkowania, a następnie pytanie o akceptacje przekazania atrybutów do dostawcy usługi.

Testowanie Shibboleth IdP

Aby przetestować działanie IdP najlepiej skorzystać z testowego dostawcy https://aai.pionier.net.pl/test/attributes.php

Metadane tego usługodawcy są wskazane we wzorcowym pliku relying-party.xml, pod id="TESTSP". Shibboleth IdP w czasie startu powinien załadować odpowiednie metadane i zapisać ich kopię do pliku /opt/shibboleth-idp/metadata/testsp.xml

Testowy dostawca MUSI OTRZYMAĆ METADANE IdP. W tym celu należy przekazać na adres <a href="mailto:admin@aai.pionier.net.pl">admin@aai.pionier.net.pl</a> adres metadanych, tj. https://login.example.pl/idp/shibboleth

Współpraca Shibboleth IdP z usługą CAS (Central Authentication Service)

Shibboleth IdP może zostać zintegrowany z uczelnianą usługą CAS na kilka sposobów. Jedna z możliwości to konfiguracja serwera CAS jako dostawcy tożsamości dla Shibboleth IdP. Oznacza to, że gdy użytkownik jest przekierowywany do Shibboleth IdP, to etapem uwierzytelnienia zajmuje się CAS, czyli:

  • jeśli użytkownik wcześniej zalogował się w CAS, to IDP wykona akcję logowania w sposób niewidoczny dla użytkownika i przejdzie do etapu obsługi atrybutów,
  • jeśli nie została wcześniej ustanowiona sesja CAS, to użytkownik zostanie przekierowany do CAS w celu zalogowania.

Aby Shibboleth IdP mógł współpracować z CAS-em, należy pobrać ostatnią wersję Jasig Java CAS Client i umieścić w katalogu /opt/shibboleth-identityprovider-2.4.3/lib pliki cas-client-core-$VERSION.jar i commons-logging-$VERSION.jar. Następnie modyfikujemy plik konfiguracyjny handler.xml:

  • Jeśli jest odkomentowany blok <ph:LoginHandler xsi:type="ph:UsernamePassword"..></ph:LoginHandler>, umieszczamy wokół niego znaki komentarza,
  • Aktywujemy blok:
<!-- Remote User handler for CAS support -->
<LoginHandler xsi:type="RemoteUser">
  <AuthenticationMethod>
    urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
  </AuthenticationMethod>
  <AuthenticationMethod>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </AuthenticationMethod>
</LoginHandler>
  • Modyfikujemy plik $IDP_INSTALL/src/main/webapp/WEB-INF/web.xml, dodajemy filtry związane z CAS-em:
<context-param>
  <param-name>serverName</param-name>
  <param-value>logon.example.pl</param-value>
</context-param>
<filter>
 <filter-name>CAS Authentication Filter</filter-name>
 <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
  <init-param>
   <param-name>casServerLoginUrl</param-name>
   <param-value>https://cas.example.pl/login</param-value>
  </init-param>
</filter>
<!-- CAS Validation Filter -->
<filter>
 <filter-name>CAS Validation Filter</filter-name>
 <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>           
 <init-param>
   <param-name>casServerUrlPrefix</param-name>
   <param-value>https://cas.example.pl/</param-value>
 </init-param>
 <init-param>
   <param-name>redirectAfterValidation</param-name>
   <param-value>true</param-value>
 </init-param>
</filter>
<!-- CAS HttpServletRequest Wrapper Filter -->
<filter>
 <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
 <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
</filter>
<!-- CAS Assertion Thread Local Filter -->
<filter>
 <filter-name>CAS Assertion Thread Local Filter</filter-name>
 <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
</filter>
<!-- CAS Filter for Shibb RemoteUser -->
<filter-mapping>
 <filter-name>CAS Authentication Filter</filter-name>
 <url-pattern>/Authn/RemoteUser</url-pattern>
</filter-mapping>
<filter-mapping>
 <filter-name>CAS Validation Filter</filter-name>
 <url-pattern>/Authn/RemoteUser</url-pattern>
</filter-mapping>
<filter-mapping>
 <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
 <url-pattern>/Authn/RemoteUser</url-pattern>
</filter-mapping>
<filter-mapping>
 <filter-name>CAS Assertion Thread Local Filter</filter-name>
 <url-pattern>/Authn/RemoteUser</url-pattern>
</filter-mapping>

Po wykonaniu modyfikacji powtarzamy proces instalacji: 

cd /opt/shibboleth-identityprovider-2.4.3
./install.sh

Uwaga: w każdym kolejnym procesie instalacji akceptujemy wszystkie pytania. Serwis tomcat automatycznie zaktualizuje instalację.

Więcej informacji na temat powiązania Shibboleth IdP z CAS-em, m.in. inne podejścia w celu integracji tych usług, znajdują się na stronach:

Źródło: „https://wiki.aai.pionier.net.pl/index.php?title=Federacja:Shibboleth_IdP&oldid=50”