Ennen asentamista  Autentikointilähde LDAP, SQL-tietokanta…  Autentikointimetodi Olemassa oleva kirjautumisjärjestelmä (Pubcookie, CAS…) Uusi autentikointijärjestelmä (yllämainitut, Tomcat forms…) Shibbolethin oma (LDAP)  Attribuuttivarasto LDAP, SQL-tietokanta… Mitä attribuutteja löytyy ja täyttyykö tarve

Asentaminen  Ensin sovelluspalvelin toimintaan Esim. Tomcat + Java  Apachen voi laittaa Tomcatin eteen halutessaan

Verkkoyhteydet  IdP:ssä kaksi palvelua ulospäin Käyttäjille tunnistautumista varten SP-palvelimille joitakin profiileja varten  443 auki maailmalle  8443 voi sallia SP-kohtaisesti Into ylläpitää acl:ia loppu todennäköisesti varsin pian  Palvelut voivat olla myös samassa portissa käytettäessä Apachea sopivalla konfiguraatiolla

Osat  Käyttäjät käyvät portissa 443 Käyttäjät tulevat selaimilla Normaali-https  8443-porttin varmenneautentikaatio SP-palvelimet mm. hakevat attribuutteja tietyissä tilanteissa Palvelimet tunnistavat toisensa varmenteiden avulla

Konfiguraatiot  relying-party.xml Yleiset asetukset mm. miten keskustellaan eri SP:den kanssa  handler.xml Tuetut viestinvaihto- ja autentikointimekanismit  logging.xml Logien asetukset  attribute-filter.xml Mitä attribuutteja luovutetaan millekin SP:lle  attribute-resolver.xml Attribuuttien haun ja luonnin asetukset

Konfiguraatiot joita ei yleensä tarvitse  service.xml  internal.xml

Metadata  Kertoo IdP:lle minkä SP:in kanssa se voi keskustella  Voi olla useita, joiden yhdistelmästä muodostuu kokonaisuus  Paikallisella levyllä tai haetaan verkosta  Oikeellisuus voidaan tarkistaa allekirjoituksen avulla  Varmenteet Shib 1.3:n aikana ainoastaan palvelinten nimet ja CA:n varmenne, joiden avulla yhteydet luotiin SAML2 kaikkien palveluiden varmenteet, jotta voidaan allekirjoittaa ja kryptata viestit

Relying-party  Joukko entityjä, joita käsitellään samalla tavalla IdP:ssä voi olla esim. kolme relying-partya, joista yksi liittyy Hakaan ja toinen omiin sisäisii palveluihin ja kolmas omiin testipalveluihin  Määrittää autentikointitavan, käytettävät varmenteet/protokollat jne.  Metadatatiedosto määrittää relying-partyn <EntitiesDescriptor Name="urn:mace:funet.fi:haka"

Käyttäjätunnistus  Shibboleth vaatii käyttäjätunnistamisen  Useita vaihtoehtoja RemoteUser (siis mikä tahansa autentikointi, joka voidaan liittää IdP:iin ja populoi RemoteUserin Shib LDAP, Kerberos, IP-osoite JAAS-moduli

Attribuuttien haku  Jostain ”haetaan” raakadata, josta attribuutteja lähdetään rakentaaman Computed Id Static data connector Stored Id LDAP RDBM  Määritellään: attribute-resolver.xml

Attribuuttien määrittely  Kukin attribuutti pitää määrittää nimi tyyppi  Määritellään: attribute-resolver.xml  Tyyppejä Simple Scoped Principal name Script Mapped SAML1 nameid SAML2 nameid jne

Attribuuttien enkoodaus  Attribuutit enkoodataan tietylle nimelle ja tyypille lähetystä varten SAML1, SAML2 String, scoped, Base64, XMLObject  Määritellään: attribute-resolver.xml

Attribuuttien luovutus  Kullekin palvelulle luovutetaan sen tarvitsemat attribuutit  CSC toimittaa Haka-palveluille valmiin tiedoston  attribute-filter.xml

IdP moneen federaatioon  Yksi IdP voi liittyä Hakaan, Virtuun, Kalmarin unioniin, korkeakoulun omiin palveluihin, kumppanien palveluihin, testipalveluihin jne.  Kullekin ryhmälle oma metadata, attribuuttien luovutussäännöt ja konfiguraatiot  Askeleet Metadatalähteet kaikille Attribuuttisäännöt