EJB 3.0 - Rozdział 17: Mechanizm bezpieczeństwa

Trochę minęło od mojego ostatniego relacjonowania lektury specyfikacji EJB3, jednakże wciąż się z nią zmagam. Przyszła w końcu pora na dwa, zwykle traktowane po macoszemu, tematy - bezpieczeństwo i transakcje. Zacznę od bezpieczeństwa, który ma swój rozdział 17: Mechanizm bezpieczeństwa w specyfikacji EJB3. Wiele ciekawego i w zasadzie streszczonego już w nim. Czasami trudno zdecydować się, co wyciąć, co nadmiarowe, bo już było wcześniej, itp. Przelewam moje tłumaczenie rozdziału z przekonaniem, że coś mi się jednak udało skrócić, wyrzucić i w ogóle uatrakcyjnić, co ostatecznie przyczyni się do lepszego zrozumienia tematu lub w ogóle do jego poznania. Nie ma przykładów, więc spragnieni ich powinni jeszcze uzbroić się w cierpliwość lub po prostu sami popróbować się z tematem. Miłej lektury!

Zacznijmy od uwspólnienia słownictwa (często doskwiera mi pewna rozbieżność podczas rozmów na ten i inne tematy, więc dobrze od tego zaczać):

• method permissions - prawo wykonania metody
• bean provider - Dostawca (ziarna)
• application assembler - Osoba Składająca/Składający aplikację (do rozważenia: Monter, Montażysta)
• deployer - Osoba Wdrażająca/Wdrażający
• identity - tożsamość (wyłącznie jako logiczny byt)
• principal - osobowość (wyłącznie w środowisku uruchomieniowym)
• principal realm - przestrzeń (królestwo) osobowości

Specyfikacja EJB3 zaleca, aby metody biznesowe nie zawierały żadnej logiki związanej z bezpieczeństwem. W ten sposób Wdrażający aplikację ma możliwość zdefiniowania polityki bezpieczeństwa w najbardziej korzystny dla środowiska uruchomieniowego sposób.

Bezpieczeństwo w EJB3 oparte jest o pojęcie ról bezpieczeństwa (ang. security roles), które są logicznym zbiorem uprawnień, które muszą posiadać użytkownicy korzystający z aplikacji. Dostawca ziarna deklaratywnie określa prawo wykonania metody dla każdej z ról korzystajac z adnotacji bądź deskryptora wdrożenia. Składający aplikację ma możliwość zmiany konfiguracji wyłącznie za pomocą deskryptora wdrożenia. Prawo wykonania metody (ang. method permission) jest prawem do wykonania określonej metody bądź grupy metod ziarna zdefiniowanych w interfejsie biznesowym, domowym, komponentu i/lub usługi sieciowej. Role upraszczają spojrzenie na bezpieczeństwo aplikacji korzystajacej z EJB3 dla osoby wdrażającej aplikacje w serwerze aplikacyjnym do niezbędnego minimum bez konieczności poznawania ich przez pryzmat kodu źródłowego czy dodatkowych dokumentacji.

Osobowością (ang. security principal), który wykonuje dana metode jest wywołujący ziarno. Za pomocą tożsamości określanej przez run-as można to zmienić. Sprawdzenie aktualnej tożsamości wykonującego metodę ziarna możliwe jest za pomocą metody javax.ejb.EJBContext.getCallerPrincipal().

Dostawca ziarna ma możliwość określenia tożsamości wykonującego za pomocą adnotacji lub deskryptora wdrożenia.

• Domyślnie tożsamość wykonującego metodę ziarna odpowiada tożsamości wywołującego. Za pomocą adnotacji @RunAs lub elementu run-as dostawca ziarna określa jego (tymczasowy) zamiennik.
• Skorzystanie z deskryptora wdrożenia umożliwia Dostawcy lub Składającemu określenie tożsamości wykonującego za pomocą elementu security-identity. Brak elementu security-identity lub adnotacji @RunAs/elementu run-as implikuje security-identity jako use-caller-identity, tożsamość wykonującego metodę ziarna jest tożsamościa wywołującego. Użycie elementu run-as definiuje bieżąca tożsamość wykonującego ziarno. Składający ma prawo zmienić tożsamość wykonującego ustanowioną przez Dostawcę.
• Wdrażający odpowiada za przypisanie osobowości i ich grup, które są zdefiniowane w środowisku uruchomieniowym do ról zdefiniowanych przez Dostawcę lub Składającego. Wdrażający jest odpowiedzialny za przypisanie osobowości do ról okreslonych przez run-as. Dodatkowo w jego obowiązkach leży konfiguracja innych aspektów bezpieczeństwa związanego z ziarnami, jak odwzorowanie (mapowanie) osobowości w komunikacji miedzy ziarnami oraz dostępu do zasobów.

