12513 pomoc Java,ASP.NET projekty na zaliczenie cwiczen

Witam, Jestem studentka informatyki z warszawy i potrzebuje pomocy w wykonaniu cwiczen znajdujacych sie ponizej, na zasadzie korepetycji. Cena do uzgodnienia. 1 Zadania 1.1 ZADANIE 1: Piaskownica JavaTM (ang. JavaTM sandbox) (26 luty/2 marca) 1.1.1 Cwiczenie 1 (1 pkt) Napisz aplet, który odczytuje i zapisuje zawartosc okreslonego pliku na dysku oraz wypisuje wszystkie własciwosci (ang. properties) JavaTM Runtime Environment. Spróbuj uruchomic ten aplet i wykorzystac jego funkcje. Dlaczego próba zakonczyła sie niepowodzeniem? Stwórz recznie lub przy pomocy narzedzia policytool plik polityki bezpieczenstwa pozwalajacy temu apletowi na wykorzystanie jego funkcjonalno´sci. 1.1.2 C´ wiczenie 2 (1 pkt) Napisz aplikacj˛e o funkcjonalno´sci identycznej z apletem z poprzedniego ´cwiczenia. Spróbuj uruchomi´c ja˛ z domys´lna˛ polityka˛ bezpieczen´stwa. Stwórz dwie polityki bezpieczen´stwa: • jedna˛ zabraniaja˛ca˛ tej konkretnej aplikacji doste˛pu do dysku, • druga˛ zabraniaja˛ca˛ wszystkim aplikacjom oprócz niej doste˛pu do włas´ciwos´ci JRE. 1.1.3 C´ wiczenie 3 (1 pkt) Zmodyfikuj aplikacj˛e z ´cwiczenia 1.1.2 tak, aby przy uruchamianiu sprawdzała przyznane jej uprawnienia i informowała u˙zytkownika w sytuacji, gdy które´s z uprawnie´n niezb˛ednych jej do działania nie zostało jej przyznane. (PODPOWIEDZ´ : moz˙na to zrobic´ na kilka róz˙nych sposobów) 1.1.4 C´ wiczenie 4 (1 pkt) Uruchom aplikacje˛ z c´wiczenia 1.1.3 korzytaja˛c z JavaTM Web Start tworza˛c w tym celu odpowiedni deskryptor JavaTM Network Launching Protocol. 1.1.5 Przydatne ´zródła informacji • Wykład z TBO • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] c 1.2 ZADANIE 2: JavaTM Authentication and Authorization Service(5 marca/9 marca) 4 1.2 ZADANIE 2: JavaTM Authentication and Authorization Service(5 marca/9 marca) 1.2.1 C´ wiczenie 1 (5 pkt) Uzupełnij aplikacje˛ z c´wiczenia 3 o naste˛puja˛ce elementy: • Moduł uwierzytelnienia uz˙ytkownika, pozwalaja˛cy ustalic´ jego toz˙samos´c´ na podstawie doste˛pnych informacji (np. zestawu login/hasło); • Odpowiednia˛ klase˛ implementuja˛ca˛ interfejs [login to view URL]; • Odpowiedni plik konfiguracyjny dla Security Managera, wskazuja˛cy na uwierzytelnienie przy pomocy opracowanego modułu jako obowia˛zkowa˛; • Klasy, definiuja˛ce działania, które powinny wymagac´ odpowiednich uprawnien´ (doste˛p do pliku itp.), implementuja˛ce interfejs [login to view URL]; • Deklaracje w pliku polityki bezpieczen´stwa, pozwalaja˛ce uz˙ytkownikowi na wykonanie okres´lonych akcji tylko po uwierzytelnieniu. Deklaracje powinny wskazywa´c u˙zytkownika uprawnionego do wykonywania danych operacji (ang. principal-based policy file statements); • Odpowiednie modyfikacje w samej aplikacji, wykorzystuja˛ce stworzone elementy. Wynikiem powinna byc´ aplikacja pozwalaja˛ca na wykonywanie wybranych czynnos´ci tylko pod kontrola˛ Security Managera poprawnie uwierzytelnionym u˙zytkownikom. 1.2.2 Przydatne ´zródła informacji • Do wykonania ´cwicze´n przydatna b˛edzie wiedza zawarta w rozdziałach Authentication i Authorization tutoriala znajduja˛cego sie˛ pod adresem: [login to view URL] UWAGA: tutorial zakłada u˙zycie systemu Kerberos do uwierzytelnienia u˙zytkownika. c 1.3 ZADANIE 3: Code-Access Security(12 marca/16 marca) 5 1.3 ZADANIE 3: Code-Access Security(12 marca/16 marca) 1.3.1 C´ wiczenie 1 (5 pkt) Stwórz projekt w .NET, składaja˛cy sie˛ z dwóch Assemblies: 1. Biblioteki, która udoste˛pnia naste˛puja˛ca˛ funkcjonalnos´c´: (a) zapis i odczyt zawarto´sci okre´slonego pliku z dysku; (b) zapis i odczyt pliku z Isolated Storage; (c) odczyt zawarto´sci jednego z kluczy rejestru systemowego, np. \\\\HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor \\0\\ProcessorNameString 2. Ka˙zda z metod powinna by´c zaimplementowana w dwóch wersjach: (a) okres´laja˛cej deklaratywnie (przy pomocy atrybutów) wymagane uprawnienia (b) okres´laja˛cej imperatywnie (przy pomocy metod) wymagane uprawnienia 3. Aplikacji, która wykorzystuje funkcjonalno´s´c biblioteki z punktu 1. Powinna umo˙zliwia´c wywołanie ka˙zdej z metod tej biblioteki, zarówno w wersji (1) imperatywnej, jak i (2) deklaratywnej Wywołanie powinno przebiegac´ wzdłuz˙ całego łan´cucha metod, które modyfikuja˛uprawnienia tak, aby pokazac´ naste˛puja˛ce przypadki: (a) jedna z metod w ła´ncuchu wywoła´n odbiera (DENY) konkretne uprawnienie; (b) jedna z metod odbiera uprawnienie, druga je bezwarunkowo przyznaje (ASSERT); (c) ˙zadna z metod nie zabrania wykonania konkretnej operacji; 4. Zweryfikuj działanie projektu 5. Przy pomocy narz˛edzia .NET Framework Configuration stwórz nowy zestaw uprawnie´n, który zabrania Twojej aplikacji wykonania okre´slonej operacji (wykonywanej przez bibliotek˛e z punktu 1). Operacja ta powinna nale˙ze´c do „niezabronionych” przez ła´ncuch wywoła´n w aplikacji z punktu 3. 1.3.2 Przydatne ´zródła informacji Do wykonania ´cwicze´n przydatna b˛edzie wiedza zawarta w artykułach: • http://www.codeproject.c om/dotnet/UB_CAS_NET.asp. 1.4 ZADANIE 4: AppDomain (19 marca/23 marca) 6 1.4 ZADANIE 4: AppDomain (19 marca/23 marca) 1.4.1 C´ wiczenie 1 (5 pkt) Rozszerz biblioteke˛ z zadania c´wiczenia 5 dodaja˛c do niej kontrolke˛ — w zupełnos´ci wystarczy prosta etykieta (ang. label). Biblioteka powinna z˙a˛dac´ naste˛puja˛cych uprawnien´: • RequestMinimum do zapisu i odczytu plików na dysku; • RequestMinimum do odczytu danych z rejestru; • RequestMinimum do zapisu i odczytu danych z Isolated Storage; • RequestOptional do UIPermission. Naste˛pnie zmodyfikuj swoja˛ aplikacje˛ z c´wiczenia 1.3 tak, aby po kaz˙dym wcis´nie˛ciu przycisku wywołuja ˛cego która˛kolwiek akcje˛ wykonywane były naste˛puja˛ce czynnos´ci: • biblioteka jest ładowana do osobnego AppDomain; • zestaw odpowiednich uprawnie´n zostaje przypisany do AppDomain biblioteki; • odpowiednia operacja jest wywoływana; • biblioteka zostaje usuni˛eta z pami˛eci przez usuni˛ecie AppDomain. Co si˛e stanie, gdy bibliotece zostanie odebrane uprawnienie UIPermission? 1.4.2 Przydatne ´zródła informacji Do wykonania ´cwicze´n przydatna b˛edzie wiedza zawarta w artykułach: • [login to view URL] • [login to view URL] 1.5 ZADANIE 5: Isolated Storage (26 marca/30 marca) 7 1.5 ZADANIE 5: Isolated Storage (26 marca/30 marca) 1.5.1 C´ wiczenie 1 (5 pkt) Zbuduj dwie prostych aplikacjiWindows Forms współdziela˛ce jeden katalog w izolowanym magazynie danych (ang. isolated storage). Aby tego dokona´c musisz stworzy´c dwie aplikacje oraz bibliotek˛e, która b˛edzie udost˛epnia´c odpowiedni zestaw operacji na na zasobach Isolated Storage. Pierwsza aplikacja (edytor) powinna: • umo˙zliwia´c stworzenie folderu o podanej nazwie we wskazanym przez u˙zytkownika miejscu Isolated Storage (uz˙ytkownik powinien podawac´ s´ciez˙ke˛ relatywna˛do udoste˛pnionego folderu izolowanego magazynu); • umo˙zliwia´c stworzenie pliku o podanej nazwie i zawarto´sci we wskazanym przez u˙zytkownika miejscu Isolated Storage (uz˙ytkownik powinien podawac´ s´ciez˙ke˛ relatywna˛ do udoste˛pnionego folderu izolowanego magazynu). Z kolegi druga aplikacja (przegla˛darka) powinna odpowiednio: • wy´swietla´c zawarto´s´c IsolatedStorage lub wybranego folderu w Isolated Storage; • wy´swietla´c zawarto´s´c wybranego pliku z Isolated Storage; • wy´swietla´c ilo´s´c miejsca pozostałego w Isolated Storage. Biblioteka współdzielona przez obydwie wymienione aplikacje powinna: • udoste˛pniac´ odpowiedni zestaw metod wywoływanych przez edytor lub/i przegla˛darke˛ — obywdwie aplikacje powinny wykorzystywa´c bibliotek˛e w celu uzyskania dost˛epu do „wspólnego” izolowanego magazynu. W celu uzyskania kompletu punktów nale˙zy: • dostarczyc´ obydwie aplikacje: (1) edytor i (2) przegla˛darke˛, oraz współdzielona˛ biblioteke˛ • ustalic´, jakie ustawienia uprawnien´ do izolowanego magazynu: (1) umoz˙liwiaja˛ aplikacjom współdzielenie danych, oraz z drugiej strony (2) uniemoz˙liwiaja˛ tego rodzaju współdziałanie. 1.6 ZADANIE 6: Wsparcie Role-Based Security w ASP.NET 2.0 (2 kwietnia/13 kwietnia) 8 1.6 ZADANIE 6: Wsparcie Role-Based Security w ASP.NET 2.0 (2 kwietnia/13 kwietnia) 1.6.1 C´ wiczenie 1 (7 pkt) Stwórz aplikacje˛ ASP.NET 2.0 wykorzystuja˛ca˛wbudowane mechanizmy uwierzytelnienia i autoryzacji u˙zytkownika. Projekt powinien: 1. Wykorzystywa´c tryb uwierzytelnienia Forms (nie Windows)—domy´slny tryb uwierzytelnienia mo˙zna zmieni´c: • za pomoca˛ narze˛dzia ASP.NET Configuration stanowia˛cego cze˛s´c´ Visual Studio .NET, lub • odpowiednio modyfikuja˛c zapisy w pliku [login to view URL] w głównym folderze projektu. W opisany sposób mo˙zna równie˙z okre´sli´c role u˙zytkowników aplikacji. 2. Przechowywa´c katalog u˙zytkowników aplikacji w bazie danych Microsoft SQL Server 2000. Wspomniany katalog powinien zawiera´c kilku zdefiniowanych u˙zytkowników wraz z przydzielonymi im rolami; 3. Zawierac´ podkatalog ze strona˛ wys´wietlaja˛ca˛ nazwe˛ zalogowanego uz˙ytkownika (odczytana˛ programowo). Dost˛ep do tego podkatalogu powinien by´c ograniczony: • jedna z ról wyste˛puja˛cych w aplikacji powinna miec´ zabroniony doste˛p do jego zawartos´ci; • podobnie jeden z uz˙ytkowników, któremu przypisano role pozwalaja˛cymi na doste˛p do tego podkatalogu powinien mie´c odebrane do niego uprawnienia. • uz˙ytkownicy, którzy nie przeszli pomys´lnie procedury uwierzytelnienia równiez˙ nie moga˛ mie´c dost˛epu do zawarto´sci wspomnianego podkatalogu. U˙zytkownik pozbawiony praw dost˛epu powinien by´c przekierowany do strony logowania. Strona powinna te˙z sprawdza´c rol˛e u˙zytkownika (przy pomocy [login to view URL]) — u˙zytkownik wyste ˛puja˛cy w okres´lonej roli powinien dostac´ dodatkowa˛ informacje˛ tekstowa˛. 4. Zawierac´ strone˛ startowa˛ —- powinna ona umoz˙liwiac´ zalogowanie sie˛ oraz stworzenie nowego uz˙ytkownika przy pomocy wbudowanych kontrolek. Dostarczone rozwia˛zanie powinno zawierac´ zarówno kod ´zródłowy projektu wraz z wszystkimi niezb˛ednymi plikami, jak i plik bazy danych zawieraja˛cy informacje niezbe˛dne do uwierzytelnienia i autoryzacji. 1.6.2 Przydatne ´zródła informacji • Beginning ASP.NET 2.0 in C# From Novice to Professional , Apress (rozdziały 18 oraz 19) • [login to view URL] 1.7 ZADANIE 7: Bardziej zaawansowane wykorzystanie Role-Based Security (16 kwietnia/20 kwietnia) 9 1.7 ZADANIE 7: Bardziej zaawansowane wykorzystanie Role-Based Security (16 kwietnia/ 20 kwietnia) 1.7.1 C´ wiczenie 1 (7 pkt) Stwórz własne rozwia˛zanie ograniczaja˛ce doste˛p uz˙ytkownika do funkcjonalnos´ci aplikacji na podstawie jego uprawnien´. Rozwia˛zanie powinno wykorzystywac´ mechanizm Role-Based Security doste˛pny w .NET Framework. 1. Stwórz własny katalog uz˙ytkowników (w postaci pliku XML, ba˛dz´ bazy danych zarza˛dzanej przez Microsoft Access albo Microsoft SQL Server) przechowuja˛cy informacje˛ nt. uz˙ytkownikowników oraz ich przynale˙zno´sci do grup. Minimalny zestaw przechowywanych informacji widoczny jest na (rys. 1). Baza danych u˙zytkowników powinna zawiera´c dwie grupy: (1) users—zwykli u˙zytkownicy, oraz (2) admins — administratorzy. W bazie powinno znale´z´c si˛e 4 u˙zytkowników: (a) User1 — członek grupy users; (b) Admin1 — członek grupy admins; (c) Superadmin — członek obu grup; (d) Nogroup — nie powinien nale˙ze´c do ˙zadnej z grup users PK user_login user_password groups PK group_id group_name group_description groups_users PK,FK1 user_login PK,FK2 group_id Figure 1: Przykładowy schemat bazy danych przechowuja˛cej informacje˛ o uz˙ytkownikach aplikacji 2. Stwórz formularz Windows Forms, który posłu˙zy do uwierzytelnienia u˙zytkownika — dostarczone przez uz˙ytkownika dane uwierzytelniaja˛c (ang. credentials) powinny byc´ zweryfikowane i na ich podstawie powinien zostac´ stworzony obiekt GenericPrincipal reprezentua˛cy uz˙ytkownika w ramach ´srodowiska. Po weryfikacji to˙zsamo´sci oczom u˙zytkownika powinien ukaza´c si˛e interfejs graficzny opisany poni˙zej. 3. Zmodyfikuj biblioteke˛ rozwijana˛ w ramach poprzednich zadan´ (patrz. 1.3) tak, aby ograniczała ona dost˛ep do funkcjonalno´sci na podstawie informacji zawartej w obiektu Principal. Biblioteka powinna uz˙ywac´ naste˛puja˛ch regul doste˛pu: (a) Ka˙zdy zalogowany u˙zytkownik mo˙ze korzysta´c z Isolated Storage; (b) Członkowie grupy users moga˛ zapisywac´ i odczytywac´ pliki z dysku; (c) Członkowie grupy admins moga˛ odczytywac´ wartos´c´ z rejestru; Weryfikacja uprawnie´n powinna odbywa´c si˛e na podstawie klasy PrincipalPermission, która˛moz˙na uz˙ywac´ zarówno w sposó imperatywny, jak i deklaratywny. 4. Stwórz aplikacje˛ korzystaja˛ca˛ z biblioteki opisanej powyz˙ej. Formularz uwierzytelniaja˛cy, biblioteka i aplikacja powinny znajdowa´c si˛e w osobnych komponentach wdro˙zeniowych (ang. assemblies). 1.7 ZADANIE 7: Bardziej zaawansowane wykorzystanie Role-Based Security (16 kwietnia/20 kwietnia) 10 1.7.2 Przydatne ´zródła informacji • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] • [login to view URL] 1.8 ZADANIE 8: Authorization Manager (21 maja/25 maja) 11 1.8 ZADANIE 8: Authorization Manager (21 maja/25 maja) 1.8.1 C´ wiczenie 1 (12 pkt) Stwórz aplikacj˛e Windows Forms, która posłu˙zy jako przykład wykorzystania mechanizmów Authorization Manager. Aplikacja powinna udost˛epnia´c interfejs dla dwóch rodzajów u˙zytkowników — zwykłego u˙zytkownika i kierownika. Funkcjonalno´s´c udost˛epniona zwykłemu u˙zytkownikowi to zgłaszanie zapotrzebowania na zakup sprz˛etu. U˙zytkownik wprowadza nazw˛e sprz˛etu oraz jego cen˛e. Zakup warto´sci do 500 EUR jest automatycznie zatwierdzany, powy˙zej tej kwoty wymagana jest autoryzacja przez przełoz˙onego reprezentowanego w systemie przez role˛ kierownika. Poza autoryzacja˛ zapotrzebowania zgłoszonego przez swoich podwładnych, kierownik równie˙z mo˙ze zgłasza´c zapotrzebowanie na zakup (zatwierdzane automatycznie, niezale˙znie od kwoty). Aplikacja powinna: • Udoste˛pniac´ odpowiedni interfejs uz˙ytkownika w zalez˙nos´ci od uprawnien´, jakie przypisane sa˛ danemu u˙zytkownikowi (warto wykorzysta´c tu mo˙zliwo´s´c sprawdzenia uprawnie´n do wykonania danej operacji); • Przechowywa´c dane o zale˙zno´sciach słu˙zbowych i zapotrzebowaniu na sprz˛et w bazie o schemacie przedstawionym na (rys. 2). Dla ułatwienia zakładamy płaska˛hierarchie˛ słuz˙bowa˛(tylko pracownicy i managerowie, emp_manager u kierownika ma warto´s´c null). approver_id w niezatwierdzonym zamówieniu powinien mie´c warto´s´c null, zamówienia zgłoszone przez managerów powinny miec´ ta˛ sama˛wartos´c´ w polach emp_id i approver_id (identyfikator kierownika); • Decyzje zwia˛zane z udzielaniem (lub nie) zezwolenia na poszczególne działania powinny byc´ zaimplementowane przy pomocy mechanizmów Authorization Managera, aplikacja powinna wywoływac ´ odpowiednie metody AzMan.a . z˙adne decyzje dotycza˛ce uprawnien´ (w tym weryfikacja wysoko´sci zamówienia) nie powinny by´c podejmowane przez aplikacj˛e. Optymalna kolejno´s´c działa´n: 1. Stworzenie aplikacji udoste˛pniaja˛cej zadana˛funkcjonalnos´c´, nie weryfikuja˛cej z˙adnych uprawnien´ (tzn. aplikacja powinna umo˙zliwia´c zapis i odczyt danych do/z bazy danych). Na tym etapie warto na formularzu pracownika umies´cic´ jakis´ element pozwalaja˛cy zdecydowac´, czy zapotrzebowanie ma by´c autoryzowane automatycznie, czy pozostawione do decyzji kierownika. 2. Przetestowanie działania zbudowanego rozwia˛zania. 3. Włas´ciwe skonfigurowanie AzMan i uzupełnienie aplikacji o kod wykorzystuja˛cy AzMan. Miejsca wymagaja˛ce autoryzacji przez Authorization Manager: 1. Decyzja o automatycznej autoryzacji (lub jej braku) zlecenia zło˙zonego przez pracownika zrealizowana w oparciu o regułe˛ biznesowa˛. 2. Decyzja o automatycznej autoryzacji zlecenia złoz˙onego przez kierownika. Moz˙liwe rozwia˛zania: (1) stworzenie reguły statycznej reguły lub (2) rozszerzenie BizRule opisanej powy˙zej. 3. Zezwolenie na wykonanie operacji autoryzacji zakupu przez kierownika: (1) reguła statyczna lub (2) osobna reguła biznesowa. 1.8 ZADANIE 8: Authorization Manager (21 maja/25 maja) 12 Wa˙zne: Wzadaniu mo˙zna wykorzysta´c mechanizmy autoryzacyjne MicrosoftWindows (9x/Me/NT/2000/XP/2003 Server), lub te˙z własne (np. stworzone w poprzednim zadaniu). W wypadku wykorzystania mechanizmów wbudowanych w system operacyjny konieczne b˛edzie zało˙zenie przynajmniej 2 kont u˙zytkowników (1 dla pracownika, 1 dla kierownika). Nalez˙y pamie˛tac´ o powia˛zaniu nazwy uz˙ytkownika z baza˛ uz˙ywana˛w zadaniu (pole emp_name). employees PK emp_id emp_name FK1 emp_manager purchase_reqs PK preq_id preq_name preq_amount FK1 approver_id FK2 emp_id Figure 2: Schemat bazy danych rejestruja˛cej informacje˛ o złoz˙onych zamówieniach z uwzgle˛dnieniem danych osoby: (1) składaja˛cej, oraz (2) zatwierdzaja˛cej zapotrzebowanie 1.8.2 Przydatne ´zródła informacji • [login to view URL];#8226; [login to view URL] • [login to view URL] • [login to view URL];en-us;324470 • [login to view URL] 1.9 ZADANIE 9: Kryptografia w JavaTM (4 czerwca/8 czerwca) 13 1.9 ZADANIE 9: Kryptografia w JavaTM (4 czerwca/8 czerwca) 1.9.1 C´ wiczenie 1 (10 pkt) Stwórz aplikacj˛e JavaTM, która b˛edzie dostarcza´c funkcjonalno´s´c narz˛edzia keytool dostarczanego w ramach JavaTM Runtime Environment rozszerzona˛ o moz˙liwos´ci: (1) generowania skrótów wiadomo ´sci, (2) generowania kodu uwierzytelnienia wiadomo´sci, oraz (3) podpisywania danych zapisanych w pliku. Twoja aplikacja powinna pozwala´c na: 1. Stworzenie nowego klucza i doła˛czenie go do magazynu kluczy (ang. keystore). Aplikacja powinna wspiera´c generowanie zarówno kluczy (1) symetrycznych, jak i (2) asymetryczne, a tak˙ze ochron˛e kluczy prywatnych i tajnych za pomoca˛ hasła; 2. Generowanie wniosków o podpisanie certyfikatu (ang. certification signing requests) w formacie zgodnym ze standardem PKCS#10 na podstawie kluczy prywatnych przechowywanych w magazynie kluczy; 3. Import podpisanych certyfikatów lub ła´ncuchów certyfikatów; 4. Generowanie (1) skrótu wiadomo´sci, (2) kodu uwierzytelnienia wiadomo´sci, oraz (3) podpisu danych przechowywanych w plikach. Osoby bardziej ambitne moga˛ pokusic´ sie˛ o zapis np. danych podpisanych w formatach przeno´snych jak np. Cryptographic Message Syntax opisanym w standardzie PKCS#7. UWAGA: Intefejs programistyczny Java 2 Platform, Standard Edition nie daje mo˙zliwo´s´ci podpisywania wniosków certyfikacji X.509, konieczne mo˙ze by´c zatem (1) wykorzystanie zewn˛etrznego narz˛edzia, np. OpenSSL, bad´z (2) skorzystanie z funkcjonalno´sci innych dostawców bezpiecze´nstwa, np. Bouncy Castle ([login to view URL]). 1.9.2 Przydatne ´zródła informacji • [login to view URL] • [login to view URL] • [login to view URL];rl=1 • [login to view URL] • [login to view URL] • [login to view URL] • Przykłady wykorzystania dostawcy Bouncy Castle zamieszczone w ksia˛z˙ce Beginning Cryptography with JavaTM dost˛epne pod adresem: [login to view URL] 0764596330,[login to view URL] 1.10 ZADANIE 10: Kryptografia w Microsoft .NET (11 czerwca/15 czerwca) 14 1.10 ZADANIE 10: Kryptografia w Microsoft .NET (11 czerwca/15 czerwca) 1.10.1 C´ wiczenie 1 (7 pkt) Wykorzystaj wspracie dla kryptografii w interfejsie programistycznym udost˛epnianym przez Microsoft .NET do zbudowania aplikacji o funkcjonalno´sci zbli˙zonej tej opisanej w tre´sci zadania 1.9. Zasadnicze róz˙nice w porównaniu z rozwia˛zaniem stworzonego w ramach zadania 1.9 be˛da˛ naste˛puja˛ce: 1. do przechowywania par składaja˛cych sie˛: (1) z klucza prywatny, oraz (2) certyfikatu X.509 aplikacja b˛edzie wykorzystywała systemowy magazyn kluczy Microsoft Windows reprezentowany przez klas˛e [login to view URL]; 2. systemowy magazyn kluczy jest przeznaczony wyła˛cznie do przechowywania certyfikatów X.509, którym opcjonalnie moga˛ towarzyszyc´ odpowiadaja˛ce im klucze prywatne. Wmiejsce funkcjonalnos ´ci umoz˙liwiaja˛cej zapis w magazynie klucza tajnego, aplikacja powinna dawac´ uz˙ytkownikowi mo˙zliwo´s´c: (a) podpisywania oraz tworzenia kopert cyfrowych na podstawie zawarto´sci plików, oraz (b) utrwalania tak zabezpieczonej tre´sci w postaci (1) dokumentów XML zgodnie ze standardami XML Signature, oraz XML Encryption, a tak˙ze w formacie (2) tzw. danych podpisanych (ang. signed data), oraz kopert (ang. enveloped data) opisanych w standardzie PKCS#7. 3. aplikacja b˛edzie pozbawiona mo˙zliwo´sci tworzenia wniosków certyfikacji PKCS#10 oraz ich podpisywania ze wzgl˛edu na brak bezpo´sredniego wsparcia tej funkcjonalno´sci w interfejsie programistycznym Microsoft .NET Framework. (PODPOWIEDZ´ : Prosze˛ zwrócic´ uwage˛ na „nieintuicyjna˛” nazwe˛ klasy X509Certificate2 reprezentuja ˛cej faktycznie pozycje˛ systemowego magazynu kluczy a nie tylko sam certyfikat X.509 — instancja klasy X509Certificate2 mo˙ze zawiera´c równie˙z klucz prywatny.) (PODPOWIEDZ´ : Ze wzgle˛du na brak moz˙liwos´ci tworzenia wniosków certyfikacji oraz ich podpisywania korzystne moz˙e okazac´ sie˛ rozszerzenie rozwia˛zania zadania 1.9 o moz˙liwos´c´ eksportu pozycji klucza do pliku wymiany danych o podmiocie zgodnego z formatem PKCS#12. Zawarto´s´c pliku wymiany (lub inaczej magazyn) PKCS#12 mo˙ze by´c nast˛epnie zaimportowana do systemowego magazynu kluczy m.in. za pomoca˛ Microsoft Internet Explorer. Rozszerzenie dotychczasowej funkcjonalnos´ci aplikacji stworzonej w ramach zadania 1.9 be˛dzie wia˛zało sie˛ ze podniesieniem oceny za to zadanie o kolejne 2 pkt.) 1.10.2 Przydatne ´zródła informacji • [login to view URL] • [login to view URL] • [login to view URL]