Západočeská univerzita v Plzni,
|
|
- Adéla Kovářová
- před 7 lety
- Počet zobrazení:
Transkript
1 Adresářové služby Jemný úvod do problematiky adresářových služeb Jiří Sitera 1 Březen Centrum informatizace a výpočetní techniky, Laboratoř počítačových systémů, Západočeská univerzita v Plzni, sitera@civ.zcu.cz
2 Obsah 1 Adresářové služby Jmenné služby Adresářové služby DIT Directory Information Tree Pojmenování položek DN (Distinguished Name) Příklad pojmenování atributů, tvorba rozlišovacího jména Základní vlastnosti Základní použití X.500, LDAP standardy adresářových služeb Co je to X Co je to LDAP Základní vlastnosti protokolu LDAP Architektura protokolu LDAP Informační model Atributy, syntaxe atributů Schéma Jmenný model Funkční model Operace search Operace compare Operace pro změnu dat Autentizační operace Možnosti rozšíření funkčního modelu Bezpečnostní model Autentizace Zabezpečení komunikace LDIF LDIF formát pro zápis adresářových položek LDIF formát pro zápis změn adresářových položek Nástroje pro komunikaci s LDAP serverem z příkazové řádky Prohledávání adresářového stromu ldapsearch i
3 Obsah Modifikace položek adresářového stromu ldapmodify, ldapdelete, ldapmodrdn LDAP Co dále? Některé další důležité vlastnosti protokolu LDAP LDAP URL Odkazy Replikace Kostra základního nasazení adresářových služeb Hlavní implementace Vývojové nástroje Kde hledat další informace a zkušenosti Použitá a doporučená literatura 27 ii
4 Kapitola 1 Adresářové služby Tato kapitola se snaží o přiblížení pojmu adresářové služby a poskytuje přehled základních informací z této oblasti. 1.1 Jmenné služby Jmenné služby obecně jsou jedním ze základních kamenů sít ových technologií a sít ové infrastruktury. Mnoho entit vyskytujících se v komunikačních technologiích se identifikuje čísly, přičemž existuje snaha o zavádění dalšího pojmenování těchto entit. V tomto okamžiku vzniká potřeba služby, která zajišt uje vazbu jména na číselnou identifikaci. Používání termínů číslo a jméno je spíše symbolickým, resp. snadno pochopitelým příkladem. Hlavním důvodem pro zavádění jmenného systému není totiž jen zakrytí vnitřních identifikátorů z hlediska člověka přijatelnějšími, ale i řada dalších aspektů, především souvisejících se strukturou jmenného prostoru zavedených jmen. Tento jmenný prostor je totiž obvykle strukturovaný hierarchický a v každém případě nezávislý na omezeních a vnitřní struktuře primárních identifikátorů. Příkladem jmenné služby je DNS (Domain Name System). Jedná se o specializovanou jmennou službu, která poskytuje v rámci sítí TCP/IP a Internetu funkci pro převod IP adres na (DNS) jména. DNS jména mají hierarchický charakter a logickou strukturu nezávislou na struktuře odpovídajících IP adres. Pomocí DNS mohou být dále získávány některé další informace přiřazené jednotlivým jménům, jako jsou například odkazy na tzv. mail exchanger, tj. uzel prostřednictvím kterého je doručována pošta 1. Imlementace DNS je navržena tak, aby vyhověla nárokům které jsou na ni kladeny databáze zahrnuje celý Internet a poskytuje služby všem uzlům v něm zapojeným. Mezi hlavní znaky 1 Existují obecnější jmenné služby založené na infrastruktuře DNS, jako je například Hesiod, který slouží k distribuovanému přístupu k informacím typu uživatelé, služby, zdroje, adt. Stejně tak existují obecnější jmenné služby, které jsou samostatné. Jako příklad může sloužit NIS (Network Information System) (viz například také [10]). 1
5 Kapitola 1, Adresářové služby implementace patří distribuce dat, replikace dat a decentralizovaná správa. Více o DNS viz [10]. 1.2 Adresářové služby Adresářovou službou se rozumí specializovaná aplikace pro ukládání dat, jejich organizaci a přístup k nim. Specifikum je především v datovém modelu, který je rámcem pro práci s daty. Nejjednodušší představa je taková, že data jsou uložena ve formě položek, přičemž každá položka obsahuje několik atributů. Atribut je nositelem dat, tj. má hodnotu. Entry Name Attribute Name Value Obrázek 1.1: První přiblížení formy uložení dat v adresářových službách entry položka, attribute atribut, name jméno, value hodnota Na obr. 1.1 je naznačen vzájemný vztah položek a atributů. Každá položka má unikátní jméno (globálně v rámci položek více viz dále) a každý atribut má unikátní jméno v rámci položky 2. Jméno položky je strukturované, složené z hierarchicky uspořádaných částí. Logicky jsou takto položky v adresářových službách rozmístěny v hierarchické struktuře, adresářovém stromu. V souvislosti s tím, se setkáváme s pojmem DIT (Directory Information Tree). 2 Mohou existovat vícenásobné atributy, které si lze představit bud to jako jeden atribut s více hodnotami nebo jako několik atributů se stejným jménem a různými hodnotami. V podstatě jsou obě představy správné, ale je třeba si uvědomit, že k atributu lze přistupovat pouze na základě jeho jména, takže první představa spíše odpovídá možným operacím. 2
6 1.2 Adresářové služby DIT Directory Information Tree Pod pojmem DIT (Directory Information Tree) se rozumí především konkrétní návrh struktury adresářového stromu, jeho větvení, tj. rozčlenění položek a informací jimi nesených do hierarchicky uspořádaných skupin. Pro přiblížení významu DIT je na obr. 1.2 je zobrazena část konkrétního adresářového stromu. Je účelné si uvědomit, že takto lze rozdělit položky adresářového stromu na uzly a listy. Uzly definují větve stromu, zatímco listy jsou samostatnými koncovými objekty. Samozřejmě i uzlová položka může nést další informaci, než je pouhá existence větve adresářového stromu, nicméně aby bylo lze umist ovat do příslušné větve nějaké položky musí uzlová položka existovat. zcu.cz People <depts> Staff civ Jiri Sitera Groups Administrators Resources Groups Jiri Sitera Node Leaf Obrázek 1.2: Stromová struktura adresářových služeb node uzel, leaf větev Pro návrh DIT architektury adresářových služeb z hlediska členění adresářového stromu a tím i informací existuje mnoho různých postupů. Členění konkrétního stromu je totiž právě jedno, přičemž existuje vždy mnoho různých hledisek a vlivů, které je vhodné posoudit. V této oblasti existuje několik prací poskytujících rozbor jednotlivých možností (např. [9, 19]). Struktura stromu (DIT) se přímo projeví ve jménech jednotlivých položek. Každá položka obsahuje unikátní jméno, které je složeno z části, která popi- 3
7 Kapitola 1, Adresářové služby suje do které větve adresářového stromu položka patří a z unikátního jména položky v rámci větve Pojmenování položek DN (Distinguished Name) DN (Distinguished Name), tj. rozlišovací jméno identifikuje jednoznačně položku v globálním jmenném prostoru adresářového stromu. Rozlišovací jméno se skládá z RDN (Relative Distinguished Name), tj. relativních rozlišovacích jmen. Relativní rozlišovací jméno unikátně specifikuje položku v rámci jedné větve stromu. Rozlišovací jméno se skládá z jednotlivých relativních rozlišovacích jmen, které odpovídají větvím adresářového stromu, kterými je třeba projít v hierarchii mezi položkou a kořenem stromu. Lze říci, že tato hierarchická architektura a způsob pojmenování jednotlivých položek je analogická souborovému systému a jeho adresářové struktuře. Každé relativní rozlišovací jméno je odvozeno od atributu (jména a hodnoty) příslušné položky Příklad pojmenování atributů, tvorba rozlišovacího jména Pojmenování atributů Každý atribut má své jméno. Existují standardy pro jména a významy běžných atributů. Na tomto místě je třeba poznamenat, že každé položce je přiřazen typ položky (objectclass). Typ položky určuje, které atributy se mohou v položce vyskytovat, přičemž může stanovit skupinu atributů, které se musí v položce vyskytovat. Stejně tak atributy mají přiřazen typ. Zde se jedná pouze o jednoduché typy, jako například celé číslo či řetězec. Tato pravidla jsou definována tzv. schématem databáze. Více o schématu viz kap Některé nejzákladnější atributy, které slouží jako elementy relativního rozlišovacího jména jsou uvedeny v následující tabulce: Jméno atributu, alias význam příklad country, c jméno (zkratka) státu cz organization, o jméno organizace zcu organizationalunitname, ou jméno organizační jednotky civ commonname, cn common name položky Jiri Sitera 3 Toto je nejjednodušší případ, obecně je RDN odvozeno od atributů (jednoho nebo více) příslušné položky. 4
8 1.2 Adresářové služby Rozlišovací jméno zcu.cz o=zcu, c=cz People ou=people Groups ou=groups Staff ou=staff Administrators ou=administrators <depts> civ ou=civ Jiri Sitera cn= Jiri Sitera Resources Groups Jiri Sitera Node Leaf Obrázek 1.3: Atributy určující relativní rozlišovací jméno položky. Na obr. 1.3 jsou doplněny hodnoty některých základních atributů u položek v příkladu adresářového stromu. Náš příklad specifikuje podvětev, která je umístěna v oblasti pojmenované dle organizace, v našem případě o=zcu, c=cz V této větvi jsou umístěny všechny objekty (položky) adresářového stromu z uvedeného příkladu, tj. všechna jména budou mít výše uvedenou specifikaci jako suffix. Pro uzly stromu v návrhu DIT jsou v našem příkladu použity atributy ou, organization unit name. Pojmenování objektu uživatele či skupiny je reprezentováno atributem cn. Pak pojmenování neboli rozlišovací jméno (DN) položky uživatele v příkladu je: cn=jiri Sitera, ou=civ, ou=staff, ou=people, o=zcu, c=cz a (položky) skupiny: cn=administrators, ou=groups, o=zcu, c=cz 5
9 Kapitola 1, Adresářové služby Základní vlastnosti Adresářové služby jsou navrženy pro specifickou oblast aplikací. Jak návrh komunikačního protokolu, tak implementace hlavních částí těchto systémů jsou vedeny snahou o specializaci. Hlavní myšlenkou je specifikace specializovaného datové modelu, který definuje rámec pro ukládání informací a přístup k nim (operace nad nimi). Za adresářové služby lze v podstatě považovat množinu nástrojů pro práci s takto uspořádanými daty (spolu s metodologií k jejich použití). Podstata tohoto přístupu je analogická jako například u relačních databází. Relační model dat je navržen a použit pro usnadnění tvorby složitých datových struktur a slouží také jako základ pro efektivní návrh a realizaci jisté množiny aplikací. Lze říci, že v případě adresářových služeb se jedná o specializovanou databázi určenou především pro realizaci aplikací, které zacházejí s daty, k nímž je velmi intenzivně přistupováno (čtení, prohledávání), ale nejsou příliš často měněna. A pokud jsou měněna, tak pouze velmi jednoduchými prostředky (žádné transakce apod.) Základní použití Základním příkladem použití adresářových služeb jsou aplikace jako telefonní seznam (seznam lidí), či databáze zdrojů, například tiskáren či aplikačních serverů. V případě telefonního seznamu mohou adresářové služby obsahovat položky reprezentující jednotlivé lidi, přičemž u každé položky jsou uvedeny atributy s informacemi jako je telefonní číslo, číslo kanceláře, e mail apod. U objektů popisujících tiskárny může jít například o informace typu formát papíru, rychlost tisku, umístění či cena vytištěné strany. Adresářové služby primárně dovolují uživatelům a aplikacím hledat objekty (lidi, zdroje) dle specifikovaných podmínek. Například jsou určeny pro zodpovídání dotazů typu hledám uživatele a znám nebo hledám tiskárnu formátu A4, která umí tisknout barevně. Adresářové služby mohou samozřejmě sloužit také k získávání informací o konkrétních objektech, tj. znám-li konkrétní specifikaci objektu (například jméno tiskárny), mohu se dotázat na jení vlastnosti 5. 4 Toto je základní představa adresářových služeb. To však neznamená, že se nemohou ukázat rozumnými například snahy o rozšíření možností změn položek v adresářových službách (často se měnící data, jako je např. stav zařízení; podpora jednoduchých transakcí) otevřené standardy v těchto oblastech otevírají volnou cestu libovolnému vývoji, který se ukáže životaschopným. 5 V literatuře se lze často setkat s pojmy jako jsou yellow pages a white pages. Tyto pojmy v podstatě odpovídají dvěma naznačeným přístupům. Hledání objektu, který splňuje žádané podmínky je analogické používání zlatých (žlutých) stránek (yellow pages), zatímco získání informací o konkrétním objektu (jehož identifikaci jméno znám) odpovídá použití bílých 6
10 1.3 X.500, LDAP standardy adresářových služeb Adresářové služby Specializované prostředky pro ukládání dat a přístup k nim. Optimalizace návrhu vzhledem k specifickým podmínkám, zejména: Předpoklad málo se měnících informací. Předpoklad jednoduchých operací s daty. Předpoklad majority přístupů, které pouze čtou data, navíc obvykle potřebují data hledat. 1.3 X.500, LDAP standardy adresářových služeb Co je to X.500 X.500 je obvyklá zkratka používaná pro označení standardu adresářových služeb, který definují dokumenty X.500 až X.521 [23]. Standard X.500 byl vytvořen CCITT (Consultative Committee on International Telephony and Telegraphy) a je postaven na rodině protokolů ISO/OSI. X.500 je poměrně komplexní a standardní specifikace pro adresářovou organizaci dat a operace nad nimi. Obecně lze říci, že X.500 je vystavěn na architektuře klient/server, přičemž definuje protokol pro komunikaci mezi klientem a adresářovým serverem directory access protocol (DAP). Protokol DAP, stejně jako implementace X.500 obecně, potřebuje OSI protokolový stack, který je relativně náročný na zdroje. Odtud plyne prvotní myšlenka návrhu prostředku pro jednodušší (lightweight) přístupu k adresářovým službám Co je to LDAP LDAP (Lightweight Directory Access Protocol) byl primárně navržen jako zjednodušená varianta protokolu DAP, tj. jako jednodušší přístupový protokol mezi klientem a adresářovým serverem (X.500). Hlavní zjednodušení tkví v použití rodiny protokolů TCP/IP jako komunikační vrstvy a ve zjednodušení protokolu jako celku (minimalizovány operace, vypuštěny složitější vlastnosti). Postupem času došlo k osamostatnění protokolu LDAP, tj. byla uplatněna idea samostatného LDAP serveru, což znamená adresářový server, který komunikuje s klientem protokolem LDAP (dosud sloužil LDAP pouze jako přístupový protokol k plnokrevnému X.500 serveru). Z obr. 1.4 je tento vývoj stránek telefonního seznamu (white pages). 7
11 Kapitola 1, Adresářové služby jasně patrný. Tak se postupně stalo, že pod pojmem LDAP se rozumí nejen komunikační protokol, ale i adresářový server sám (a to obvykle včetně všech náležitostí, tj. především datového modelu a konceptu distribuované infrastruktury adresářových služeb). Z hlediska klienta by mělo být v principu jedno, zda přistupuje k adresářovým službám realizovaným samostatným (LDAP) serverem, či zda se jedná pouze o gateway k serveru X.500. LDAP Client TCP/IP LDAP Server ISO/OSI X.500 Server Directory Data Stand-alone LDAP server LDAP Client TCP/IP LDAP Server Directory Data Obrázek 1.4: Protokol LDAP a jeho úloha LDAP hlavní významy Protokol pro přístup k datům. Model ukládání, organizace a přístupu k datům (informacím). Rozhraní pro přístup k datům (operace) Základní vlastnosti protokolu LDAP Specifikace protokolu LDAP je implementačně nezávislá a je vedena snahou o maximální jednoduchost pro koncepci byla určující snaha o zjednodušení 8
12 1.4 Architektura protokolu LDAP implementace (za účelem podpory nasazení LDAPu v aplikacích, tj. tvorby tzv. LDAP enabled aplikací). Díky těmto vlastnostem se protokol LDAP začal skutečně výrazněji prosazovat a dosáhl dokonce stavu, kdy je běžně implementován a užíván samostatně. Shrňme hlavní rozdíly oproti X.500: TCP/IP namísto OSI protokolového stacku, jednodušší funkční model, jednodušší reprezentace dat. Globálně se k vývoji situace kolem protokolu LDAP dá říci asi toto: Poté, co se protokol LDAP začal prosazovat díky svojí jednoduchosti, začala tato jednoduchost býti omezujícím aspektem pro některé případy nasazení. Z toho ovšem vyplynula snaha o vylepšování protokolu LDAP a jeho doplňování dalšími vlastnostmi. Takto se vlasně tvoří nový standard pro adresářové služby a to od elementárního (ale dostatečně otevřeného) základu, postupným doplňováním potřebných vlastností. LDAP hlavní vlastnosti Jednoduchost, dobrý poměr implementační náročnosti vůči šíři spektra možného využití. Rozšiřitelnost, otevřenost. Distribuovaný model uložení dat a přístupu k nim. 1.4 Architektura protokolu LDAP Protokol LDAP definuje komunikaci mezi serverem a klientem. Klient zašle serveru zprávu obsahující požadavek na provedení jedné z definovaných operací a server vrátí odpověd (viz obr. 1.5). Zprávy obsahují také příslušná data a informace o jejich formátu. Základní schéma komunikace: Klient naváže spojení s LDAP serverem. Pro operaci navázaní spojení se používá termín binding. Klient se může připojit anonymně nebo musí prokázat svoji identitu (identitu uživatele) provede se autentizace jednou z možných metod. Pro navázaní spojení je tedy nutné, aby klient znal IP adresu a port, na kterém je LDAP server. 9
13 Kapitola 1, Adresářové služby Klient má k dispozici spojení na server (identifikace spojení byla vydána serverem při navázání spojení) a může v jeho rámci posílat žádosti o provedení definovaných operací nad adresářovými daty. Klient uzavře spojení s adresářovým serverem. Pro tuto operaci se používá termín unbinding. Ačkoli se nejedná o přímou součást protokolu LDAP, jedním z důležitých faktorů v této oblasti je standardní LDAP API (application program interface), tj. rozhraní (knihovny) přímo přístupné pro psaní aplikací. Největší význam má standardní rozhraní do jazyka C a jazyka Java. Directory client app. Directory server Internal directory server structure Application Back end Request Reply API LDAP Client Library TCP/IP Front end LDAP reply/request TCP/IP TCP/IP Obrázek 1.5: Komunikace architektura klient/server LDAP Architektura klient/server. Komunikace prostřednictvím rodiny protokolů TCP/IP. Standardní LDAP API, knihovny pro psaní aplikací. Z hlediska návrhu adresářových služeb je komunikační protokol pouze jedním z několika aspektů návrhu a implementace. Pro lepší pochopení celku je vhodné rozčlenit LDAP do několika modelů: 10
14 1.5 Informační model Informační model struktura informací uložených v adresářových službách. Jmenný model organizace a identifikace informací v adresářových službách. Funkční model operace nad informacemi v adresářových službách. Bezpečnostní model řízení přístupu k informacím v adresářových službách. 1.5 Informační model Základní pojmy informačního modelu adresářových služeb byly nastíněny v kap Základní datová jednotka umístěná v adresářových službách se nazývá položka. Položka má atributy, které popisují její vlastnosti. Jak položka, tak atribut jsou identifikovány jménem (obr. 1.1 na straně 2) Atributy, syntaxe atributů Každý atribut má přiřazen typ, tj. informaci o tom, jaké hodnoty může nést, neboli informaci o syntaxi pro zápis hodnot atributu. Typ atributu také definuje zacházení s hodnotou atributu při operacích, například při prohledávání či porovnávání. Například je definován typ atributu pro uložení telefonního čísla. Atribut označený tímto typem může obsahovat libovolný text, přičemž znaky jako mezera a pomlčka se ignorují pro účely porovnávání. Dále se ignoruje velikost písmen a je definováno lexikografické uspořádání. Základní typy hodnot atributů jsou uvedeny v následující tabulce: Typ atributu ces cis tel bin dn význam řetězec znaků, při porovnávání se bere ohled na velikost písmen (Case Exact String) řetězec znaků, při porovnávání se nebere ohled na velikost písmen (Case Insensitive String) telefonní číslo, tj. řetězec znaků, mezery a pomlčky jsou při porovnávání ignorovány stejně tak jako velikost písmen libovolná (binární) data rozlišovací jméno (objektu v adresářových službách) 11
15 Kapitola 1, Adresářové služby Schéma Také jména atributů a jejich význam, samozřejmě včetně přiřazení typu atributu, jsou standardizována. Každá položka má navíc přiřazen typ, který popisuje které atributy se musí a které se mohou u ní vyskytovat. Globálně se pro označení popisu těchto pravidel používá pojmu schéma. Příklady některých nejběžnějších atributů, jejich typ a význam: Jméno atributu, alias typ atributu význam organization, o cis jméno organizace organizationalunitname, ou cis jméno organizační jednotky commonname, cn cis common name položky surname, sn cis jméno osoby, kterou položka reprezentuje telephonenumber tel telefonní číslo jpegphoto bin portrét osoby, kterou položka reprezentuje ve formátu JPEG Schéma definuje třídy objektů (object class), tj. typy položek, které se mohou vyskytovat v adresářovém stromu. Třída objektu definuje jména a typy atributů, které se mohou v objektu (položce) vyskytovat, přičemž určuje, které z nich jsou povinné (musí se vyskytovat). Typ položky ve formě jména třídy objektu je u každé položky uveden ve vyhrazeném a povinném atributu objectclass. Příklady tříd objektů (obsahují pouze příklady atributů, přičemž tučně tištěné jsou povinné): Třída objektu význam příklad atributů inetorgperson Reprezentuje člověka (v rámci intranetu) commonname (cn) surname (sn) objectclass mail telephonenumber organization Reprezentuje organizaci organization (o) objectclass location (l) postaladdress seealso Při definování tříd objektů je možno používat dědičnost, tj. definovat novou 12
16 1.6 Jmenný model třídu objektů jako rozšíření jiné, již definované třídy. Schéma lze tedy chápat také jako hierarchii tříd objektů 6. Schéma dává možnost definovat vlastní datové typy, definovat popis nových objektů nebo rozšiřovat či měnit popis běžných objektů. Pro interoperabilitu je velmi důležitá standardizace, proto je třeba vycházet ze standardizovaných schémat. Základní informace z této oblasti lze najít v [3] a [7]. Pro pokročilejší řešení interoperability je definován v rámci LDAP verze 3 mechanismus pro publikaci schématu. Adresářový server poskytuje některé základní informace o sobě včetně schématu, klienti mohou definovaným způsobem k těmto informacím přistupovat. Pro textový zápis položky a obsahu adresářového stromu je definována syntaxe LDIF (LDAP Data Interchange Format) viz kap Základní nástroje pro komunikaci s adresářovým serverem z příkazové řádky (viz kap. 1.10) používají pro zápis dat také formát LDIF. LDAP informační model Datové entity: položka, atribut. Položka má typ položky (třída objektu), obsahuje atributy, má jméno, DN (rozlišovací jméno) globální v rámci DIT, uspořádání do Directory Information Tree (DIT). Atribut má typ, má hodnotu, resp. hodnoty, má jméno identifikaci v rámci položky. Schéma rozšiřitelnost (ale také standardizace). 1.6 Jmenný model Základní koncept jmenného modelu byl nastíněn již v kapitole 1.2. Položky jsou organizovány do hierarchické struktury zvané Directory Information Tree (DIT). Každá položka je jednoznačně identifikována jménem (DN), přičemž toto jméno jednoznačně určuje polohu položky v rámci stromu. 6 Atribut objectclass obsahuje jména všech tříd objektů, které jsou použity pro definici aktuální třídy objektu, tj. ze kterých je aktuální třída objektů odvozena. 13
17 Kapitola 1, Adresářové služby 1.7 Funkční model Standardní operace protokolu LDAP lze rozdělit do tří kategorií: Dotazování a prohledávání slouží pro získávání informací z adresářového stromu. Operace search a compare. Změny dat operace add, delete, modify (modifyrdn). Základní prostředky pro změnu dat. Autentizace navázání spojení a prokázání identity uživatele. Operace bind a unbind Operace search Pro realizaci veškerého přístupu k datům (čtení) v adresářovém serveru slouží jediná operace, prohledávání. Tato operace je navržena obecně, tj. pokryje jak potřebu hledání, tak čtení přesně specifikovaných dat. Specifikace požadavku pro operaci search se definuje prostřednictvím několika základních parametrů: Báze Rozlišovací jméno definující nejvyšší objekt v hierarchii DIT, který je prohledáván. Rozsah Specifikuje rozsah prohledávání vzhledem k bázovému objektu. Lze požadovat prohledání celého podstromu, jedné úrovně podstromu či pouze bázového objektu samého. Prohledávací filtr Pro definici kritéria pro výběr vyhovujících položek existuje relativně komplexní syntaxe a sémantika tzv. prohledávacího filtru. Základní syntaxe filtru je: <atribut> <operátor> <hodnota> kde nejjednodušším operátorem je rovnítko, například sn=sitera. Filtry lze skládat pomocí logických operací. Syntaxe je: ( <operátor> (<filtr>) (<filtr>) (<filtr>)...) 14
18 1.7 Funkční model například (& (ou=civ)(mail=si*)), kde & je operátor logického součinu a * zástupný znak pro libovolný řetězec. Pak tedy tento příklad definuje prohledávací filtr, jemuž vyhovují všechny položky mající atribut ou s hodnotou civ a atribut mail s hodnotou, která začíná znaky si. Podrobnější informace o syntaxi filtru viz [5]. Atributy k vyzvednutí Je možno omezit množinu atributů, které jsou z hlediska konkrétního dotazu zajímavé. Limity Klient může omezit maximální počet položek vrácených dotazem nebo maximální objem času který je možno věnovat na zodpovězení dotazu. To je užitečná vlastnost v případě dotazů, u kterých není z hlediska klienta jasná informace o objemu položek, které splňují kritéria dotazu Operace compare Operace compare slouží speciálně pro porovnání hodnoty atributu konkrétní položky se zadanou hodnotou. Vrací logickou hodnotu Operace pro změnu dat Operace pro změnu dat: add delete modify modifyrdn Vytvoření nové položky. Zrušení existující položky. Mohou být smazány pouze položky, které jsou listy stromu (tj. pokud neexistují žádné položky umístěné v podstromu mazané položky). Slouží ke změnám uvnitř existující položky. Dovoluje měnit hodnotu atributu, mazat atribut a přidávat nový atribut. Slouží ke změně rozlišovacího jména položky. Dovoluje změnit pouze relativní rozlišovací jméno v rámci větve, ve které je položka umístěna Autentizační operace Operace pro navázání a řízení komunikace: bind unbind abandon Navázání spojení mezi LDAP serverem a klientem. Při navázání spojení probíhá autentizace. Zrušení spojení mezi LDAP serverem a klientem. Operace, kterou klient požaduje zrušení nedokončené (předchozí) operace. 15
19 Kapitola 1, Adresářové služby Vlastní autentizace může být provedena několika standardními mechanismy. Více viz kap Možnosti rozšíření funkčního modelu Také funkčního model je navržen jako rozšiřitelný. Jednak je možno definovat tzv. controls, což jsou dodatečná rozšíření standardních operací, jednak je možno definovat zcela nové operace (extended operations). LDAP funkční model Prohledávání obecně definovaná operace search. Změna dat, na úrovni položek a na úrovni atributů. Otevřený návrh, rozšiřitelnost. 1.8 Bezpečnostní model Z hlediska bezpečnosti lze v rámci protokolu LDAP hovořit především o autentizaci uživatele, tj. metodě prokázání identity (a tím vazbě uživatele na položku která ho reprezentuje v adresářovém stromu), o bezpečnosti obecně (zabezpečení proti odposlechu a napadení komunikace) a o autorizaci (řízení přístupových práv k jednotlivým objektům a operacím nad nimi). Autorizace není dosud součástí žádného přijatého standardu. Existuje řada řešení (obvykle formou přístupových listů, např. Netscape [20]) a návrh standardu Autentizace Z hlediska prokázání identity uživatele (autentizace) lze v současných adresářových službách mluvit o třech základních možnostech: 16 Žádná autentizace Nejjednodušší přístup, určený obvykle pouze pro čtení veřejných položek, je anonymní. V tomto případě není potřeba provádět žádnou autentizaci. Základní autentizace Jednoduchá metoda prokázání identity uživatele. Klient specifikuje DN uživatele a jeho heslo. Heslo je uloženo (obvykle přes jednosměrnou šifru) v atributu příslušné adresářové položky.
20 1.8 Bezpečnostní model SASL (Simple Authentication and Security Layer) SASL (Simple Authentication and Security Layer) je standardizovaná ([1]) cesta pro dodatečné zabezpečení spojově orientovaných komunikačních protokolů. Jedná se v podstatě o jasně definované rozhraní, jehož prostřednictvím lze propojovat standardní autentizační mechanismy s komunikačnímy protokoly. Podpora SASL je novou vlastností standardu LDAP verze 3. Základní schéma použití SASL autentizace je následující: I. Klient předá informace pro autentizaci: DN rozlišovací jméno entity, která se autentizuje. mechanismus identifikace SASL autentizačního mechanismu. Server může prostřednictvím SASL podporovat několik autentizačních mechanismů 7. Běžně podporovaným autentizačním mechanismem je SSL (nebo jeho následník TLS - viz kap ) 8, přičemž tyto protokoly poskytují také zabezpečení komunikace. credentials data prokazující identitu (v příslušném autentizačním mechanismu). II. Přes LDAP API dojde autentizační požadavek LDAP serveru, který pro jeho vyřízení použije příslušný autentizační modul (dle zadaného mechanismu). III. Příslušný autentizační modul na základě předaných dat rozhodne, zda je identita prokázána či nikoli. Za tímto bodem se může skrývat další komunikace vlastní autentizačnímu mechanismu (např. Kerberos) Zabezpečení komunikace Protokol SSL (Secure Socket Layer) je určen jak pro zabezpečení komunikace tak pro provádění autentizace komunikujících entit. Slouží primárně pro zabezpečení TCP/IP komunikace jako mezivrstva mezi aplikací a běžnou TCP/IP komunikační abstrakcí (sokety). Další informace o protokolu SSL a TLS (Transport Layer Security) přesahují rámec tohoto dokumentu. Lze pouze doporučit některé základní informační zdroje [11, 12, 13]. 7 Samozřejmě server musí podporovat klientem použitý autentizační mechanismus, jinak nemůže autentizace uspět. Podporované autentizační mechanismy lze získat standardizovaným LDAP dotazem. 8 Mezi jiné možné autentizační mechanismy patří: Kerberos, S/Key, GSSAPI ([8]), CRAM- MD5. 17
21 Kapitola 1, Adresářové služby LDAP bezpečnostní model Autentikace prokázání identity uživatele, vazba na objekt v adresářových službách. Zabezpečení komunikace, odolnost proti napadení. Autorizace řízení přístupu. 1.9 LDIF LDIF (LDAP Interchange Format) [14] je textový formát pro zápis obsahu adresářových služeb. Slouží také jako prostředek pro zápis operací pro změnu obsahu adresářových položek. LDIF se používá především pro hromadné změny dat, import a export dat (přenos ze serveru na server) apod. LDIF také využívají nástroje pro komunikaci s LDAP serverem z příkazové řádky. V této kapitole lze najít základní nástin formátu LDIF, další iformace viz doporučená literatura LDIF formát pro zápis adresářových položek Popišme použití formátu LDIF pro zápis adresářových položek. LDIF soubor se skládá z bloků dat oddělených prázdnou řádkou. Každý blok dat reprezentuje jednu položku. Základní struktura: dn: <rozlišovací jméno> objectclass: <třída objektu>... <jméno atributu>: <hodnota atributu>... Atribut objectclass je z hlediska formátu LDIF atribut jako každý jiný, jeho zvýraznění ve výše uvedené struktuře slouží pouze k přiblížení obvyklého vzhledu LDIF formátu položky. Příklad položky: 18 dn: cn=jiri Sitera, ou=civ, ou=staff, ou=people, o=zcu, c=cz objectclass: top objectclass: organizationalperson objectclass: inetorgperson cn: Jiri Sitera sn: Sitera mail: sitera@civ.zcu.cz seealso: sitera l: UI404
22 1.10 Nástroje pro komunikaci s LDAP serverem z příkazové řádky LDIF formát pro zápis změn adresářových položek Způsob zápisu příkazů pro modifikaci položek v adresářových službách je popsán v kapitole LDIF Standardní textový formát pro zápis dat v adresářových službách. Slouží také pro zápis příkazů pro modifikaci dat v adresářových službách. Pro hromadné změny dat, export a import databáze adresářového serveru Nástroje pro komunikaci s LDAP serverem z příkazové řádky Nástroje pro komunikaci s LDAP serverem z příkazové řádky jsou obvykle součástí prostředků pro tvorbu aplikací, často označovaných jako SDK (Software Development Kit). Nicméně v hlavních rysech jsou zcela kompatibilní. Základní použití těchto nástrojů je nastíněno v následujících odstavcích. Více informací viz příslušná dokumentace, např. [18] Prohledávání adresářového stromu ldapsearch Funkce ldapsearch odpovídá operaci search LDAP funkčního modelu. Základní použití: ldapsearch -h <LDAP server> -b <báze> <prohledávací filtr> například: ldapsearch -h pleiades.zcu.cz -b o=zcu,c=cz sn=sitera Dále lze parametry prohledávání určit především: seznam atributů, jejichž hodnoty mají být vráceny, rozsah prohledávání, port na kterém je LDAP server (implicitně 389), limity, autentizační data (jednoduchá autentizace, tj. DN a heslo), zabezpečení a autentizaci, obvykle se používá SSL. 19
23 Kapitola 1, Adresářové služby Modifikace položek adresářového stromu ldapmodify, ldapdelete, ldapmodrdn Příkaz ldapmodify používá pro zadávání požadavků na modifikaci adresářových položek tzv. LDIF update formát. Základní syntaxe je: dn: <rozlišovací jméno> changetype: <typ změny> <bližší specifikace změny> <seznam atributů>... - <bližší specifikace změny> <seznam atributů>... Například pro provádění základních změn uvnitř položky se užívá specifikace changetype:modify, přičemž bližší specifikace změny může být: add: <jméno atributu> přidá specifikovaný atribut a jeho hodnotu do položky. Existuje-li již takový atribut, přidá mu další hodnotu. Například: dn: cn=jiri Sitera, ou=civ, ou=staff, ou=people, o=zcu, c=cz changetype: modify add: telephonenumber telephonenumber: 580 delete: <jméno atributu> smaže specifikovaný atribut z položky. Pokud má specifikovaný atribut více hodnot, smaže všechny. Je-li potřeba smazat pouze jednu hodnotu a ostatní ponechat, je možno ke jménu atributu připsat hodnotu, která se má smazat. replace: <jméno atributu> slouží k obecné modifikaci atributu zadáním cílového stavu, tj. neexistuje-li atribut, je vytvořen a neníli specifikována žádná nová hodnota, tak je případný původní atribut smazán. Další typy změny jsou: add, delete a modrdn. Takto lze pomocí příkazu ldapmodify a příslušného LDIF vstupu zakládat, mazat a přejmenovávat položky. Přidání nových položek lze také realizovat na základě běžného LDIF souboru popisujícího tyto položky. K tomu slouží přepínač -a příkazu ldapmodify 20
24 1.10 Nástroje pro komunikaci s LDAP serverem z příkazové řádky poté je operace add implicitní. Smazání položky je možno také realizovat příkazem ldapdelete. Poznamenejme ještě, že při operacích, které mění data v adresářovém serveru, je potřeba použít autentizaci a pravděpodobně také zabezpečení komunikace (SSL). 21
25 Kapitola 2 LDAP Co dále? Vzhledem k rozsahu tohoto dokumentu není možno pokročilejší a praktičtější otázky probírat podrobně. Proto se tato kapitola snaží poskytnout stručnou formou základy pro praktickou práci s adresářovými službami, jmenovitě protokolem LDAP a pro studium informací z této oblasti, které sami o sobě překračují rámec tohoto dokumentu. 2.1 Některé další důležité vlastnosti protokolu LDAP LDAP URL V rámci snah o standardizaci protokolu LDAP a využití adresářových služeb jako jednotné informační infrastruktury byl navržen URL (Universal Resource Locators) [24] formát pro přístup k LDAP službám. LDAP URL je přijatým standardem [6] a podporuje ho řada aplikací (například Netscape Navigator 4.0). Základní syntaxe LDAP URL: kde: ldap://<host>:[<port>] [/ [<dn>[? [<atributy>] [? [<rozsah>] [? [<filtr>]]]]]] ldap host port dn atributy rozsah filtr Specifikuje protokol LDAP. Může zde být také ldaps což určuje použití protokolu LDAP přes SSL (implicitní port 636). Jméno LDAP serveru. TCP/IP port na kterém je přítomen server. Rozlišovací jméno určující bázi pro hledání. Seznam atributů, které mají být získány. Rozsah hledání. base, one nebo sub. Implicitní je base. Filtr pro hledání. Implicitní je objectclass=* Příklad použití LDAP URL pro dotaz: 22
26 2.2 Kostra základního nasazení adresářových služeb ldap://pleiades.zcu.cz/o=zcu,c=cz??sub?sn=sitera LDAP URL je velmi flexibilní může vyjadřovat odkaz na LDAP server, odkaz na položku v adresářových službách nebo LDAP dotaz. LDAP URL lze také s výhodou používat pro specifikaci dotazů v aplikacích Odkazy LDAP server nemusí obsahovat celý adresářový strom. Tento strom může být rozprostřen mezi hierarchicky uspořádané servery. Každý server obsahuje jeden podstrom 1 a některé položky mohou reprezentovat odkaz, tzv. referal. Tímto způsobem jsou jednotlivé servery, a části dat v nich umístěné, propojeny. Kořenová položka podstromu se nazývá suffix, nebot její název je vždy suffixem rozlišovacích jmen všech položek v podstromu se nacházejících. Odkaz (referal) je speciální položka (objectclass=referal), jež slouží jako ukazatel na server, který obsahuje příslušný podstrom. Pro zápis odkazu se používá atribut ref a LDAP URL. Více informací o odkazech viz doporučená LDAP literatura a dokumentace k příslušnému vývojovému nástroji (většina implementací LDAP API poskytuje transparentní vyhodnocování odkazů) Replikace Z hlediska návrhu implementace adresářových služeb je samozřejmě důležitým faktorem dostupnost a rozšiřitelnost ( škálovatelnost ). První z mechanismů pro zajištění robustnosti infrastuktury LDAP služeb, členění na části (partitioning), je realizováno výše popsaným mechanismem odkazů. Data jsou rozdělena do hierarchicky uspořádaných částí, přičemž každá část je poskytována samostatnými prostředky. Druhým mechanismem je replikace. Adresářový server může mít několik replik, tj. serverů, které poskytují stejná data. Datový obsah je mezi replikami udržován konzistentní a je zajištěna základní funkce systému i v případě výpadku některého ze serverů. Více informací opět viz příslušná dokumentace, např. [20, 15]. 2.2 Kostra základního nasazení adresářových služeb Nastiňme nyní, které základní kroky je třeba provést v rámci nasazení adresářových služeb. Předpokládejme základní nasezení, tj. jako seznam lidí s 1 Ve skutečnosti může LDAP server obsahovat několik podstromů. 23
27 Kapitola 2, LDAP Co dále? informacemi o nich. Mezi takové informace patří především telefon, fax, kancelář, příslušnost organizační jednotce, , atd. Mezi funkce může patřit telefonní seznam s vazbou na běžné aplikace ( ,...). Server výběr a instalace serverového SW. Obvykle je k dispozici dokumentace s informacemi nejen o instalaci, ale i konfiguraci a návrhu adresářových služeb. Patří sem samozřejmě návrh fyzické infrastruktury, tj. především otázky replikace a rozčlenění dat. To je samozřejmě již úzce vázáno na návrh DIT. Pravděpodobně nejlepší cesta pro většinu případů je učinit základní návrh a postupovat dále dle naznačeného schématu, přičemž celek bude sloužit jako ověrovací implementace a v rámci posledního kroku se navrhnou změny vedoucí k nasazení do produkčního prostředí. Schéma volba, respektive návrh informačního modelu. V našem případě nejspíše vybereme některou ze standardních tříd objektů. Pro realizaci objektů pro uživatele se hodí organizationalperson či inetorgperson. Je samozřejmě třeba navrhnout DIT a realizovat jeho uzly. K tomu se hodí třída objektů organization a organizationalunit. Klient je třeba navrhnout základní využití adresářových služeb. V první fázi postačí nástroje pro komunikaci s LDAP serverem z příkazové řádky a standardní aplikace (mail klient, WEBový prohlížeč). Je možné vybrat si a vyzkoušet některý z pokročilejších nástrojů, jako je WWW LDAP brána (gateway) či samostatný LDAP prohlížeč (browser). Rozhraní nástroje, synchronizace, migrace dat jedním z důležitých kroků je samozřejmě naplnění daty. Po prvních pokusech s testovacími daty bude nutno navrhnout mechanismy pro získání reálných dat. Samozřejmě, že zde se dotýkáme velmi komplexního problému, který se často označuje pojmem metadirectory integrace existujících zdrojů dat, resp. přechod na jednotnou bázi dat. Zde bude potřeba stanovit postupy a navrhout nástroje pro synchronizaci dat, resp. pro jejich migraci. Existuje řada postupů a nástrojů v této oblasti 2. Mezi nejjednodušší začátek patří transformace dat z existujících systémů do formátu LDIF a import tohoto souboru. Konfigurace aplikací viz dokumentace příslušných aplikací. Velmi mnoho současných klientů podporuje LDAP pro získávání adres lidí (viz například Netscape Communicator Mail). Údržba, restrukturalizace pro nasazení do produkčního prostředí 2 V této oblasti lze najít řadu komerčních (více či méně komplexních) řešení. Je také třeba si uvědomit, že s tímto usílím souvisí práce s vlastním obsahem dat, často označovaná (po právu) termínem konsolidace dat. 24
28 2.3 Hlavní implementace 2.3 Hlavní implementace Jmenujme nyní, bez nároku na úplnost a správnost výběru, několik základních implementací LDAP serveru a souvisejících věcí. University of Michigan LDAP implementace tato práce otevřela svět LDAPu tak, jak je nastíněn v tomto dokumentu. Je k dispozici standalone LDAP directory server (slapd), standalone LDAP update replication daemon (slurpd), front end for an X.500 DSA a mnoho vývojových nástrojů. Vše je k dispozici volně včetně zdrojových textů [16]. Netscape Communications dobře podporovaná rozvíjející se technologie LDAPu. Adresářový server s modulární architekturou, podporou LDAPv3 a mnoha rozšířeními (autorizace, schéma, integrace s ostatními produkty). Jsou k dispozici nástroje pro tvorbu aplikací (C SDK, Java SDK, modul pro Perl PerLDAP). Nástroje pro tvorbu aplikací jsou k dispozici včetně zdrojových textů zdarma, server je komerční [21]. OpenLDAP projekt OpenLDAP, vývoj LDAP technologie na otevřené bázi, vychází z implementace University of Michigan. Rychle se rozvíjející projekt, server i vývojové nástroje volně šířené včetně zdrojových textů [17]. 2.4 Vývojové nástroje Kromě knihoven SDK pro C a Javu, které jsou součástí mnoha implementací LDAPu, stojí za alespoň stručnou zmínku především: Java Naming and Directory Interface (JNDI) rozhraní pro tvorbu aplikací v jazyce Java. Jedná se o zobecněné rozhraní k jmenným a adresářovým službám, které dovoluje jednotné zacházení se souborovým systémem, DNS a LDAPem. JNDI je navrženo jako otevřené vzhledem k dalším jmenným službám. Oproti LDAP Java SDK poskytuje abstrakci vyšší úrovně. Více viz [25]. PerLDAP knihovna pro programovací jazyk Perl, která poskytuje objektově orientované rozhraní pro práci s adresářovými službami [22]. 2.5 Kde hledat další informace a zkušenosti Možností je mnoho. Uved me několik základních vstupních bodů. 25
29 Kapitola 2, LDAP Co dále? Innosoft s LDAP World, dříve Critical Angle. Mnoho informací a odkazů udržovaných Markem Wahlem, autorem UMICH LDAPu. An LDAP Roadmap & FAQ, Kings Mountain Systems, udržuje Jeff Hodges, Stanford. 26
30 Použitá a doporučená literatura [1] RFC 2222, Simple Authentication and Security Layer (SASL). [2] Wahl, M., Howes, T., Kille, S., Lightweight Directory Access Protocol (v3), RFC 2251, Critical Angle, Inc., ISODE Consortium, Netscape Communications Corp., July, [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, RFC 2252, December [4] Wahl, M., Kille, S., and T. Howes, Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, RFC 2253, December [5] T. Howes, Lightweight Directory Access Protocol (v3): The String Representation of LDAP Search Filters, RFC 2254, December [6] T. Howes, M. Smith, The LDAP URL Format, RFC 2255, December [7] RFC 2256, A Summary of the X.500: User Schema for use with LDAPv3. [8] RFC 2078, Generic Security Service Application Program Interface. [9] Jim Rommel, Perot System Corporation: DIT Design. Electronic Messaging Association Conference [10] Jiří Sitera: Administrace TCP/IP sítí v prostředí OS UNIX. Akademie informačních technologií ZČU Plzeň, materiály pro posluchače, [11] Netscape Communications, The SSL Protocol Version 3.0, Secure Sockets Layer, Internet Draft, [12] RFC 2246, The TLS Protocol Version 1.0,Transport Layer Security protocol. [13] LDAPExt Working Group, Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security, Internet Draft, draft-ietf-ldapext-ldapv3-tls-04.txt 27
31 Použitá a doporučená literatura [14] Gordon Good, Netscape Communications, The LDAP Data Interchange Format (LDIF) - Technical Specification, Internet Draft, draft-good-ldap-ldif-02.txt [15] University of Michigan, The SLAPD and SLURPD Administrator s Guide, dirsvcs/ldap/doc/guides/slapd [16] University of Michigan, Lightweight Directory Access Protocol, dirsvcs/ldap/ [17] The OpenLDAP Project, Open source suite of LDAP applications and development tools, [18] Netscape Communications, Netscape Directory Server 3.0 Administrator s Guide, [19] Netscape Communications, Netscape Directory Server 3.0 Deployment Guide, [20] Netscape Communications, Netscape Directory Server Documentation, [21] Netscape Communications, Directory Developer Central, [22] Netscape Communications, PerLDAP Central, central.html [23] Recommendations X.500, OSI Directory Standard, [24] Berners-Lee, T., Masinter, L. and M. McCahill, Uniform Resource Locators (URL), RFC 1738, December [25] Java Naming and Directory Interface (JNDI), Java Standard Extension 28
Adresářové služby úvod do problematiky
Technická zpráva TEN-155 CZ číslo 4/2000 Adresářové služby úvod do problematiky Jiří Sitera 7. září 2000 1 Adresář ovéslužby Tato kapitola se snaží o přiblížení pojmu adresářové služby a poskytuje přehled
VíceAutor. Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech
Adresářová služba X.500 a LDAP Autor Martin Lasoň Abstrakt Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech vedla ke vzniku specializovaných databází adresářů.
VíceX36PKO Jmenné služby Jan Kubr - X36PKO 1 4/2007
X36PKO Jmenné služby Jan Kubr - X36PKO 1 4/2007 Program úloha jmenných služeb informace ve jmenných službách jmenné služby X.500 DNS ostatní Jan Kubr - X36PKO 2 4/2007 Úloha jmenných služeb specializovaná
VícePDS. Obsah. protokol LDAP. LDAP protokol obecně. Modely LDAP a jejich funkce LDIF. Software pro LDAP. Autor : Petr Štaif razzor_at
PDS Adresářov ové služby a protokol LDAP Autor : Petr Štaif e-mail : razzor_at at_tiscali.czcz Obsah Adresářov ové služby LDAP protokol obecně Modely LDAP a jejich funkce LDIF Software pro LDAP Závěr Adresářov
VíceThe Lightweight Directory Access Protocol version 3 (LDAPv3) is specified by this set of eleven RFCs:
The Lightweight Directory Access Protocol version 3 (LDAPv3) is specified by this set of eleven RFCs: [RFC2251] Lightweight Directory Access Protocol (v3) [the specification of the LDAP on-thewire protocol]
VíceProjekt Pleiades informační infrastruktura z pohledu
Projekt Pleiades informační infrastruktura z pohledu jejího uživatele Jiří Sitera Centrum informatizace a výpočetní techniky, Laboratoř počítačových systémů, Západočeská univerzita v Plzni, e-mail: sitera@civ.zcu.cz
VíceWindows Server 2003 Active Directory
Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,
VíceSNMP Simple Network Management Protocol
SNMP Simple Network Management Protocol Vypracoval: Lukáš Skřivánek Email: skrivl1@fel.cvut.cz SNMP - úvod Simple Network Management Protocol aplikační protokol pracující nad UDP (porty 161,162) založený
VíceAdresářové služby, DNS
Adresářové služby, DNS RNDr. Ing. Vladimir Smotlacha, Ph.D. Katedra počítačových systémů Fakulta informačních technologií České vysoké učení technické v Praze Vladimír Smotlacha, 2011 Počítačové sít ě
VíceOsnova dnešní přednášky
Osnova dnešní přednášky Pracovní skupina x doména Active Directory Něco z historie Použité technologie Pojmy Instalace Active Directory DNS DNS v Active Directory Pracovní skupina x doména Pracovní skupina
VíceTÉMATICKÝ OKRUH Softwarové inženýrství
TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího
VícePřípadová studie: Adresářové řešení pro webhosting pomocí ApacheDS. Lukáš Jelínek
Případová studie: Adresářové řešení pro webhosting pomocí ApacheDS Lukáš Jelínek AIKEN Webhosting primárně pro provoz zakázkových projektů klasická platforma Linux+Apache+PHP+MySQL (LAMP) + databáze SQLite
VíceÚvod do informatiky 5)
PŘEHLED PŘEDNÁŠKY Internet Protokol a služba Jmenná služba (DNS) URL adresa Elektronická pošta Přenos souborů (FTP) World Wide Web (WWW) Téměř zapomenuté služby 1 INTERNET 2 PROTOKOL A SLUŽBA Protokol
VíceMetody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka
Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce
VíceInovace výuky prostřednictvím šablon pro SŠ
Název projektu Číslo projektu Název školy Autor Název šablony Název DUMu Stupeň a typ vzdělávání Vzdělávací oblast Vzdělávací obor Tematický okruh Cílová skupina Anotace Inovace výuky prostřednictvím šablon
VíceIdentifikátor materiálu: ICT-3-03
Identifikátor materiálu: ICT-3-03 Předmět Téma sady Informační a komunikační technologie Téma materiálu TCP/IP Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí architekturu TCP/IP. Druh
VíceTECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY
Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS
VíceInformační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází
1 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Požadavky kreditového systému. Relační datový model, relace, atributy,
Více8.2 Používání a tvorba databází
8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam
VíceEXTRAKT z mezinárodní normy
EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové
Více1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4
CRM SYSTÉM KORMORÁN PŘÍRUČKA ADMINISTRÁTORA Obsah 1 Administrace systému 3 1.1 Uživatelské účty.................................. 3 1.2 Přístupová práva................................. 3 1.3 Moduly.......................................
VíceIdentity and Access Management
Identity and Access Management Praktické cvičení pavel.horal@orchitech.cz Cíl cvičení Identity & Access Management Identity Management Část IdM Seznámení s OpenIDM Načtení HR exportu Synchronizace do LDAPu
VíceInternet Information Services (IIS) 6.0
Internet Information Services (IIS) 6.0 V operačním systému Windows Server 2003 je obsažena i služba IIS v 6.0. Služba IIS poskytuje jak www server tak i některé další služby (FTP, NNTP,...). Jedná se
VíceČ á s t 1 Příprava instalace
Obsah Úvod 31 Seznámení se s rodinou produktů 31 Co je nového v systému Windows Server 2003 32 Práce s touto příručkou 32 Obsah této příručky 33 Obsah disku CD-ROM 34 Komunikujte s námi 35 Část 1 Příprava
Více1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services
13. Webové služby. K čemu slouží? Popis a vyhledávání služeb. Co je a k čemu slouží orchestrace a choreografie služeb. Technologie pro implementaci služeb 1. Webové služby. K čemu slouží? Definice WS -
VíceRoční periodická zpráva projektu
WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových
VíceEU-OPVK:VY_32_INOVACE_FIL9 Vojtěch Filip, 2013
Číslo projektu CZ.1.07/1.5.00/34.0036 Tématický celek Inovace výuky ICT na BPA Název projektu Inovace a individualizace výuky Název materiálu Komunikační protokoly v počítačových sítích Číslo materiálu
VíceDatum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží
Číslo projektu CZ.1.07/1.5.00/34.0394 Škola SOŠ a SOU Hustopeče, Masarykovo nám. 1 Autor Ing. Miriam Sedláčková Číslo VY_32_INOVACE_ICT.3.01 Název Teorie internetu- úvod Téma hodiny Teorie internetu Předmět
VíceEXTRAKT z mezinárodní normy
EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS: 03.220.01; 35.240.60 Inteligentní dopravní systémy Komunikační infrastruktura pro
VíceReplikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou
Administrace Oracle Replikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou zachyceny a uloženy lokálně před posláním
VíceFreeIPA a SSSD. Správa uživatelů pomocí Free Software. LinuxAlt 2009 Jakub Hrozek Martin Nagy 30. listopadu 2009
FreeIPA a SSSD Správa uživatelů pomocí Free Software LinuxAlt 2009 Jakub Hrozek Martin Nagy 30. listopadu 2009 1 Úvod 2 FreeIPA 3 SSSD Section 1 Úvod Úvod Správa uživatelů a systémů definice problému:
Více14.4.2010. Obsah přednášky 7. Základy programování (IZAPR) Přednáška 7. Parametry metod. Parametry, argumenty. Parametry metod.
Základy programování (IZAPR) Přednáška 7 Ing. Michael Bažant, Ph.D. Katedra softwarových technologií Kancelář č. 229, Náměstí Čs. legií Michael.Bazant@upce.cz Obsah přednášky 7 Parametry metod, předávání
VíceDOPLNĚK. Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj.
GLOBÁLNÍ ARCHITEKTURA ZÁKLADNÍCH REGISTRŮ DOPLNĚK Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj. Obsah 1 Cíle dokumentu...3 2
VíceMicrosoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR
Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka
VíceRegistrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován
VíceReferenční rozhraní. Jiří Kosek. Ministerstvo informatiky ČR. ISSS 25. března 2003
Jiří Kosek Ministerstvo informatiky ČR ISSS 25. března 2003 Požadavky na RR!zákon 365/2000 Sb.!RR je souhrnem opatření, která vytvářejí jednotné integrační prostředí informačních systémů veřejné správy!rr
VíceEXTRAKT z technické normy ISO
EXTRAKT z technické normy ISO Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě. Inteligentní dopravní systémy Kooperativní ITS Zkušební architektura ISO/TS 20026
VíceÚvod 17 ČÁST 1. Kapitola 1: Principy návrhu doménové struktury služby Active Directory 21
Úvod 17 Proč číst tuto knihu? 18 ČÁST 1 Kapitola 1: Principy návrhu doménové struktury služby Active Directory 21 Kritéria návrhu doménové struktury služby Active Directory 22 Schéma 23 Aspekty návrhu
VícePOLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE
POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE INTERPI Interoperabilita v paměťových institucích Program aplikovaného výzkumu a vývoje národní kulturní identity (NAKI) (DF11P01OVV023) Zpracovali: Marie
Více1. Integrační koncept
Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury
VícePožadavky pro výběrová řízení TerraBus ESB/G2x
Dokument: Převod dat TerraBus ESB/G2x Požadavky pro výběrová řízení TerraBus ESB/G2x Obsah 1. Účel dokumentu... 2 2. Použité termíny a zkratky... 2 3. Požadavky... 3 Účel dokumentu Účelem tohoto dokumentu
VíceSystém souborů (file system, FS)
UNIX systém souborů (file system) 1 Systém souborů (file system, FS)! slouží k uchování dat na vnějším paměťovém médiu a zajišťuje přístup ke struktuře dat! pro uživatele možnost ukládat data a opět je
VíceIdentifikátor materiálu: ICT-3-10
Identifikátor materiálu: ICT-3-10 Předmět Téma sady Informační a komunikační technologie Téma materiálu Doména a služby Internetu Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí služby
VícePřístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace DNS
Aplikační vrstva Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace RIP DNS TELNET HTTP SNMP RTP SMTP FTP port UDP TCP IP 1 Aplikační
VícePŘÍRUČKA SÍŤOVÝCH APLIKACÍ
PŘÍRUČKA SÍŤOVÝCH APLIKACÍ Uložení protokolu tisku na síť Verze 0 CZE Definice poznámek V celé Příručce uživatele používáme následující ikony: Poznámky uvádějí, jak reagovat na situaci, která může nastat,
VíceCAL (CAN Application Layer) a CANopen
CAL (CAN Application Layer) a CANopen J. Novák České vysoké učení technické v Praze Fakulta elektrotechnická Katedra měření Průmyslový distribuovaný systém na bázi sběrnice CAN Pressure sensor Stepper
VíceTonda Beneš Ochrana informace podzim 2011
Autorizace informační systém může poskytovat různé úrovně ochrany objektů 1. žádná ochrana - postačující pokud dochází k samovolné časové separaci 2. isolace - (semi)paralelně běžící procesy jsou zcela
VícePočítačové sítě. Lekce 4: Síťová architektura TCP/IP
Počítačové sítě Lekce 4: Síťová architektura TCP/IP Co je TCP/IP? V úzkém slova smyslu je to sada protokolů používaných v počítačích sítích s počítači na bázi Unixu: TCP = Transmission Control Protocol
VíceENUM v telefonní síti Ostravské univerzity. M. Dvořák
ENUM v telefonní síti Ostravské univerzity Rok 2007 Číslo MD-ENUM-01 Oblast: počítačové sítě IP telefonie ENUM v telefonní síti Ostravské univerzity M. Dvořák Obsah ENUM...2 Co to je ENUM...2 Sestavení
Více10 Balíčky, grafické znázornění tříd, základy zapozdření
10 Balíčky, grafické znázornění tříd, základy zapozdření Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost příkazům balíčkům, grafickému
VíceAdministrační systém ústředen MD-110
SAS MD-110 Administrační systém ústředen MD-110 SAS MD-110 Administrační systém ústředen MD-110 Efektivní systém administrace poboček a parametrů ústředen Ericsson MD110 s přímou vazbou na telefonní seznam
VícePOKROČILÉ POUŽITÍ DATABÁZÍ
POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a
VíceSpecifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.
C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt
VíceKoncept centrálního monitoringu a IP správy sítě
Koncept centrálního monitoringu a IP správy sítě Implementace prostředí MoNet a AddNet Jindřich Šavel 31/5/2013 NOVICOM s.r.o. 2012 2013 Novicom All rights s.r.o. reserved. All rights reserved www.novicom.cz,
VíceInovace výuky prostřednictvím šablon pro SŠ
Název projektu Číslo projektu Název školy Autor Název šablony Název DUMu Stupeň a typ vzdělávání Vzdělávací oblast Vzdělávací obor Tematický okruh Inovace výuky prostřednictvím šablon pro SŠ CZ.1.07/1.5.00/34.0748
VíceDatabázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz
Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty
VíceINTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY
INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY Dušan Kajzar Slezská univerzita v Opavě, Filozoficko-přírodovědecká fakulta, Bezručovo nám. 13, 746 00 Opava, e-mail: d.kajzar@c-box.cz Česká pošta, s.p.,
VíceCCNA I. 3. Connecting to the Network. CCNA I.: 3. Connecting to the network
CCNA I. 3. Connecting to the Network Základní pojmy Konvergence sítí (telefony, TV, PC, GSM) SOHO (Small Office and Home Office) nabídka a prodej produktů evidence objednávek komunikace se zákazníky zábava
VíceSystém elektronického rádce v životních situacích portálu www.senorady.cz
Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML
VíceÚvod Bezpečnost v počítačových sítích Technologie Ethernetu
České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů Úvod Bezpečnost v počítačových sítích Technologie Ethernetu Jiří Smítka jiri.smitka@fit.cvut.cz 26.9.2011
VíceSSL Secure Sockets Layer
SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou
VíceProfilová část maturitní zkoušky 2017/2018
Střední průmyslová škola, Přerov, Havlíčkova 2 751 52 Přerov Profilová část maturitní zkoušky 2017/2018 TEMATICKÉ OKRUHY A HODNOTÍCÍ KRITÉRIA Studijní obor: 78-42-M/01 Technické lyceum Předmět: TECHNIKA
VíceAlgoritmizace prostorových úloh
INOVACE BAKALÁŘSKÝCH A MAGISTERSKÝCH STUDIJNÍCH OBORŮ NA HORNICKO-GEOLOGICKÉ FAKULTĚ VYSOKÉ ŠKOLY BÁŇSKÉ - TECHNICKÉ UNIVERZITY OSTRAVA Algoritmizace prostorových úloh Datové struktury Daniela Szturcová
VíceDATABÁZOVÉ SYSTÉMY. Metodický list č. 1
Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové
VíceObsah OLAP A ESO9... 3
Zpracoval: Tomáš Urych U Mlýna 2305/22, 141 Praha 4 Záběhlice Dne: 27.6.2008 tel.: +420 585 203 370-2 e-mail: info@eso9.cz Revize: Havlena Stanislav www.eso9.cz Dne: 1.7.2011 Obsah 1. OLAP A ESO9... 3
VíceUML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W
UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram
VíceVývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz
Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem
VíceTECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU
zadávací dokumentace TECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU Stránka 1 z 6 Obsah 1. Specifikace požadavků webové stránky... 4 2. Specifikace technických
VíceSIMATIC S IT. Micro Automation. Promoters Meeting October Představení CP IT SPIDER CONTROL TELESERVIS. TESTOVACÍ server.
SIMATIC S7-200 243-1 2005, Page 1 Program workshopu Začátek: 9.00 GPRS - aplikace pro GPRS, základy - jak nastavit vzdálenou stanici, knihovna instrukcí pro GPRS - jak nastavit server (SINAUT MICRO SC,
VícePočítačové sítě Aplikační vrstva Domain Name System (DNS)
Aplikační vrstva Domain Name System (DNS) DNS je distribuovaná databáze, kterou používají TCP/IP aplikace k mapování doménových jmen do IP adres (a naopak) DNS informace jsou rozprostřeny po množině DNS
VíceOsnova. GIOP a IIOP IDL IOR POA. IDL Klient Server. 2 Historie. 3 Princip a základní pojmy. 4 Implementace. 5 Aplikace CORBA
Common Object Request Broker Architecture FJFI ČVUT 9. 12. 2010 Osnova 1 2 3 4 5 Standard umožňující propojení aplikací psaných v různých jazycích a běžících na různých strojích a architekturách. Definuje
VíceObsah. Zpracoval:
Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč
VícePoslední aktualizace: 1. srpna 2011
Jmenné a adresářové služby Šárka Vavrečková Ústav informatiky, FPF SU Opava http://fpf.slu.cz/~vav10ui Poslední aktualizace: 1. srpna 2011 Jmenné a adresářové služby Jmenné (názvové) služby překlad jmenných
VíceIMPLEMENTACE SYSTÉMU GROUPWISE NA PEF ČZU V PRAZE IMPLEMENTATION OF THE SYSTEM GROUPWISE ON THE PEF ČZU PRAGUE. Jiří Vaněk, Jan Jarolímek
IMPLEMENTACE SYSTÉMU GROUPWISE NA PEF ČZU V PRAZE IMPLEMENTATION OF THE SYSTEM GROUPWISE ON THE PEF ČZU PRAGUE Jiří Vaněk, Jan Jarolímek Anotace: Příspěvek se zabývá hlavními trendy rozvoje programů pro
VíceMBI - technologická realizace modelu
MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,
VíceRelační vrstva SMB-Síťový komunikační protokol aplikační vrstvy, který slouží ke sdílenému přístupu k souborům, tiskárnám, sériovým portům.
Aplikační vrstva http-protokol, díky kterému je možné zobrazovat webové stránky. -Protokol dokáže přenášet jakékoliv soubory (stránky, obrázky, ) a používá se také k různým dalším službám na internetu
VíceMATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ
MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE
VíceCertifikační prováděcí směrnice
První certifikační autorita, a.s. Certifikační prováděcí směrnice (algoritmus RSA) Certifikační prováděcí směrnice (algoritmus RSA) je veřejným dokumentem, který je vlastnictvím společnosti První certifikační
VíceDefinice pojmů a přehled rozsahu služby
PŘÍLOHA 1 Definice pojmů a přehled rozsahu služby SMLOUVY o přístupu k infrastruktuře sítě společnosti využívající technologie Carrier IP Stream mezi společnostmi a Poskytovatelem 1. Definice základních
VíceKSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví
Koordinační středisko pro resortní zdravotnické informační systémy Budějovická 15/743 140 00 Praha 4 Počet stran: 10 KSRZIS Postup kroků nutných pro napojení nemocničního informačního systému s registrem
VícePříloha č. 12. Systém společného přihlašování, tzv. Single Sign On, ochrana dat
Název projektu: Redesign Statistického informačního systému v návaznosti na zavádění egovernmentu v ČR Příjemce: Česká republika Český statistický úřad Registrační číslo projektu: CZ.1.06/1.1.00/07.06396
Víceilé aspekty distribuovaných objektových systémů
Pokročil ilé aspekty distribuovaných objektových systémů Petr Grygárek rek 1 Komunikační protokoly 2 General Inter-ORB Interoperability Protocol (GIOP) Původně v CORBA Postupně přejat do RMI Implementace
VíceNastavení provozního prostředí webového prohlížeče pro aplikaci
Nastavení provozního prostředí webového prohlížeče pro aplikaci IS o ISVS - Informační systém o informačních systémech veřejné správy verze 2.03.00 pro uživatele vypracovala společnost ASD Software, s.r.o.
VíceElektronická evidence tržeb. Produkční prostředí Přístupové a provozní informace
Elektronická evidence tržeb Produkční prostředí Přístupové a provozní informace Verze 3.1 (odpovídá verzi datového rozhraní) Datum poslední verze dokumentu: 1.11.2016 Vymezení obsahu dokumentu Dokument
VíceEXTRAKT z technické normy CEN ISO
EXTRAKT z technické normy CEN ISO Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě. Inteligentní dopravní systémy Kooperativní ITS Zařízení stanice ITS pro přenos
VíceKolaborativní aplikace
Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, 638 00 Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů,
VíceGIS Geografické informační systémy
GIS Geografické informační systémy Obsah přednášky Prostorové vektorové modely Špagetový model Topologický model Převody geometrií Vektorový model Reprezentuje reálný svět po jednotlivých složkách popisu
VícePokročilé Webové služby a Caché security. Š. Havlíček
Pokročilé Webové služby a Caché security Š. Havlíček Webové služby co se tím míní? Webová služba metoda komunikace mezi dvěma elektronickými zařízeními přes internet Typicky jsou pomocí rozhraní přístupné
Více12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování
12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které
VíceKapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů
- 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa
VíceKritéria hodnocení praktické maturitní zkoušky z databázových systémů
Kritéria hodnocení praktické maturitní zkoušky z databázových systémů Otázka č. 1 Datový model 1. Správně navržený ERD model dle zadání max. 40 bodů teoretické znalosti konceptuálního modelování správné
VíceGIS Geografické informační systémy
GIS Geografické informační systémy Obsah přednášky Prostorové vektorové modely Špagetový model Topologický model Převody geometrií Vektorový model Reprezentuje reálný svět po jednotlivých složkách popisu
VíceSemináˇr Java X J2EE Semináˇr Java X p.1/23
Seminář Java X J2EE Seminář Java X p.1/23 J2EE Složitost obchodních aplikací robusní, distribuované, spolehlivé aplikace s transakcemi na straně serveru, klientské aplikace co nejjednodušší Snaha : Návrh,
VíceJádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb:
Technologie Marushka Základním konceptem technologie Marushka je použití jádra, které poskytuje přístup a jednotnou grafickou prezentaci geografických dat. Jádro je vyvíjeno na komponentním objektovém
VícePočítačové sítě Systém pro přenos souborů protokol FTP
Počítačové sítě Systém pro přenos souborů protokol FTP Autorizovaný přístup do souborového systému hostitelského uzlu Informace o obsahu souborového systému hostitelského uzlu Obousměrný přenos kopií souborů
VíceX33EJA Web Services. Martin Ptáček, KOMIX s.r.o.
X33EJA Web Services Martin Ptáček, KOMIX s.r.o. ptacek@komix.cz Copyright 2007 KOMIX Copyright s.r.o. 2007 KOMIX s.r.o. 1. Obsah Historie Co jsou Web Services? Co je to SOA? JAX-WS (Java API for XML Web
Více6 Objektově-orientovaný vývoj programového vybavení
6 Objektově-orientovaný vývoj programového vybavení 6.1 Co značí objektově-orientovaný - organizace SW jako kolekce diskrétních objektů, které zahrnují jak data tak chování objekt: OMG: Objekt je věc (thing).
Více