160 likes | 278 Views
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…
E N D
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