Podczas uruchomienia aplikacji, klient ma prawo wykonać metodę ziarna, jeśli osobowość związana z wywołaniem ziarna została przypisana przez Wdrażającego do przynajmniej jednej roli uprawnionej do wykonania metody lub jeśli Dostawca lub Składający określiły, że sprawdzenie bezpieczeństwa nie jest wykonywane dla tej metody, tj. wszystkie role mają prawo wykonania metody.

Dostawca kontenera (producent) odpowiada za zagwarantowanie, że polityka bezpieczeństwa jest przestrzegana udostepniając narzędzia do zarządzania bezpieczeństwem podczas pracy kontenera i udostępniając narzędzia wspomagające pracę Wdrażającego do zarządzania bezpieczeństwem podczas wdrożenia.

Ze względu na fakt, że nie wszystkie polityki bezpieczeństwa da sie wyrazić deklaratywnie (za pomocą adnotacji lub deskryptora wdrożenia), specyfikacja EJB udostępnia interfejs programistyczny, który dostawca ziarna może wykorzystać do dostępu do kontekstu bezpieczeństwa z poziomu metody biznesowej.

I w zasadzie to wystarczyłoby do spojrzenia na możliwości związane z bezpieczeństwem w EJB3. Dalsze strony specyfikacji dotyczą już rozwinięciu tematu - przekazywaniu tożsamości wykonującego, mapowanie ról i referencji, adnotacje i deskryptor wdrożenia, itp.

Interfejs programistyczny javax.ejb.EJBContext

Specyfikacja EJB nie udostepnia interfejsu programistycznego, który wspierałby kontrolę tożsamości wywołującego, która jest przekazywana do wywoływanego ziarna przez ich interfejs biznesowy, domowy lub komponentu.

Zarządzanie osobowościami wywołującego przekazywanymi w komunikacji między ziarnami (delegacja osobowości) jest konfigurowana przez Wdrażającego lub Administratora serwera w specyficzny dla kontenera EJB (serwera aplikacji) sposób. Dostawca i/lub Składający powinni opisać wszystkie wymagania związane z tego typu wywołaniami jako część opisu ziarna (opcjonalne pole description).

Specyfikacja EJB nie definiuje osobowości w systemie operacyjnym, z którym wywoływana jest metoda. Z tego powodu, Dostawca nie może polegać na specyficznej osobowości, z którą będzie następował dostęp do zasobów systemu operacyjnego, np. plików.

Dostawca korzysta z adnotacji lub deskryptora wdrożenia celem określenia wymagań bezpieczeństwa aplikacji. W ten sposób Wdrażający ma możliwość zdefiniowania poprawnej polityki bezpieczeństwa.

Zarządzanie bezpieczeństwem powinno być w gestii kontenera EJB i powinno być przeźroczyste dla metod biznesowych ziarna. Udostępniony interfejs programistyczny powinien być stosowany wyłącznie w wyjątkowych sytuacjach.

Interfejs javax.ejb.EJBContext udostępnia dwie metody (oraz dwie niezalecane do użycia metody z EJB 1.0), które pozwalają Dostawcy na dostęp do kontekstu bezpieczeństwa i pozyskanie informacji o tożsamości wywołującego ziarno.

