Interoperacyjność?

Ciekawe który z nich jest większym zagrożeniem dla MS – IBM czy Oracle? Na konferencji Java One wystąpił zespół MS – mówi się o projekcie Apache Stonehenge (SOA) i referencyjnym rozwiązaniu StockTrade 2.0 – współpracy między serwisami WS w oparciu o wszystkie standardy WS* Security -

Companies change (maybe). In the last five years, Sun and Microsoft 
have made progress. Three years ago, representatives of both companies 
took the stage at JavaOne to discuss interoperability and early 
efforts in the Apache Stonehenge project (http://tinyurl.com/r5bq52) 
for SOA. Microsoft's StockTrader 2.0 code -- a head-to-toe .NET rewrite 
of an IBM-based Java app -- was contributed as a reference app to 
"Stonehenge" last November. It shows developers how they can interop 
with Web services by connecting an ASP.NET Web front end to business 
services and order processing services running in .NET, or the Metro 
Web Service (Java) stack on the Sun GlassFish Enterprise App Server. 
The interoperability is enabled through WS* Security and other Web 
Service standards. Developers basically use a different URI to point to 
the services and configure the security. On the back end, StockTrader 
2.0 supports SQL Server (demonstrated today) or Oracle 11g. Support for 
MySQL is on the way, according to Microsoft. During the keynote, Sun 
announced that it's contributing its Metro-based StockTrader code to 
the Apache Stongehenge project today. 

SUN
Technologie użyte w rozwiązaniu WebSigner Applet - http://rcardon.free.fr/websign/wakka.php?wiki=MainPage:

1. http://www.keyon.ch/en/Produkte/JavaJCE/JACAPI/index.htm - płatne (kontakt)
   
2. http://pheox.com/products/jcapi/ - płatne (1700 Eu)
3. Dokumentacja do implementacji podpisu przez SUN - http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#SSLTLS

Pobieranie stron HTTP:

1. http://hc.apache.org/httpclient-3.x/tutorial.html
2. http://www.innovation.ch/java/HTTPClient/getting_started.html
3. http://java.sun.com/developer/onlineTraining/
4. http://rcardon.free.fr/
   

Szkolenia inne:

1. http://java.sun.com/developer/onlineTraining/tools/ - UML
2. Bezpieczeństwo - http://java.sun.com/developer/onlineTraining/Security/
3. Rozbiegówka - http://java.sun.com/docs/books/tutorial/security/TOC.html
4. http://java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html#secSignIE
5. Nowa wersja - http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#SSLTLS
6. http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
7. http://java.sun.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider - dostęp do CAPI
8. Architektura dostawcy - http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html#ProviderArch
9. Forum msdn - http://forums.microsoft.com/msdn/default.aspx?siteid=1
10. Ciekawy post - http://www.javaworld.com/javaforums/showflat.php?Cat=2&Number=39181&an=0&page=3
11. Hi everyone:
    Im using the SunPKCS11 in my Applet application in order to interact with smart card to sign data
    The SunPKCS11 needs as parameter in its constructor a library (".dll in case of windows" or ".so in case of linux"). That´s ok and it´s working fine!
    Im using the dll from the vendor of the smart-card (aetpkss1.dll)
    
    1- First question: For each kind of reader / smart-card, do i need to specify a diferent library (.dll / .so) ? Is there a generic dll ? How do i know the name of dll installed at the user´s machine ?
    
    I have been testing CAPICOM too. Everybody knows CAPICOM (Written in VB) interacts with the Windows CryptoAPI (Written in C).
    I have an application working with CAPICOM (at Internet Explorer) to sign data. The application can sign using certificates stored at Smart-Card. However CAPICOM never asked me for a dll or something like that, why ?
    
    2 - Second question: Does CAPICOM or CryptoAPI knows where is the location of the dll and do it automatically ? or the CAPICOM / CryptoAPI can interact with the smart-card directly ?
12. Inny - I'm trying to execute a Post request using HTTPS. To achieve that I'm using commons-httpclient v.3.0rc1 and a custom SSLSocketProtocolSocketFactory that can work with untrusted self-signed certificates.
13. Podpis wykorzystujący CAPI i C++: http://www.codeproject.com/KB/asp/adrian_bacaianu.aspx
    

Ciekawe linki:

1. IE7Pro ma debugger FireBug w wersji Lite
2. Refleksja w Javie czasmi może być pomocna - http://www.onjava.com/pub/a/onjava/2007/03/15/reflections-on-java-reflection.html?page=1
3. Tworzenie okien modalnych będących jedynie warstwą na stronie - http://jquery.com/demo/thickbox/
4. Inna wersja - http://livepipe.net/projects/control_modal/
   
5. Przykład wykorzystania j. dynamicznych - http://www.javabeat.net/javabeat/java6/articles/2007/06/java-6-0-new-features-part-1/2
6. Portal Java EE - http://java.sun.com/javaee/community/blogs/?feed=JSC
7. Tutorial o oknach - http://www.webreference.com/js/tutorial1/final.html
8. http://p0t.jp/pprompt/
9. http://openjsan.org/doc/k/ko/komagata/Widget/Dialog/0.01/index.html
10. http://www.webreference.com/js/column90/
11. http://www.dhtmlgoodies.com/index.html?whichScript=modal-message
12. http://www.dynamicdrive.com/dynamicindex8/dhtmlwindow/dhtmlmodal.htm
    
13. Wstrzyknięcie dynamiczne javascript-u i css-ów - http://www.javascriptkit.com/javatutors/loadjavascriptcss.shtml
14. Przykłady EXT JS - http://extjs.com/deploy/dev/examples/
15. marekcoig/t - https://inventory.sun.com/RegistrationWeb/nbgf/thankyou.jsp
16. http://developers.sun.com/downloads/ - dostęp po zarejestrowaniu wcześniej
17. Java SE security - http://java.sun.com/javase/technologies/security/
18. Tutoriale - http://java.sun.com/developer/onlineTraining/
19. Klasyczne :
1. dzone
2. http://dean.edwards.name/my/
3. http://code.google.com/
   

Rozwiązanie podpisu cyfrowego w COIG


Wstęp

Analiza SWAT

Generalnie mamy do czynienia z takimi "show stopperami":

1. Wymagania prawne odnośnie podpisu i wymaganej od aplikacji deklaracji zgodności - nie do końca je znamy, są one dostępne na stronach Sigillum i SputnikSoftware, ale nie wiemy co tak naprawdę jest ważne.
2. Problem uzyskania zgodności z ustawą...
3. Proces instalowania podpisu cyfrowego u klienta jest pracochłonny i wymaga zainstalowanie oprogramowania dodatkowego oraz poprawnego skonfigurowania w systemie. Być może nawet pomocy technicznej np. coś w rodzaju naszego "maximo"
4. Stosowanie klienta Cisco VPN skutecznie wyklucza sprawdzenie ważności certyfikaty z listą CRL (VPN wyłącza dostęp do witryny świadczącej usługi sprawdzenia CRL)
5. Przeglądarki internetowe nie potrafią w prosty sposób (na poziome zwykłego użytkownika) dostać się do zasobów lokalnych komputera klienckiego
6. Poza platformą MS Windows brak powszechnego wsparcia implementacji procedur kryptograficznych w postaci zintegrowanych, gotowych do wykorzystania z poziomu systemu operacyjnego a nie wywołań funkcji bibliotecznych komponentów, które uzyskały aprobatę w oczach ustawodawców (mających certyfikaty). Dlatego OpenSSL mimo, że jest wspaniałą biblioteką nie jest gotowa do obsługi.
7. Brak dostępu do sterowników obsługujących czytniki smart card na naszym rynku w środowisku Unix/Linux (producenci tychże czytników dostarczają sterowników wyłącznie pod Windows)
8. Brak certyfikatu do podpisywania kodu własnego oprogramowania udostępnianego publicznie klientom (musimy zakupić taki certyfikat aby zwiększyć wiarygodność)
9. Jak i co podpisywać cały dokument czy jego fragment i jakiego formatu użyć (formaty wykorzystujące XML pozwalają podpisywać fragmenty dokumentów)
10. Czy używać znakowania czasem, jeżeli tak to jakie rozwiązanie wybrać (opłata czy własny serwer czasu), stowarzyszenie PEMI wyraża chęć pomocy (oni przez pewien czas utrzymywali taki serwer ale nie było zainteresowania)
11. Wybór systemu operacyjnego użytkownika oraz określenie przeglądarki internetowej
12. Wybór dostawcy certyfikatu (tzw. urząd certyfikacyjny) w pewnym sensie determinuje sposób obsługi certyfikatu u klienta. Są dwa: Sigillum i Certum
13. Wybór urządzenia smart cart i karty inteligentnej jeszcze bardziej zawęża wybór rozwiązania tej obsługi. Są dwa rozwiązania. Jedno bazuje na sterownikach PC-SC (dll) drugia na JavaCard (ale mało popularne)
14. Co wybierze nasz klient, pod tym kątem musimy przygotować oprogramowanie
15. Wybóry powyższe determinują rozwiązanie obsługi ceryfikatów i podpisu w naszych aplikacjach
16. Coś za coś - wybrawszy dostawcę możemy liczyć na jego wsparcie i dostajemy dużo narzędzi do instalacji, konfiguracjie, testowania certyfikatów a także aplikacje wspomagające np. CryptoCard Monitor, ale kosztem bardziej skomplikowanej procedury instalacyjnej i konfiguracyjnej
17. Wsparcie (Sigillum i Certum) polega na dostarczeniu bezpłatnej aplikacji w grubym kliencie do podpisu i weryfikacji dokumentów lokalnych. To niewybrednym klientom wystarcza, resztę załatwiają przy pomocy poczty elektronicznej.
18. Na szczęście każdy dostawca dostarcza własne biblioteki obsługi oraz sterowniki (czasami odpłatnie) wraz z homologacją
19. Na nieszczęście każde rozwiązanie jest inne, brak uniwersalnego rozwiązania (czasami zdarzają sie biblioteki uniwersalne - patrz Sigillum)
20. W MS Windows jest wbudowana obsługa podpisu i certyfikatów poprzez odpowiednio zdefiniowane warstwy
    
21. Należy unikać "szarlatańskich" rozwiązań z Internetu, które działają w pewnych tylko przypadkach, choć istnieje pewne prawdopodobieństwo, że przy odrobinie wysiłku można je przystosować i rozwinąć dla własnych potrzeb. Sprawdziłem - prosto jedynie można podpisać gdy certyfikat nie jest na karcie a jedynie w repozytorium Windows
22. Prawdziwe i pełne oprogramowanie podpisu nie może sie obejść bez głębokiego wniknięcia w programowanie (szczególnie jeżeli chodzi o przygotowanie komponentów) na poziomie Java lub .NET. Dlatego konieczne są szkolenia
23. Rozwiązania z internetu (każde inne):
    
    1. http://www.nakov.com/documents-signing/demo/SmartCardSignerApplet-demo.html
    2. http://www.developer.com/java/web/article.php/3298051
    3. http://www.developer.com/security/article.php/11580_3587361_1
    4. http://rcardon.free.fr/
    5. http://www.podpiselektroniczny.pl
    6. http://www.trustedwebservices.org/content/view/48
       

Można udostępnić całościowe ale hermetyczne rozwiązanie albo wiele różnych wihajstrów do wykorzystania. Oba te rozwiązania są pożyteczne.


Część kliencka podpisu

Do podpisywania (i tylko do tego bo można jeszcze szyfrować) służy bezpieczne urządzanie tj. zestaw: system operacyjny, czytnik smart card/karta inteligentna oraz aplikacja. Miejsce podpisywania - wyłącznie u klienta. Konieczna jest wizualizacja dokumentu przed podpisem. Wszystkie inne funkcje związane z podpisem mogą być realizowane w innym miejscu np. na serwerze. Problem podpisu możemy rozwiązać na dwa sposoby.

1. Podejście brutalne - wykorzystanie istniejących w systemie Windows uniwersalnych komponentów do obsługi całego (kompletnego) procesu składania i sprawdzania podpisu. Komponenty te można zabudować we własnych aplikacjach. Te komponenty to:
   1. Wbudowany w MS Windows moduł CAPI oraz interface do niego CAPICOM (czyli udostępnienie interfejsu Crypto API poprzez architekturę COM) który zapewnia wszystkie podstawowe funkcje związane z podpisem i sprawdzaniem dokumentu oraz obsługą repozytorium certyfikatów. Dokładnie mówiąć CAPICOM pozwala na "przeźroczystą" obsługę konkretnych urządzeń kryptograficznych dostępnych przez CSP. Jest to dla środowiska MS Windows Client jedyny wbudowany komponent do obsługi podpisu cyfrowego. Dla środowiska Linux / Unix nie ma takiego komponentu, jedynie aplikacje w Javie coś takiego mają. Należy pamiętać, że Microsoft ogłosił plany stopniowego wygaszania wsparcie dla CAPICOM począwszy od systemów operacyjnych po Viscie (ale CAPICOM w Viście jest wspierany, a to dlatego, że całkiem po prostu nie ma jeszcze pełnego wsparcia dla obsługi certyfikatów kwalifikowanych tj. mających zabezpieczone przed pobraniem klucze prywatne - tego jeszcze na platformie .NET nawet w nowej wersji 3.5 nie ma! Sam sprawdziłem, mówi się, że trzeba poczekać na SP1 do Visty. W Viscie jest nowy moduł, zgodny z CAPICOM i nosi nazwę CNG (Cryptography API: Next Generation) - wykorzystuje on nowsze, certyfikowane przez National Security Agency (NSA) algorytmy, jest bezpieczniejszy i szybszy (dzięki wykorzystanie tzw. Elliptic Curve Cryptography). Ale jest jeszcze niedopracowany (czekamy na SP1). Dlatego jedyne na obecną chwilę rozwiązanie w środowisku .NET poza CAPICOM to skorzystanie z dostępnych bibliotek firm dostarczających certyfikaty np. biblioteki Sigillum. Możliwości CAPICOM:
      1. Dostęp do:
         1. Certyfikatu oraz ścieżki certyfikacyjnej
         2. Danych o podpisującym
         3. Danych o wystawcy
         4. Danych o datach ważności informacji
         5. Klucza publicznego
      2. Realizacja podpisu pod dokumentem:
         1. Wbudowanego (tzw. attached, powstaje nowy, znacznie większy o ok. 3 razy dokument, który jest samowystarczalny tj. niesie informację o dokumencie podstawowym, się może być sprawdzony na nienaruszalność danych i zawiera informacje kto, kiedy podpisał
         2. Pomocniczy (tzw. detached, znacznie mniejszy ok. 20-30 KB, do weryfikacji potrzebny jest dokument podstawowy)
      3. Weryfikacji dokumentu - sprawdzenia czy dokument uległ zmianie.
      4. Kopertowanie (envelope) - dodatkowa funkcja szyfrowania danych kluczem publicznym odbiorcy, wtedy tylko odbiorca może dokument odczytać
      5. Brak bardziej zaawansowanych funkcji: znacznika czasu i sprawdzenia (online poprzez OCSP lub pobranej periodycznie listy CRL) czy certyfikat nie został odwołany
   2. Biblioteki zewnętrzne (przykład - zakupiona przez ZA biblioteka Sigillum), realizuje ona wszystko to co ma CAPICOM i ma mnóstwo rozszerzeń m.in. znakowanie czasem, walidacja ważności certyfikatu online (poprzez OCSP), wsparcie certyfikatów innych wystawców, podpis wielokrotny. Zaletą tej biblioteki jest oparcie jej o nowy standard bezpieczeństwa wykorzystujący platformę .NET, będącej podstawą kolejnych edycji MS Windows. Nie rozpoznałem możliwości biblioteki drugiego dostawcy certyfikatów Certum z uwagi na utrudniony dostęp do informacji (znam jedynie cenę biblioteki ok. 7 tyś. zł. W czasie rozmów z przedstawicielami Certum w Katowicach przedstawiono nam warunki dostępu - podpisanie umowy partnerskiej.
2. Podejście ambitne - stworzenie własnej, uniwersalnej biblioteki co wiąże się z dużymi nakładami. Biblioteka może być rozwijana na platformie MS (wykorzystywać trzeba będzie już chyba nie CAPICOM ale .NET) lub Java na platformie Linux/Unix. W tym ostatnim przypadku brakuje natywnych sterowników do czytników smart card obecnie na rynku no i brak naszego doświadczenia. Probowałem się skontaktować z przedstawcielami SputnikSoftware jedynej w Polsce firmy mającej rozwiązanie pod Linux. Poza rozmowy przez telefon i wysłania im e-maila z zapytaniem o współpracę brak odpowiedzi.

Studium przypadków

Rozwiązania kompleksowe (ale przez to nieco hermetyczne), przetestowane w Portalu AS:

1. Aplikacja kameleon w "grubym kliencie" implementująca na formularzu komponent webBrowser (silnik IE 6/7) do wyświetlania witryny AS (użytkownik ma całkowite złudzenie, że korzysta z przeglądarki internetowej), która przechwytuje zdarzenia w przeglądarce i obsługuje lokalne zasoby, w tym przypadku czytnik smart card i wszystkie biblioteki (.dll czy .ocx) Windows. Była to wersja I podpisu cyfrowego dokumentów zamówień w Portalu AS. Eksploatowana od 2006 roku. Wynik:
   1. Zalety:
      1. Zero niespodzianek i potrzeb zdobywania nowych "doświadczeń" od strony użytkownika
      2. Doskonała współpraca z urządzaniami peryferyjnymi i komponentami Windows
      3. Bezproblemowa komunikacja z czytnikiem
      4. Bezpieczeństwo - użytkownik ma dostęp do jedynie tych adresów URL na które mu zezwolimy
   2. Wady:
      
      1. Potrzeba instalacja (użytkownik musi pobrać z witryny i zainstalować u siebie aplikację) chociaż wykorzystywane przeze mnie narzędzie do tworzenia instalacji sprowadza jej proces do bezmyślnego klikania OK),
      2. W jednym przypadku (opcja upoważnień witryna się zawieszała),
      3. Być może do był powód poprzedniego problemu - zła obsługa wielu instancji okien przeglądarkowych
   3. Werdykt - rozwiązanie niezłe, przy odrobinie samozaparcie można problem ten zbadać i albo go usunąć albo znaleźć obejście.
2. Aplikacja natywna w "grubym kliencie". Jest to rasowa aplikacja wykonana w WinForm w środowisku .NET. Wszystkie kontrolki potrzebujące danych z bazy (np. listy rozwijane, tabele/gridy) są zasilane poprzez technologię AJAX z baz po stronie portalu, czyli aplikacja wszystkie świeże dane ściąga z witryny poprzez prymitywną usługę webową. Dalej jak powyżej, dostęp do wszystkich zasobów lokalnych jest bez ograniczeń. Była to wersja II podpisu cyfrowego dokumentów zamówień w Portalu AS. Eksploatowana od 2007 roku. Wynik:
   1. Zalety:
      1. Doskonała współpraca z zasobami lokalnymi i sieciowymi oraz komponentami Windows
      2. Bezproblemowa komunikacja z czytnikiem
      3. Bezpieczeństwo - pełna kontrola nad użytkownikiem
      4. Zgodność z wymaganiami MS dla aplikacji klienckich
      5. Wykorzystanie biblioteki Sigillum z jej pełnym zestawem możliwości np. realizacja podpisu wielokrotnego
      6. Możliwość łatwego generowania wydruków pod katem użytkownika lub nawet przez użytkownika (dostępny jest generator wydruków)
   2. Wady:
      1. Potrzeba instalacja (użytkownik musi pobrać z witryny i zainstalować u siebie aplikację) chociaż wykorzystywane przeze mnie narzędzie do tworzenia instalacji sprowadza jej proces do bezmyślnego klikania OK. W przypadku .NET ułatwieniem może być automatyczna aktualizacja programu bezpośrednio z witryny Portalu.
      2. Brak pełnej funkcjonalności portalu - udostępnia jedynie jego wąski skrawek, są użytkownicy chcący spojrzeć szerzej na portal - dla nich trzeba by dopisać coś więcej, chociaż z drugiej strony można im udostępnić komponent w innym WinForm komponent webBrowser z rozwiązania nr.1.
   3. Werdykt - rozwiązanie niezłe i jednocześnie nowoczesne udostępniające pełną gamę funkcji związanych z podpisem. Należy nadal rozwijać
3. Podpis poprzez ActiveX - użytkownik ma możliwość wykonania wszelkich prac związanych ze składaniem podpisu i weryfikacją bezpośrednio w przeglądarce pracując w portalu dziedzinowym. Dostęp do tych funkcji ma poprzez osadzenie na stronie internetowej kontrolki ActiveX (CAPICOM lub Sigillum). Metoda eksploatowana w Portalu AS od 2007 roku w przypadku ok. 15% klientów.
1. Zalety:
   1. Zero niespodzianek i potrzeb zdobywania nowych "doświadczeń" od strony użytkownika
   2. Przeźroczyste dla użytkownika - nic nie musi instalować
   3. Dostęp z poziomu przeglądarki do wszystkich funkcji jak w przypadku "grubego klienta"
2. Wady:
1. Potrzeba zgody użytkownika na zainstalowanie "obcej" kontrolki
2. Potrzeba skorygowania często niepoprawnie działającej konfiguracji przeglądarki
3. Potrzeba skonfigurowania poziomu zabezpieczeń przeglądarki aby zezwalała na dostęp do repozytorium certyfikatów i samego czytnika
4. Trudność dokonania diagnozy i zdalnej konfiguracji w przypadku niedoświadczonych użytkowników
3. Werdykt - rozwiązanie działa poprawnie w środowisku przeglądarki MS IE i lokalnej sieci gdzie administrator ma kontrolę nad instalacjami
4. Podpis poprzez applet Java - dostęp do w/w funkcji odbywa się poprzez podpisany zaufanym certyfikatem specjalny applet w języku Java. Komunikacja z czytnikiem wygląda tak:
   1. Strona internetowa przekazuje żądanie do appletu wraz z kluczem do dokumentu źródłowego,
   2. Applet uruchamia i przekazuje ten klucz do komponentu lokalnego (np. dll)
   3. Komponent lokalny (opakowana funkcjonalność CAPICOM lub Sbibiloteki Sigillum w .dll) - który na jego podstawie pobiera z Internetu dokument, podpisuje go i odsyła z powrotem.
   4. Applet jest niewizualny (nie ma interfejsu graficznego) jego zadaniem jest łączenie strony internetowej ze środowiskiem lokalnym.
   5. Rozwiązanie nie wdrożone (działa prototyp).
   6. Wady:
      1. Potrzeba zakupu certyfikatu Authenticode do podpisania appletu
      2. Potrzeba zgody użytkownika na zainstalowanie "obcego" appletu
   7. Zalety:
      1. Otwartość i uniwersalność - działa w każdej przeglądarce
      2. Przeźroczyste dla użytkownika - nic nie musi instalować (no musi zainstalować .dll ale to można zautomatyzować)
   8. Werdykt - rozwiązanie nie gotowe ale o potencjalnie dużych możliwościach

Rozwiązania cząstkowe

Narzędzia do wykorzystania:

1. Baza danych dla dokumentów źródłowych i podpisanych
2. Własne biblioteki .dll opakowująca funkcjonalność CAPICOM i Sigillum
3. Rozwiązanie 1-4 są dostępne do analizy
4. Pobieranie i sprawdzanie certyfikatu z listami CRL (program w Javie poprzez połączenie z Internetem ściąga plik CRL)
5. Serwer sprawdzający certyfikat jw ale z wykorzystaniem OCSP i biblioteki Sigillum (usługa webowa na platformie .NET - wymaga MS Windows Server)
   

Wnioski

1. Wybór technologii:
   1. Rozwiązania .NET i Java są jeszcze niedojrzałe (brakuje im specjalizacji np. obsługi urządzeń, uwzględnienia specyfiki wymagań podpisu krajowego).
   2. Obiecująco wygląda rozwiązanie oparte o Javę, jest otwarte i ciągle rozwijane poprzez prace środowiska open-source
   3. Rozwiązanie oparte o CAPICOM jest dojrzałe i sprawdzone ale ma dwie wady: nie jest dalej rozwijane przez MS (w jego miejsce ma wejść .NET ale nie jest jeszcze gotowe)
   4. Rozwiązanie zamknięte wykorzystujące biblioteki dostawcy sprzętowego jest chyba na chwilę dzisiejszą najbardziej obiecujące, załatwia wszystkie potrzeby odnośnie podpisu oraz uwzględnia specyfikę krajowego ustawodawstwa. Ale jest mało mało uniwersalne.

Nowe cechy Javy:
Java powinna być bezpieczna z założenia, że działa w "piaskownicy" parametry bezpieczeństwa której można definiować. Model bezpieczeństwa Java składa się z dwóch warstw Core Java 2 Security Architecture i Java Cryptography Architecture. Stanowią one podstawowy poziom bezpieczeństwa nad którym są różne rozszerzenia (extension). Od wersji 1.4 Java ma własne mechanizmy obsługi kryptografii i nie trzeba uciekać się do bibliotek firm trzecich np. Bouncy Castle.

Opis J2SA składa się z:

1. byte code verifier - sprawdza ponownie poprawność użytych konstrukcji języka (czy klasy mają cechę public, czy klasa final ma podklasę itd)
2. class loader - ładuje klasy do maszyny wirtualnej i sprawdza poprawność odwołań do klas w ramach języka i do zasobów lokalnych
3. security manager - klasa stworzona przez twórcę aplikacji zezwala na dostęp do zasobów
4. access controller - niskopoziomowe sprawdzenie wykonywania się aplikacji (zarządzanie pamięcią, typowanie danych, naruszenie konwersji danych)

Opis JCA - realizuje funkcje kryptograficzne i udostępnia API do nich.
Rozszerzenia:

1. Java Cryptographic Extension
2. Java Security Socket Extension
3. Java Autentication and Authorization Extension Service
   

Ciekawe linki

http://www.javaworld.com/javaworld/jw-11-2006/jw-1101-netbeans5.html - co daje netbeans:

1. New features in NetBeans 5.5 include the Java Persistence API and the Java API for XML Web Services (JAX-WS) 2.0 productivity tools, and support for the open source version-control system Subversion. Also in the new release of NetBeans are enhancements to its GUI builder, work previously carried out under the name Project Matisse.
2. Sun also released five value-added packs for NetBeans 5.5, including a technology preview of NetBeans Visual Web Pack for developing applications using JavaServer Faces (JSF) as well as a beta version of NetBeans C/C++ Pack, which enables C or C++ developers to use NetBeans alongside their own compiler and tools. The NetBeans Enterprise Pack brings together tools for creating and testing SOA (service-oriented architecture) applications.