Ennen asentamista  Autentikointilähde LDAP, SQL-tietokanta…  Autentikointimetodi Olemassa oleva kirjautumisjärjestelmä (Pubcookie, CAS…) Uusi autentikointijärjestelmä.

Esitys aiheesta: "Ennen asentamista  Autentikointilähde LDAP, SQL-tietokanta…  Autentikointimetodi Olemassa oleva kirjautumisjärjestelmä (Pubcookie, CAS…) Uusi autentikointijärjestelmä."— Esityksen transkriptio:

1

2 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

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

4 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

5 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

6 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

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

8 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

9 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"

10 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

11 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

12 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

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

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

15 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