Dostawca wykonuje getCallerPrincipal() oraz isCallerInRole(String roleName) jedynie w metodach biznesowych (warto zapoznać się z tabelą uprawnień w specyfikacji EJB3 w tabeli 10 Operations Allowed in the Methods of an Entity Bean (strona 269). Każdorazowe wykonanie ich poza określonymi miejscami powoduje wystąpienie wyjątku java.lang.IllegalStateException.

Metody getCallerIdentity() oraz isCallerInRole(Identity role) są pozostałością (reliktami) czasów EJB 1.0 i nie zaleca sie ich wykorzystania. Dostawca musi używać wspomniane wcześniej metody getCallerPrincipal() oraz isCallerInRole(String roleName). Kontener ma prawo dostarczyć implementacje metod z EJB 1.0, które zawsze zgłaszają wyjątek java.lang.RuntimeException.

Celem metody getCallerPrincipal() jest pozyskanie informacji o bieżącej tożsamości wykonującego metodę biznesową. Na ich podstawie metody mogą przykładowo pozyskiwać dodatkowe informacje z bazy danych traktując tożsamość jako klucz do danych.

Metoda getCallerPrincipal() zwraca tożsamość wykonującego metodę jako egzemplarz java.security.Principal. Jeśli nie przypisano praw wykonania metody, metoda zwróci reprezentację kontenera odpowiadającą domyślnej tożsamości nieuwierzytelnionej.

Metoda getCallerPrincipal() zwraca tożsamość, która reprezentuje wywołującego ziarno, a nie tożsamość określoną przez run-as (jeśli zdefiniowano).

Głównym celem isCallerInRole(String roleName) jest udostępnienie dostawcy ziarna możliwości przeprowadzenia kontroli wykonania, która nie może być wyrażona deklaratywnie w deskryptorze wdrożenia za pomocą prawa wykonania metody.

Metoda biznesowa ziarna może użyć isCallerInRole(String roleName) do sprawdzenia, czy bieżąca tożsamość wywołującego metodę ziarna posiada daną rolę bezpieczeństwa. Role bezpieczeństwa są zdefiniowane przez Dostawcę lub Składającego i są przypisywane do właściwych osobowości i ich grup w środowisku uruchomieniowym przez Wdrażającego.

isCallerInRole(String roleName) sprawdza osobowość reprezentującego faktycznie wywołującego ziarno, a nie osobowość, która odpowiada tożsamości z run-as dla ziarna (jeśli określono).

Dostawca jest zobowiązany zadeklarować wykorzystywane nazwy ról w kodzie ziarna za pomocą adnotacji @DeclareRoles lub security-role-ref w deskryptorze wdrożenia. Adnotacja @DeclareRoles jest umieszczana na poziomie klasy ziarna i określa nazwy ról, które są wykorzystywane w ziarnie jako parametry wejściowe do metody isCallerInRole(String roleName). Deklaracja nazw ról pozwala Dostawcy, Składającemu lub Wdrażającemu związać je z rolami zdefiniowanymi w aplikacji. W przypadku braku deklaracji za pomocą adnotacji lub deskryptora zakłada się, że wykorzystywane nazwy ról odpowiadają rolom w aplikacji.

Dostawca deklaruje role wykorzystywane w kodzie ziarna korzystając z adnotacji @DeclareRoles. Nazwa roli musi odpowiadać tej wykorzystywanej jako parametr wejściowy dla isCallerInRole(String roleName). Dostawca ziarna może opisać rolę poprzez opcjonalny element description adnotacji @DeclareRoles.

Jeśli @DeclareRoles nie jest w użyciu, dostawca ziarna musi użyc security-role-ref w deskryptorze, aby zadeklarować role wykorzystywane w kodzie ziarna.

Elementy security-role-ref:

• role-name - nazwa roli jaką podano w parametrze metody isCallerInRole(String roleName)
• description - opcjonalny element do opisu roli

security-role-ref, włączajac nazwę zdefiniowana przez referencję, jest ograniczone do ziarna, które zawiera adnotację @DeclareRoles lub którego deskryptor wdrożenia zawiera element security-role-ref.

Dostawca lub Składający mogą również użyć security-role-ref dla tych referencji ról, które zostały zadeklarowane w adnotacjach, a które dostawca ziarna chciałby związać z security-role, której nazwa różni się od zaproponowanej. Jeśli referencja roli nie jest powiązana do roli w ten sposób, kontener EJB musi związać nazwę referencji do roli o tej samej nazwie.

17.3 Obowiązki Dostawcy oraz Składającego (w kontekście bezpieczeństwa)

Dostawca lub Składający mogą zdefiniować opcjonalny "widok bezpieczeństwa" ziaren w ramach deskryptora wdrożenia.

Głównym powodem utworzenia "widoku bezpieczeństwa" jest uproszczenie zadania Wdrażającemu. W przeciwnym przypadku musiałby istnieć inny sposób deklarowania/określania wymagań przez Dostawcę i Składającego dla Wdrażającego. Za pomocą "widoku" Wdrażający może wykonać swoje zadanie zabezpieczenia aplikacji bez konieczności poznawania innych mechanizmów czy zapoznawania sie z innymi materiałami związanymi z aplikacją, a jedynie poznać skonsolidowany widok wszystkich wymagań bezpieczeństwa aplikacji w deskryptorze wdrożenia.

"Widok bezpieczeństwa" składa się z ról bezpieczeństwa. Rola jest zbiorem uprawnień, które nadawane sa użytkownikowi, aby mógł on poprawnie korzystać z aplikacji.

Dostawca lub Składający określa uprawnienia metod dla każdej z roli. Uprawnienie metody jest uprawnieniem, aby wykonać określoną grupę metod ziarna.

"Widok bezpieczeństwa" jest jedynie logicznym spojrzeniem na wymagania bezpieczeństwa aplikacji i nie powinno być mylone z ich odpowiednikami w środowisku uruchomieniowym jakim jest serwer aplikacyjny - użytkownik, grupa użytkowników, osobowości.

Dostawca lub Składający (opcjonalnie) definiuje jedną lub więcej ról bezpieczeństwa za pomocą adnotacji lub deskryptora. Dostawca lub Składający przypisują metody (biznesowe, domowe, komponentu i usługi sieciowej) do ról, aby zdefiniować "widok bezpieczeństwa". Brak "widoku bezpieczeństwa" jest określeniem braku specyficznych wymagań związanych z bezpieczeństwem aplikacji dla Wdrażającego.

Ze względu na (możliwą) nieznajomość środowiska uruchomieniowego (serwera aplikacyjnego), role bezpieczeństwa są jedynie logicznymi bytami (aktorami), każdy reprezentujący typ użytkownika, który powinien mieć określone uprawnienia.

Wdrażający przypisuje (mapuje) grupy i pojedyńczych użytkowników ze środowiska uruchomieniowego do ról bezpieczeństwa zdefiniowanych przez Dostawcę lub Składającego.

W przypadku stosowania adnotacji, dostawca ziarna używa @DeclareRoles i @RolesAllowed w celu zdefiniowania ról bezpieczeństwa. Zbiór ról bezpieczeństwa używanych przez aplikację jest zbiorem ról bezpieczeństwa zdefiniowanych przez adnotacje @DeclareRoles i @RolesAllowed. Dostawca ziarna moze zmodyfikować zbiór ról bezpieczeństwa przez element deskryptora wdrożenia - security-role.

W przypadku zastosowania deskryptora, Dostawca lub Składający używa elementu security-role w następujący sposób:

• Definiuje rolę bezpieczeństwa za pomocą elementu security-role
• Opcjonalnie, opisuje rolę w elemencie description
• Wykorzystuje role-name, aby zdefiniować nazwę roli

Wszystko w ramach elementu assembly-descriptor w deskryptorze.

Poza zdefiniowaniem ról bezpieczeństwa przez Dostawcę lub Składającego, moga oni również określić metody interfejsów biznesowego, domowego i komponentu oraz usług sieciowych, które mogą zostać wykonane przez daną rolę. W tym celu stosują adnotacje lub deskryptor wdrożenia.

Prawo wykonania metod może zostać określone za pomocą adnotacji na poziomie klasy, metody biznesowej lub obu. W tym celu korzysta się z adnotacji @RolesAllowed, @PermitAll oraz @DenyAll.

Wartością @RolesAllowed jest lista (logicznych) nazw ról bezpieczeństwa uprawnionych do wykonania danej metody. Adnotacja @PermitAll określa, że wszystkie role są uprawnione do wykonania metody, podczas gdy @DenyAll jest jej przeciwieństwem (żadna z ról bezpieczeństwa nie ma prawa wykonania wybranej metody).

Określenie @RolesAllowed oraz @PermitAll na poziomie klasy dotyczy wszystkich metod biznesowych ziarna.

Prawo wykonania metody określone na poziomie metody nadpisuje prawa określone na poziomie klasy.

Jesli klasa ziarna ma nadklasy, następujące reguły zachodza:

• Prawo wykonania określone dla nadklasy S dotyczy metod biznesowych klasy S
• Prawo wykonania może zostać określone dla metody biznesowej M zdefiniowanej przez klasę S, co przesłoni uprawnienia zdefiniowane dla tej metody wprost bądź niewprost przez klasę S.
• Jeśli metoda M klasy S przesłania metodę biznesowa zdefiniowaną przez nadklasę S, prawa wykonania dla M są wyznaczone przez reguły opisane powyżej jakby dotyczyły klasy S.

Dostawca może użyć deskryptora wdrożenia jako alternatywę dla adnotacji lub jako sposób uzupełnienia/nadpisania praw z adnotacji. Składający ma prawo nadpisania praw za pomocą deskryptora.

Prawa określone w deskryptorze nadpisują odpowiadajace im prawa z adnotacji. Brak określenia praw w deskryptorze, oznacza uprawomocnienie praw z adnotacji. Ziarnistość reguł nadpisywania jest do poziomu metod.

Dostawca lub Składający definiują prawa metod w deskryptorze za pomocą elementu method-permission.

• Każdy element method-permission składa się z listy ról bezpieczeństwa i uprawnionych do wykonania metod. Wymienione role mają prawo wykonać wszystkie z wymienionych metod. Każda z ról określona jest przez element role-name, a każda metoda (zbiór metod) jest identyfikowana przez element method. Opcjonalnie możemy opisać method-permission poprzez element description.
• Relacja praw wykonania metod jest zdefiniowana jako złożenie wszystkich uprawnień wykonania zdefiniowanych w poszczególnych elementach method-permission.
• Wybrana rola bezpieczeństwa lub metoda mogą wystąpić w wielu elementach method-permission.

Dostawca lub Składający mogą wskazać, że wszystkie role są uprawnione do wykonania pojedyńczej lub wielu określonych metod, tj. dostęp do metod nie powinien wiązać się z uwierzytelnieniem przed wykonaniem przez kontener. Element unchecked podany zamiast nazwy roli w elemencie method-permission wskazuje, że wszystkie role są dozwolone.

Jeśli prawo wykonania dla danej metody określono jako unchecked oraz jednocześnie związano z rolą, wszystkie role są uprawnione do wykonania metody.

Element exclude-list może być użyty, aby określić listę metod, które nie powinny być wywołane. Wdrażający powinien tak skonfigurować bezpieczeństwo ziarna, aby żaden dostęp nie był dozwolony do metod zawartych na liście exclude-list.

Jeśli podana metoda znajduje się w exclude-list oraz występuje w innym opisie prawa wykonania, Wdrażający powinien tak skonfigurować bezpieczeństwo ziarna, że żadne wykonanie metody nie będzie dozwolone.

Element method zawiera elementy ejb-name, method-name oraz method-params w celu opisania metod ziarna. Istnieją trzy sposoby opisu metody przez element method:

• ejb-name określony z method-name=* - dotyczy wszystkich metod ziarna
• ejb-name określony z method-name=<nazwa metody> - dotyczy wszystkich metod ziarna o podanej nazwie bez względu na liczbę parametrów
• ejb-name określony, method-name=<nazwa metody> z method-params - określona metoda o zadanej nazwie i liczbie parametrów

Opcjonalny element method-intf wskazuje na metodę z zadaną sygnaturą, jednakże określoną przez wybrany interfejs biznesowy, domowy, komponentu i usługi sieciowej.

Może się zdarzyć, że role bezpieczeństwa nie zostały przypisane do wybranej metody ani nie określono dla niej @DenyAll czy nie zawarto jej w liście exclude-list. W takim przypadku, Wdrażający powinien przypisać wszystkie nieprzypisane metody do pewnej roli lub po prostu oznaczając je jako unchecked. Brak przypisania uprawnienia do wybranej metody powoduje, że ich wykonanie jest unchecked.

Referencje ról bezpieczeństwa używane w komponentach aplikacji są wiązane z rolami bezpieczeństwa zdefiniowanych dla całej aplikacji. Przy braku jakiegokolwiek jawnego wiązania, referencje ról bezpieczeństwa będą związane z rolami bezpieczeństwa o tej samej nazwie.

Składający może jawnie określić wiązanie wszystkich referencji ról bezpieczeństwa zadeklarowanych przez @DeclareRoles lub element security-role-ref dla komponentu do ról bezpieczeństwa zdefiniowanych przez adnotacje i/lub w elementach security-role.

Składający wiąże każdą referencję roli bezpieczeństwa do roli bezpieczeństwa korzystając z elementu role-link. Wartością role-link musi być nazwa jednej z ról bezpieczeństwa zdefiniowanej w elemencie security-role lub za pomocą adnotacji @DeclareRoles lub @RolesAllowed, jednakże nie potrzebuje być określona, kiedy role-name używane w kodzie jest takie samo jak security-role (które ma zostać związane).

Dostawca lub Składający zazwyczaj określają czy tożsamość wywołującego powinna być użyta jako bieżąca podczas wywoływania metod ziarna lub czy w zamian nie powinna być podmieniana na określoną tożsamość zdefiniowaną przez run-as.

Domyślnie, tożsamość wywołującego jest przekazywana do ziarna. Dostawca może użyć adnotacji @RunAs, aby określić tożsamość run-as dla wykonania metod ziarna. Zdefiniowanie tożsamości wykonującego przez element security-identity w deskryptorze wdrożenia nadpisuje tożsamość wykonującego bądź tą określoną przez adnotację @RunAs. Wartością elementu security-identity jest use-caller-identity lub run-as.

Dostawca może użyć adnotacji @RunAs lub dostawca ziarna oraz Składający aplikację mogą użyć elementu run-as w deskryptorze wdrożenia celem przypisania tożsamości run-as dla wywoływania metod ziarna. Tożsamość run-as dotyczy ziarna EJB w całości, tj. wszystkie metody interfejsu biznesowego, domowego, komponentu oraz usługi sieciowej oraz metoda obsługi komunikatów ziarna MDB, metoda zwrotna timeout i wszystkich wewnętrznych metod ziarna, które mogą z kolei zostać wywołane przez nie.

Określenie tożsamości run-as nie zmienia tożsamości wywołującego, które są sprawdzane celem zweryfikowania prawa wykonania, a jedynie przesłania ją (ustanawia jako tymczasową tożsamość bieżącą), która będzie następnie bieżącą podczas pracy ziarna.

Nazwa określona przez dostawcę i składającego jako tożsamość run-as jest logiczną nazwą roli bezpieczeństwa i odpowiada roli bezpieczeństwa zdefiniowaną przez dostawcę i składającego w adnotacjach bezpieczeństwa lub deskryptorze wdrożenia.

Wdrażający przypisuje osobowość bezpieczeństwa określoną w środowisku wykonawczym, która będzie wykorzystywana jako odpowiednik logicznej tożsamości run-as. Osobowość przypisana przez wdrażającego będzie odpowiadała roli bezpieczeństwa określoną przez adnotację @RunAs lub przez element role-name w elemencie run-as w deskryptorze.

Dostawca i składający odpowiedzialni są za następujące zadania podczas określania tożsamości run-as:

• Użycie adnotacji @RunAs lub elementu role-name w deskryptorze, aby określić nazwę roli bezpieczeństwa
• Opcjonalnie, w elemencie description, opisać wymaganie stawiane roli, która powinna być przypisana do tożsamości run-as ze względu na jej uprawnienia

17.4 Obowiązki Wdrażającego

Wdrażający odpowiada za zapewnienie, że aplikacja działa w środowisku gwarantującym jej bezpieczne użytkowanie po wdrożeniu w docelowym środowisku uruchomieniowym.

Wdrażający korzysta z narzędzi dostarczanych przez środowisko uruchomieniowe (serwer aplikacyjny) do odczytania "widoku bezpieczeństwa" aplikacji dostarczonej przez Dostawcę i Składającego. "Widok" oparty jest o informacje zapisane w adnotacjach i deskryptorze. Zadaniem Wdrażającego jest odzwierciedlenie "widoku bezpieczeństwa" na odpowiednie mechanizmy i polityki bezpieczeństwa używane przez docelowe środowisko uruchomieniowe. Wynikiem prac Wdrażającego jest deskryptor z polityką bezpieczeństwa aplikacji, która jest specyficzna dla środowiska uruchomieniowego. Format i zawartość deskryptora jest specyficzny dla środowiska uruchomieniowego.

Wdrażający przypisuje osobowości i/lub grup osobowości (pojedyńczy użytkownicy i grupy) określone w środowisku wykonawczym do ról bezpieczeństwa zdefiniowanych za pomocą adnotacji @DeclaredRoles i @RolesAllowed oraz elementów security-role w deskryptorze wdrożenia.

Wdrażający nie przypisuje osobowości i/lub grup osobowości do referencji ról bezpieczeństwa - osobowości i ich grupy przypisane do ról bezpieczeństwa dotyczą również wszystkich przypisanych referencji ról bezpieczeństwa.

Proces przypisywania logicznych nazw ról bezpieczeństwa zdefiniowanych w deskryptorze lub adnotacjach jest specyficzny dla środowiska uruchomieniowego. Zazwyczaj wdrażanie aplikacji polega na przypisaniu ról bezpieczeństwa do grup użytkowników (osobowości) dostępnych w środowisku uruchomieniowym. Przypisanie jest wykonywne per aplikacja. Te same nazwy ról bezpieczeństwa w różnych aplikacjach korporacyjnych mogą być przypisane inaczej. Jeśli logiczna nazwa roli nie zostanie przypisana do odpowiadających bytów w środowisku uruchomieniowym, zakłada się, że logiczna nazwa roli odpowiada osobowości lub grupie osobowości o tej samej nazwie w środowisku uruchomieniowym.

Wdrażający zobowiązany jest do konfiguracji delegacji uprawnień osobowości wykorzystywanej do komunikacji między elementami aplikacji. Wdrażający musi przestrzegać zasad opisanych przez Dostawcę lub Składającego w opcjonalnym elemencie description adnotacji @RunAs lub elemencie run-as w deskryptorze.

Jeśli tożsamość bezpieczeństwa jest domyślna, lub jest wymieniona expicite, że tożsamość wywołującego będzie w użyciu, np. poprzez użycie use-caller-identity w deskryptorze, osobowość wywołującego jest przekazana z jednego elementu aplikacji do wywoływanego. Podobnie jest z określeniem tożsamości run-as, która będzie przekazywana podczas wywołań i musi skonfigurować jej osobowość.

17.5 Wymagania stawiane klientowi EJB

Klient transakcyjny nie może zmienić swojej tożsamości w ramach transakcji. Dzięki temu zapewniono, że wszystkie wywołania od klienta w ramach pojedyńczej transakcji są wykonywane pod auspicjami tego samego kontekstu bezpieczeństwa.

Klient ziarna sesyjnego nie może zmienić swojej tożsamości podczas trwania komunikacji z obiektem sesyjnym. Dzięki temu zapewnia się, że serwer może przypisać tożsamość z instancją ziarna podczas jego tworzenia i nie zmieniać jej przez cały czas jej istnienia.

Jeśli żądania transakcyjne nadejdą od wielu klientów w ramach pojedyńczej transakcji, wszystkie żądania muszą być wykonane pod auspicjami tej samej tożsamości.

17.6.5. Metody dotyczące bezpieczeństwa w javax.ejb.EJBContext

Kontener EJB musi udostępniać do informacji o kontekście bezpieczeństwa wywołującego z egzemplarzy ziaren przez metody getCallerPrincipal() oraz isCallerInRole(String rolename). Kontener musi zapewnić, że wywołanie metod biznesowych, domowych, komponentu, usługi sieciowej, metody obsługi komunikatów lub metod TimedObject są związane z pewną osobowością. Jeśli nie określono tożsamości wywołującego, kontener zobowiązany jest przypisać wywołanie do własnej reprezentacji tożsamości nieuwierzytelnionej. Kontener nie może w żadnym momencie zwrócić null z wywołania metody getCallerPrincipal().

Kontener EJB umożliwia wykonanie metody wtw jeśli metoda określona jest jako @PermitAll lub tożsamość wywołującego przypisana jest do co najmniej jednej z roli, która związana jest z prawem wykonania dla tej metody. Wystarczy, że tożsamość wywołującego przypisana jest do przynajmniej jednej roli. Jeśli kontener zabroni wykonania metody zostanie zgłoszony wyjątek javax.ejb.EJBAccessException. W przypadku użycia interfejsu EJB 2.1, kontener zgłosi java.rmi.RemoteException lub jego podklasę java.rmi.AccessException dla klientów zdalnych, a javax.ejb.EJBException lub podklasę javax.ejb.AccessLocalException dla klientów lokalnych.