Bezpieczeństwo w J2EE

Model programowania aplikacji J2EE oddziela projektowanie od specyficznych szczegółów implementacji mechanizmu zapewniającego bezpieczeństwo. Dzięki temu zwiększa się przenośność aplikacji, które mogą być wdrażane w rozmaitych środowiskach, z różnymi poziomami bezpieczeństwa.

Zalecane jest wcześniejsze zapoznanie się z zasadami bezpieczeństwa w Javie: The Java Tutorial (zobacz http://java.sun.com/docs/books/tutorial/security1.2/index.html)

Spis treści

Wstęp
Role związane z bezpieczeństwem
Role References - deklarowanie i linkowanie odwołań do ról
Mapowanie ról z użytkownikami i grupami J2EE
Bezpieczeństwo warstwy Web
Ochrona zasobów sieciowych
Kontrola dostępu do zasobów sieciowych
Uwierzytelnianie użytkowników zasobów sieciowych
Używanie programowalnego bezpieczeństwa (Programmatic Security) w warstwie Web
Niechronione zasoby sieciowe
Bezpieczeństwo warstwy EJB
Deklarowanie pozwoleń dla metod
Używanie programowanego bezpieczeństwa w warstwie EJB
Niechronione zasoby warstwy EJB
Bezpieczeństwo warstwy aplikacji klienckiej
Definiowanie Callback Handler w aplikacji klienckiej
Bezpieczeństwo warstwy EIS
Konfigurowanie zapisów (Sign-On)
Zapisy zarządzane przez kontener
Zapisy zarządzane przez komponent
Konfigurowanie Resource Adapter Security
Propagacja ID bezpieczeństwa
Konfiguracja propagowanego ID bezpieczeństwa komponentu
Konfigurowanie uwierzytelniania klienta
Użytkownicy J2EE, Dziedziny oraz Grupy
Zarządzanie Użytkownikami oraz Grupami J2EE
Konfigurowanie Certyfikatu Serwera (Server Certificate)

Wstęp

 Poprzedni Początek Następny

Platforma J2EE definiuje deklaratywne umowy pomiędzy tymi, którzy piszą komponenty aplikacji oraz tymi, którzy konfigurują aplikacje w środowisku docelowym. W kontekście bezpieczeństwa aplikacji programista jest zobowiązany do zadeklarowania wymagań dla swojej aplikacji w taki sposób, aby te wymagania mogły zostać spełnione w trakcie jej konfiguracji. Mechanizm deklaratywnego bezpieczeństwa (declarative security) używany w aplikacji zapisuje się w deklaratywnej składni w dokumencie deployment descriptor. Następnie osoba wdrażająca, za pomocą odpowiednich narzędzi kontenera, określa które wymagania aplikacji, zdefiniowane w tym opisie, mają być realizowane przez jakie mechanizmy bezpieczeństwa, zaimplementowane w kontenerach J2EE. W J2EE SDK funkcjonalność tą zapewnia narzędzie deploytool.

Programowalne bezpieczeństwo (programmatic security) odpowiada za te aspekty bezpieczeństwa aplikacji, które nie mieszczą się w obrębie deklaratywnego bezpieczeństwa, np. aplikacja dokonuje autoryzacji na podstawie daty i godziny, parametrów wywołania albo bieżącego stanu ziarenka albo komponentu webowego. Inna aplikacja może ograniczać dostęp bazując na informacjach użytkownika przechowywanych w bazie danych.

Aplikacje J2EE są tworzone z komponentów, które mogą być umieszczane w różnych kontenerach. Komponenty zazwyczaj tworzą wielozadaniową aplikację. Celem bezpieczeństwa w architekturze J2EE jest osiągnięcie bezpieczeństwa end-to-end przez zabezpieczanie każdej warstwy.

Warstwy mogą zawierać zarówno zasoby chronione jak i niechronione. Często trzeba chronić zasoby, aby tylko autoryzowani użytkownicy mieli do nich dostęp. Autoryzacja zapewnia kontrolę dostępu do chronionych zasobów. Autoryzacja bazuje na identyfikacji i uwierzytelnianiu (autentication). Identyfikacja to proces umożliwiający rozpoznanie encji przez system, natomiast uwierzytelnianie weryfikuje tożsamość użytkownika, urządzenia lub innej encji w systemie, zazwyczaj jako wstępny warunek przed pozwoleniem na dostęp do zasobów systemu.

Autoryzacja nie jest wymagana przy dostępie do niechronionych zasobów. Ponieważ autoryzacja jest realizowana przez uwierzytelnianie, również uwierzytelnianie nie jest wymagane przy dostępie do niechronionych zasobów. Dostęp do zasobów bez uwierzytelnienia jest opisany dalej jako nieuwierzytelniony lub anonimowy dostęp (unauthenticated, anonymous).

Role związane z bezpieczeństwem

 Poprzedni Początek Następny

Kiedy się tworzy ziarenko (enterprise bean) albo komponent webowy, powinno się zawsze pomyśleć jacy użytkownicy będą mieli do niego dostęp. Przykład: ziarenko Account może być udostępnione klientom, kasjerom i kierownikom działu/filii banku. Każda taka kategoria użytkowników jest nazywana rolą (security role). Rola to abstrakcyjna logiczna grupa użytkowników, która jest zdefiniowana przez twórcę aplikacji. W momencie umieszczania aplikacji w środowisku administrator przypisze role z aplikacji do ich odpowiedników w systemie operacyjnym.

W J2EE zdefiniowane są grupy, które również reprezentują kategorie użytkowników, ale mają one nieco szerszy zasięg niż role. Grupy są zdefiniowane dla całego serwera, natomiast role dotyczą konkretnej aplikacji na serwerze.

Role w aplikacji J2EE deklaruje się dla plików EJB JAR (w przypadku enterprise bean) oraz WAR (w przypadku Web component). Na przykład, aby dodać role za pomocą deploytool należy:

  1. Wybrać odpowiedni plik EJB JAR lub WAR.
  2. W zakładce Roles kliknąć Add.
  3. W tabeli wpisać odpowiednie wartości w pola Name i Description.

Role References - deklarowanie i linkowanie odwołań do ról

Odwołania do ról (security role reference) umożliwiają ziarenkom i komponentom korzystanie z istniejących ról. Rola to specyficzna dla aplikacji, logiczna grupa użytkowników, klasyfikowanych wg wspólnych cech takich jak profil klienta albo stanowisko. W trakcie wdrażania aplikacji role zostają przypisane jakimś konkretnym bytom związanym z bezpieczeństwem, takim jak grupa albo principals (coś co zostaje związane z każdym użytkownikiem w wyniku jego uwierzytelniania). W rezultacie użytkownik przypisany do danej roli nabywa prawa dostępu do aplikacji. Link to aktualna nazwa roli, do której chcemy się odwoływać.

W trakcie pisania aplikacji programista tworzy role dla aplikacji i przypisuje im dostępne mechanizmy bezpieczeństwa. Następnie rozwija odwołania do ról w konkretnych servletach i JSP przez zlinkowanie ich z rolami zdefiniowanymi dla aplikacji.

Odwołanie do roli definiuje mapowanie pomiędzy nazwą roli, której używa się w komponentach lub ziarenkach, a nazwą roli zdefiniowanej dla aplikacji. W komponentach używa się isUserInRole(String name) (zobacz Wykorzystywanie programowalnego bezpieczeństwa w warstwie Web), natomiast w enterprise bean isCallerInRole(String name) (zobacz Wykorzystywanie programowalnego bezpieczeństwa w warstwie EJB). Przykład: niech cust będzie odwołaniem do roli o nazwie bankCustomer. Mapowanie można zrealizować w następujący sposób:

  1. Wybierz komponent albo ziarenko.
  2. Wybierz zakładkę Security.
  3. Jeśli w Role Names Referenced In Code nie pojawia się cust, kliknij przycisk Add.
  4. Wpisz cust w kolumnie Coded Name.
  5. Z rozwijalnego menu w kolumnie Role Name wybierz rolę o nazwie bankCustomer
    Jeśli rola, którą chcesz zmapować nie znajduje się na liście w kolumnie Role Name, kliknij Edit Roles i ją dodaj.
  6. Kliknij ikonkę folderu, aby dodać opis do odwołania cust.
  7. W okienku dialogowym Description wpisz opis.
  8. Kliknij OK żeby zapisać lub Cancel żeby anulować.

W podanym przykładzie zarówno isUserInRole("bankCustomer") jak i isUserInRole("cust") zwrócą true dla metod wskazanych w okienku Method Permissions.

Odwołanie do roli jest linkowane z nazwą roli. Z tego powodu nie trzeba zmieniać odwołania (grzebać w kodzie), jeśli zmieni się nazwa roli. Trzeba natomiast ponownie zlinkować z nową nazwą.

Mapowanie ról z użytkownikami i grupami J2EE

W momencie tworzenia aplikacji powinno się znać role użytkowników z niej korzystających. Prawdopodobnie jednak nie wie się, którzy dokładnie to będą użytkownicy. Architektura J2EE zapewnia, że w momencie wdrażania administrator serwera J2EE zmapuje role do konkretnych użytkowników lub grup. W przykładzie z ziarenkiem Account administrator może podpiąć użytkownika Alicja do roli Manager, natomiast użytkowników Bartek, Czeslaw i Daria do roli Teller.

Administrator może posłużyć się narzędziem deploytool żeby zmapować role do konkretnych użytkowników i grup:

  1. Wybrać aplikację J2EE.
  2. W zakładce Security wybrać odpowiednie role z listy Role Name.
  3. Kliknac Add.
  4. W oknie dialogowym Users wybrać użytkowników i grupy, które powinny należeć do roli. (Zobacz Zarządzanie użytkownikami i grupami J2EE żeby dowiedzieć się jak tworzyć użytkowników i grupy za pomocą deploytool.)

Bezpieczeństwo warstwy Web

 Poprzedni Początek Następny

Poniższe sekcje dotyczą ochrony zasobów i uwierzytelniania użytkowników w warstwie Web.

Ochrona zasobów sieciowych

Można chronić zasoby sieciowe specyfikując warunki bezpieczeństwa (security constraint). Taki warunek określa, kto jest upoważniony korzystania z kolekcji zasobów sieciowych. Taka kolekcja to lista wzorców URL i metod HTTP, która opisuje zbiór zasobów, które mają być chronione. Warunki bezpieczeństwa mogą być definiowane za pomocą deploytool, jak zostało opisane poniżej (patrz Kontrola dostępu do zasobów sieciowych).

W momencie, gdy ktoś próbuje się dostać do chronionych zasobów, kontener próbuje go uwierzytelnić. Kontener zaakceptuje żądanie tylko jeśli użytkownik udowodni swoją tożsamość i będzie miał prawa dostępu do zasobu.

Kontrola dostępu do zasobów sieciowych

Poniższa procedura w deploytool umożliwia wyspecyfikowanie warunku bezpieczeństwa (security constraint) dostępu do zasobów sieciowych.

  1. Wybierz WAR zawierający zasoby, wymagające ochrony dostępu.
  2. Wybierz zakładkę Security.
  3. Kliknij przycisk Add w sekcji Security Constraints.
  4. Kliknij przycisk Edit sąsiadujący z polem Web Resource Collection, żeby dodać kolekcję zasobów. Kolekcja zasobów opisuje pary wzorców URL i metod HTTP, które odnoszą się do zasobów wymagających ochrony.
  5. Kliknij przycisk Edit sąsiadujący z polem Authorized Roles, żeby dodaj jedną lub więcej ról, które uzyskają prawa dostępu do podanej przed chwilą kolekcji.

Uwierzytelnianie użytkowników zasobów sieciowych

W momencie próby dostępu do chronionego zasobu kontener uruchamia procedurę uwierzytelniania, skonfigurowaną dla tego zasobu. Można zdefiniować następujące procedury uwierzytelniania dla zasobu:

Proste uwierzytelnianie HTTP

Serwer będzie uwierzytelniał użytkownika za pomocą loginu i hasła uzyskanych od klienta webowego.

Uwierzytelnianie przez formularz

W tym przypadku można zdefiniować okienko logowania i komunikaty błędów, które będą wyświetlone ostatecznemu użytkownikowi przez przeglądarkę.

Dwie powyższe metody nie są tak naprawdę bezpieczne. W form-based authentication zawartość okna dialogowego jest przesyłana otwartym tekstem, a docelowy serwer nie jest uwierzytelniony. Basic authentication przesyła login i hasło kodowane Base64, ale nie szyfrowane. Jeśli połączenie nie odbywa się poprzez SSL, to w przypadku przechwycenia transmisji dane mogą zostać łatwo odczytane.

Uwierzytelnianie przez certyfikat

Ostatnia metoda jest bezpieczniejsza, bo z założenia odbywa się za pomocą SSL (HTTPS). Serwer uwierzytelnia klienta za pomocą X.509 certificate.

Konfiguracja procedury uwierzytelniania użytkowników zasobów sieciowych

Aby zdefiniować procedurę uwierzytelniania:

  1. Wybierz WAR zawierający zasoby.
  2. Wybierz zakładkę Security.
  3. Z rozwijalnego menu User Authentication Method wybierz jedną z dostępnych opcji: None, Basic, Client-Certificate albo Form Based.
    1. Jeśli zostało wybrane form-based authentication, kliknij Settings i uzupełnij informacje w polach Realm Name, Login Page, and Error Page. Error Page zostanie wyświetlona gdy użytkownikowi nie będzie mógł się zalogować.
    2. Jeśli zostało wybrane basic authentication, kliknij Settings i wpisz Default w polu Realm Name.

Użycie protokołu SSL do poprawienia HTTP Basic oraz Form-Based Authentication

Hasła nie są chronione przy uwierzytelnianiach typu HTTP basic i form-based authentication. Można obejść to uruchamiając protokół logowania pod sesją SSL.

Żeby skonfigurować HTTP basic lub form-based authentication pod sesją SSL:

  1. Wybierz komponent. Zostanie wyświetlony Web Component inspector.
  2. W zakładce Security upewnij się, że w menu User Authentication Method zostało wybrane Basic lub Form Based.
  3. Kliknij przycisk Add w sekcji Security Constraint.
  4. Kliknij na dodany warunek.
  5. Wybierz CONFIDENTIAL w rozwijalnym menu Network Security Requirement.

Używanie programowalnego bezpieczeństwa (Programmatic Security) w warstwie Web

Programowanie bezpieczeństwa jest używane, gdy samo deklaratywne bezpieczeństwo nie wystarcza, by wyrazić założenia dotyczące bezpieczeństwa zawarte w modelu aplikacji. Programowane bezpieczeństwo opiera się na następujących metodach interfejsu HttpServletRequest:

Metoda getRemoteUser jest używana do pobierania nazwy klienta, który ma być uwierzytelniony. Metoda isUserInRole umożliwia określenie czy użytkownik należy do odpowiedniej grupy. Metoda getUserPrincipal zwraca obiekt klasy java.security.Principal.

Te API pozwalają serwletom podejmowanie decyzji biznesowych na postawie logicznej roli zdalnego użytkownika.

Niechronione zasoby sieciowe

Dużo aplikacji zawiera dane, które nie muszą być chronione i każdy ma do nich dostęp bez potrzeby uwierzytelniania. W warstwie Web nieograniczony dostęp realizuje się przez nie konfigurowanie procedur uwierzytelniajacych.

Bezpieczeństwo warstwy EJB

 Poprzedni Początek Następny

Ta część opisuje zarówno deklaratywne jak i programowane mechanizmy bezpieczeństwa, które mogą być użyte do ochrony warstwy EJB. Chronione zasoby obejmują metody ziarna, które mogą być wołane przez aplikacje klienckie, komponenty oraz inne ziarna.

Można chronić zasoby warstwy EJB przez:

Deklarowanie pozwoleń dla metod (Method Permissions)

Po zdefiniowaniu ról można zdefiniować pozwolenia na wykonywanie metod ziarna. Takie pozwolenie określa, które role mogą wywoływać które metody.

Poniższa procedura określa, w jaki sposób za pomocą deploytool zdefiniować pozwolenia dla ról na wykonywanie metod:

  1. Wybierz ziarenko.
  2. Wybierz zakładkę Security.
  3. W tabelce Method Permissions wybierz Set Roles w kolumnie Availability.
  4. Zaznacz checkbox'y przy tych rolach, które powinny móc wywoływać metody.

Używanie programowanego bezpieczeństwa w warstwie EJB

Programowane bezpieczeństwo w warstwie EJB opiera się na metodach getCallerPrincipal i isCallerInRole. getCallerPrincipal służy do określania, kto woła metodę, natomiast isCallerInRole do ustalenia jego roli.

Metoda getCallerPrincipal pochodzi z interfejsu EJBContext i zwraca obiekt klasy java.security.Principal, który opisuje, kto woła metodę ziarenka (w tym przypadku principal jest taki sam jak user). W poniższym przykładzie metoda ziarenka getUser zwraca nazwę użytkownika, który ją wywołał: 

	public String getUser() {
	   return context.getCallerPrincipal().getName();
	}

Żeby sprawdzić czy użytkownik należy do jakiejś roli należy użyć metody isCallerInRole:

	boolean result = context.isCallerInRole("Customer");

Niechronione zasoby warstwy EJB

Standardowo J2EE SDK przydziela rolę ANYONE do każdej metody. Użytkownik guest, który jest anonimowy i nieuwierzytelniony należy do roli ANYONE. W ten sposób każdy użytkownik może wywołać metodę, do której programista nie przypisał jakiś konkretnych ról.

Bezpieczeństwo warstwy aplikacji klienckiej

 Poprzedni Początek Następny

Wymagania dotyczące uwierzytelniania dla aplikacji klienckich w J2EE są takie same jak wymagania dla innych komponentów. Dostęp do chronionych zasobów zarówno w warstwie EJB jak i w warstwie Web wymaga uwierzytelnienia.

Aplikacja kliencka może używać do uwierzytelniania Java Authentication and Authorization Service (JAAS). JAAS implementuje javowa wersje PAMa, czyli oddziela prawa dostępu aplikacji od technologii uwierzytelniania, tzn. sam mechanizm uwierzytelniania może być zmieniany bez potrzeby modyfikowania aplikacji. Aplikacje umożliwiają proces uwierzytelnienia poprzez stworzenie instancji obiektu LoginContext, który z kolei sprawdza konfigurację, aby określić technologię uwierzytelniania lub moduły logujące.

Typowy moduł logujący będzie prosił o login i hasło. Inne moduły mogą odczytywać odciski palców albo rozpoznawać głos.

W niektórych przypadkach moduł logujący będzie musiał się komunikować z użytkownikiem, żeby uzyskać odpowiednie informacje, np. moduł CODE>javax.security.auth.callback.CallbackHandler. Aplikacje implementują interface CallbackHandler i podają go do kontekstu logowania, który przekazuje go bezpośrednio do odpowiednich modułów. Moduły logujące używają tego handlera zarówno do pobierania informacji od użytkownika (hasło, PIN itp.) jak i do prezentacji istotnych informacji (np. o statusie). Ponieważ to w aplikacji jest zdefiniowany sposób porozumiewania się z użytkownikiem w trakcie autoryzacji, to moduł logujący może działać niezależnie od innych form komunikowania się aplikacji z użytkownikiem.

Przykład: implementacja handlera dla aplikacji GUI może wyświetlać okienko logowania, natomiast handler dla narzędzia uruchamianego z linii komend może po prostu wymagać od użytkownika wpisania hasła w tejże linii komend.

Moduł logujący daje tablicę wartości do metody handle (np. dla użytkownika nazwę i login jako NameCallback i PasswordCallback), następnie handler wywołań wykonuje żądaną interakcję użytkownika i ustawia odpowiednie zwracane wartości. Przykład: żeby przetworzyć NameCallback, CallbackHandler może poprosić o nazwę, odebrać nazwę od użytkownika i wywołać metodę setName obiektu NameCallback żeby uzyskaną nazwę zapamiętać.

Definiowanie Callback Handler w aplikacji klienckiej

Poniższa procedura umożliwia zdefiniowanie handlera za pomocą deploytool:

  1. Wybierz aplikację JAR.
  2. Wybierz zakładkę General.
  3. Z menu CallbackHandler Class wybierz klasę CallbackHandler, która ma być używana do komunikacji z użytkownikiem w czasie logowania.

Bezpieczeństwo warstwy EIS

 Poprzedni Początek Następny

W warstwie EIS komponent aplikacji żąda połączenia do zasobu EIS. Jako część tego połączenia EIS może wymagać zapisania się (sign-on) do zasobu. Dostawca komponentów aplikacji może zapisać się do EIS na dwa sposoby:

Dostawca komponentu może użyć deploytool, żeby wybrać sposób zapisywania do EIS.

Konfigurowanie zapisów (Sign-On)

Poniższa procedura opisuje jak za pomocą deploytoolskonfigurować typ zapisów.

  1. Wybierz komponent.
  2. Wybierz zakładkę Resource Refs.
  3. Kliknij Add.
  4. W combo box Authentication wybierz Container dla zapisów zarządzanych przez kontener albo Application dla zarządzanych przez komponent.

Zapisy zarządzane przez kontener

W zapisach zarządzanych przez kontener aplikacja nie musi podawać żadnych informacji, żeby zostać zapisana do zasobu. Informacje dotyczące bezpieczeństwa dostarczane są przez kontener, co widać w poniższym przykładzie: 

// Business method in an application component
Context initctx = new InitialContext();
// perform JNDI lookup to obtain a connection factory
javax.resource.cci.ConnectionFactory cxf =
     (javax.resource.cci.ConnectionFactory)initctx.lookup(
      "java:comp/env/eis/MainframeCxFactory");
// Invoke factory to obtain a connection. The security
// information is not passed in the getConnection method
javax.resource.cci.Connection cx = cxf.getConnection();
...

Zapisy zarządzane przez komponent

W przypadku zapisów zarządzanych przez komponent, komponent aplikacji jest zobowiązany dostarczyć potrzebne dane dotyczące bezpieczeństwa w metodzie getConnection() żeby zapisać się do zasobu. Mogą to być np. login i hasło jak w poniższym przykładzie:

// Method in an application component
Context initctx = new InitialContext();
// perform JNDI lookup to obtain a connection factory
javax.resource.cci.ConnectionFactory cxf =
     (javax.resource.cci.ConnectionFactory)initctx.lookup(
       "java:comp/env/eis/MainframeCxFactory");
// Invoke factory to obtain a connection
com.myeis.ConnectionSpecImpl properties = //..
// get a new ConnectionSpec
properties.setUserName("...");
properties.setPassword("...");
javax.resource.cci.Connection cx = 
  cxf.getConnection(properties);
...

Konfigurowanie Resource Adapter Security

Dodatkowo, aby skonfigurować zapisy trzeba jeszcze skonfigurować Resource Adapter Security. W tym celu należy:

  1. Wybrać RAR (Resource Adapter Archive).
  2. Wybrać zakładkę Security. W okienku Authentication Mechanisms wybrać, który mechanizm uwierzytelniania będzie realizowany:
    • Password: Do połączenia z EIS wymagane są użytkownik i hasło.
    • Kerberos Version 5.0: Adapter zasobów udostępnia mechanizm uwierzytelniania Kerberos. Zobacz RFC-1510, The Kerberos Network Authentication Service (V5): http://www.ietf.org/rfc/rfc1510.txt.
    Można wybrać wiele mechanizmów, jeden albo żaden. Jeśli żaden mechanizm nie zostanie wybrany nie będzie realizowane uwierzytelnianie.
  3. Wybrać Reauthentication Supported jeśli adapter zasobów udostępnia wykonywanie ponownego uwierzytelnienia na istniejącym fizycznym połączeniu. Ponowne uwierzytelnienie będzie wykonywane kiedy serwer aplikacji wywoła metodę getConnection() w innym kontekście bezpieczeństwa niż ten, w którym było nawiązywane połączenie.
  4. W okienku Security Permissions kliknij przycisk Add, żeby dodać security permission, którego twój adapter będzie wymagał do dostępu do zasobów systemowych. Wystarczy zdefiniować te pozwolenia, które nie są zawarte w domyślnym zbiorze pozwoleń (zobacz Table 2, Section 11.2 w J2EE Connector Architecture Specification 1.0).
  5. Dla każdego pozwolenia kliknij w ostatniej kolumnie po prawej stronie (w ikonkę folderu), żeby dodać opis.

Żeby usunąć security permission wybierz odpowiednie pozwolenie w tabeli i kliknij Delete.

Propagacja ID bezpieczeństwa

 Poprzedni Początek Następny

W trakcie wdrażanie ziarenka lub komponentu sieciowego można wyspecyfikować ID bezpieczeństwa (security identity), która będzie propagowana do ziarenek wywoływanych z bieżącego.

Propagacja tożsamości

Można wybrać jeden z poniższych sposobów propagacji:

Konfiguracja propagowanego ID bezpieczeństwa komponentu

Za pomocą deploytool można wybrać typ tożsamości, która będzie propagowana z ziarenka lub komponentu webowego.

Aby propagować tożsamość, z którą ziarenko lub komponent jest uruchamiane należy:

  1. Wybrać komponent.
  2. Wybrać zakładkę Security.
  3. W okienku Security Identity zaznaczyć radio Use Caller ID.

Aby propagować inną tożsamość niż ta, z którą ziarenko lub komponent są uruchamiane:

  1. Wybierz komponent.
  2. Wybierz zakładkę Security.
  3. W okienku Security Identity zaznacz opcję Run As Specified Role.
  4. W rozwijalnym menu wybierz rolę, z którą ma być uruchamiane.
  5. Po wybraniu roli można jeszcze określić konkretnego użytkownika z tej roli. W tym celu należy użyć Deployment Settings.
  6. W oknie Run As Specified User należy wybrać nazwę użytkownika, który będzie używany do uruchamiania metod ziarenka.
  7. Kliknij OK.

Konfigurowanie uwierzytelniania klienta

Jeśli komponent aplikacji w kontenerze klienta aplikacji korzysta z chronionej metody w ziarenku, korzystaj z uwierzytelnienia klienta.

Za pomocą deploytool, wykonaj poniższą procedurę aby skonfigurować uwierzytelnienie klienta:

  1. Wybierz docelowe ziarenko (enterprise bean).
  2. Wybierz zakładkę Security.
  3. Wybierz Deployment Settings aby wyświetlić okienko dialogowe Security Deployment Settings.
  4. Zaznacz czekbox SSL Required aby uaktywnić SSL.
  5. W okienku Client Authentication, wybierz Certificate jako metodę, za pomocą której serwer oczekuje, że klient będzie się uwierzytelniał wobec serwera.
  6. Kliknij OK.

Zaufanie (Trust) pomiędzy Kontenerami

Kiedy ziarnko jest zaprojektowane tak, żeby albo korzystać z oryginalnego ID procedury wywołującej albo ze specjalnie przeznaczonego ID aby wywołać docelowe ziarnko, docelowe ziarnko otrzyma tylko rozprzestrzeniane ID, nie otrzyma natomiast jakichkolwiek danych uwierzytelniających.

Docelowy kontener nie ma sposobu na uwierzytelnienie rozpowszechnianego ID bezpieczeństwa (security identity). Jednakże, ponieważ ID bezpieczeństwa jest wykorzystywane do weryfikacji uwierzytelniania (np. prawa dostępu metod albo korzystając z metody isCallerInRole()) jest to bardzo ważne, żeby ID bezpieczeństwa było prawdziwe. Ponieważ nie ma dostępnych danych uwierzytelniajacych, aby uwierzytelnić rozpowszechniane ID, obiekt docelowy musi zaufać, że wywołujący kontener rozpowszechnił uwierzytelnione ID bezpieczeństwa.

Domyślnie, serwer J2EE SDK jest skonfigurowany, aby ufał ID rozpowszechnianym z różnych kontenerów. W związku z tym nie ma specjalnych kroków, które trzeba powziąć, aby ustanowić więź zaufania (trust relationship).

Użytkownicy J2EE, Dziedziny oraz Grupy

 Poprzedni Początek Następny

Użytkownik J2EE jest podobny do użytkownika systemu operacyjnego. Zwykle oba typy użytkowników reprezentują ludzi. Jednakże te dwa typy użytkowników nie są tożsame. Serwis uwierzytelniania J2EE nie ma wiedzy o nazwie użytkownika i haśle, które wpisuje się, logując się do systemu operacyjnego. Serwis uwierzytelniania J2EE nie jest podłączony do mechanizmu bezpieczeństwa systemu operacyjnego. Te dwa serwisy bezpieczeństwa zarządzają użytkownikami należącymi do innych dziedzin.

Dziedzina jest zbiorem użytkowników, którzy są kontrolowani przez tę samą politykę uwierzytelniania (authentication policy). Serwis uwierzytelniania J2EE zarządza użytkownikami w dwóch dziedzinach: certyfikatu oraz domyślnej.

Certyfikaty są używane razem z protokołem HTTPS aby uwierzytelniać klienta przeglądarek internetowych. Aby zweryfikować tożsamość użytkownika w dziedzinie certyfikatu, serwis uwierzytelniający weryfikuje certyfikat X.509. Aby dostać instrukcje krok po kroku patrz Konfigurowanie Certyfikatu Serwera. Pole powszechnej nazwy certyfikatu X.509 jest używane jako główna nazwa.

W większości przypadków, serwis uwierzytelniania J2EE weryfikuje tożsamość użytkownika poprzez sprawdzenie domyślnej dziedziny. Ta dziedzina jest używana do uwierzytelniania wszystkich klientów poza klientami przeglądarek internetowych, korzystającymi z protokołu HTTPS oraz certyfikatów.

Użytkownik J2EE z domyślnej dziedziny może należeć do grupy J2EE. (Użytkownik z dziedziny certyfikatu nie może). Grupa J2EE to kategoria użytkowników, klasyfikowana przez wspólne cechy, takie jak stanowisko lub profil klienta. Np. większość klientów aplikacji e-commerce może należeć do grupy CUSTOMER ale kupujący najwięcej należą do grupyPREFERRED. Kategoryzowanie użytkowników w grupy ułatwia kontrolę dostępu w przypadku dużej liczby użytkowników. Sekcja Bezpieczeństwo warstwy EJB wyjaśnia, jak kontrolować dostęp użytkowników do ziarenek.

Zarządzanie Użytkownikami oraz Grupami J2EE

Ta sekcja pokazuje jak wykorzystać deploytool aby wykonać poniższe czynności

Wykonaj poniższą procedurę, aby wyświetlić wszystkich użytkowników w domyślnej dziedzinie lub dziedzinie certyfikatu:

  1. Wybierz serwer, do którego chcesz dodać użytkowników lub grupy.
  2. Wybierz Tools Server Configuration, aby wyświetlić ekran Configuration Installation.
  3. Pod J2EE Server w widoku drzewiastym wybierz Users.
  4. Wybierz dziedzinę (Default lub Certificate).

Wykonaj poniższą procedurę, aby dodać użytkownika do domyślnej dziedziny.

  1. Kliknij Add User.
  2. Wpisz nazwę użytkownika i hasło w odpowiednich polach.
  3. W okienku Group Membership wybierz grupę (z Available groups), do której będzie należał użytkownik, którego dodajesz. Aby wybrać wiele grup, powtórz ten krok.
  4. Kliknij Add aby przenieść zaznaczenie na Grupy.
  5. Kliknij OK po zakończeniu.

Wykonaj poniższą procedurę, aby dodać grupę do domyślnej dziedziny.

  1. Kliknij Edit Groups.
  2. W okienku Groups kliknij Add.
  3. Wybierz linię, którą właśnie dodałeś i wpisz nazwę grupy do dodania.
  4. Kliknij OK po zakończeniu.

Wykonaj poniższą procedurę, aby usunąć grupę z domyślnej dziedziny.

  1. Kliknij Edit Groups.
  2. Z okienka Groups wybierz grupę do usunięcia.
  3. Kliknij Delete.
  4. Kliknij Yes w odpowiedzi na komunikat.
  5. Kliknij OK po zakończeniu.

Wykonaj poniższą procedurę, aby dodać nowego użytkownika do dziedziny certyfikatu.

  1. Wybierz dziedzinę Certyfikatu.
  2. Kliknij Add User.
  3. Wybierz katalog, gdzie znajduje się certyfikat.
  4. Wybierz nazwę pliku dla certyfikatu.
  5. Kliknij OK po zakończeniu.

Konfigurowanie Certyfikatu Serwera (Server Certificate)

 Poprzedni Początek Następny

Certyfikaty są wykorzystywane z protokołem HTTPS do uwierzytelniania klientów przeglądarek Internetowych. Serwis HTTPS serwera J2EE nie będzie działał dopóki nie zostanie zainstalowany Certyfikat Serwera. Wykonaj poniższą procedurę, aby skonfigurować Certyfikat Serwera J2EE.

  1. Wygeneruj parę kluczy i podpisany przez Ciebie certyfikat.
    Narzędzie keytoolpozwala na stworzenie certyfikatu. Narzędzie keytool załączone w pakiecie J2EE SDK korzysta z tej samej składni, co narzędzie w oprogramowaniu J2SE. Jednakże wersja J2EE SDK programistycznie dodaje Java Cryptographic Extension, które implementuje algorytm RSA.
    Aby wygenerować certyfikat, uruchom narzędzie keytool w poniższy sposób, podstawiając zamiast <certificate-alias> alias twojego certyfikatu oraz nazwę twojego pliku keystore zamiast <keystore-filename> 
       keytool -genkey -keyalg RSA -alias <certificate-alias> 
      -keystore <keystore-filename>
  2. Narzędzie keytool zażąda poniższych informacji:
    1. Keystore password: Wpisz hasło. (Możesz użyć "changeit", aby być spójnym z domyślnym hasłem J2EE SDK keystore.)
    2. First and last name: Wpisz w pełni wyspecyfikowaną nazwę twojego serwera. Ta pełna nazwa musi zawierać nazwę komputera oraz nazwę domeny.
    3. Organizational unit: Wpisz właściwą wartość.
    4. Organization: Wpisz właściwą wartość.
    5. City or locality: Wpisz właściwą wartość.
    6. State or province: Wpisz pełną nazwę.
    7. Two-letter country code: Dla USA dwuliterowy skrót stanu.
    8. Key password for alias: Nie wpisuj hasła. Wciśnij klawisz Enter.
  3. Zaimportuj certyfikat.
    Jeśli twój certifikat będzie podpisany przez innego CA niż Verisign, musisz go zaimportować. W przeciwnym przypadku pomiń ten punkt. (Jednak jeśli twój certyfikat jest podpisany przez Verisign Test CA, to musisz go zaimportować).
    Aby zaimportować certyfikat, wykonaj poniższe czynności:
    1. Złóż prośbę o certyfikat CA do twojego CA. Zapisz certyfikat w postaci pliku.
    2. Aby zainstalować certyfikat CA w Java 2 Platform, Standard Edition, uruchom narzędzie keytool w poniższy sposób (musisz mieć odpowiednie prawa aby zmodyfikować plik $JAVA_HOME/jre/lib/security/cacerts). 
            keytool -import -trustcacerts -alias <ca-cert-alias> 
         -file <ca-cert-filename>
  4. Jeśli chcesz, aby twój certyfikat został cyfrowo podpisany przez CA wykonaj następujące czynności:
    1. Wygeneruj Certificate Signing Request (CSR). 
            keytool -certreq -sigalg MD5withRSA -alias <cert-alias> 
         -file <csr-filename>
    2. Wyślij zawartość <csr-filename> do podpisania. Jeśli korzystasz z Verisign CA, użyj http://digitalid.verisign.com/. Verisign wyśle podpisany certyfikat za pośrednictwem e-maila. Zapisz ten certyfikat w postaci pliku.
    3. Zaimportuj do serwera podpisany certyfikat, który otrzymałeś e-mailem: 
            keytool -import -alias <cert-alias> -file 
         <signed-cert-file>