Czas posmęcić o informatyce...
Kontenery referencyjnego serwera aplikacji Java EE udostępniają trzy mechanizmy bezpieczeństwa dla komponentów aplikacji odpowiedzialnych za uwierzytelnianie użytkowników i autoryzację dostępu do zasobów i funkcjonalności.
Kontenery referencyjnego serwera aplikacji Java EE udostępniają trzy mechanizmy bezpieczeństwa dla komponentów aplikacji odpowiedzialnych za uwierzytelnianie użytkowników i autoryzację dostępu do zasobów i funkcjonalności.
- mechanizm deklaratywny - kluczowym elementem mechanizmu jest deskryptor wdrożenia, w którym w sposób deklaratywny zapisane są wymagania dotyczące prawidłowego wdrożenia i wykorzystania mechanizmu bezpieczeństwa. Deskryptor pełni tu rolę kontraktu. Wyróżniamy dwa poziomy, na których może być wykorzystany deklaratywny mechanizm bezpieczeństwa:
· Poziom aplikacji (ang. Application Level Security) – na poziomie aplikacji, role wykorzystywane w aplikacji muszą być zdefiniowane za pomocą adnotacji DeclareRoles, RolesAllowed lub w elementach w pliku deskryptora wdrożenia aplikacji. Mapowanie roli na zarządców definiuje się w elemencie , dla wszystkich ról wykorzystywanych w systemie. Zdefiniowane role dotyczą wszystkich komponentów aplikacji. Pozwala to na pewnego rodzaju generalizację ról w aplikacji. Jeśli w deskryptorze wdrożenia konkretnego komponentu aplikacji zdefiniowano role, to komponent ten poza tymi rolami, może również korzystać z ról zdefiniowanych na poziomie aplikacji.
· Poziom komponentu (ang. Component Level Security) – Dotyczy konkretnego komponentu aplikacji. W przypadku komponentów webowych może to być na przykład serwelet. Wówczas nazwy ról powinny być zdefiniowanie w deskryptorze wdrożenia serwletu – web.xml.
- Mechanizm programowalny – programowalny mechanizm bezpieczeństwa, wykorzystywany jest, gdy deklaratywny mechanizm jest niewystarczający do spełnienia wymagania modelu aplikacji. Mechanizm ten dotyczy komponentów EJB oraz serwletów i opiera na wykorzystaniu metod interfejsu EJBContext dla komponentów EJB oraz interfejsu HttpServletRequest dla serwletu. Metody te zostały wymienione poniżej:
· isCallerInRole (EJBContext),
· getCallerPrincipal (EJBContext),
· isUserInRole (HttpServletRequest),
· getUserPrincipal (HttpServletRequest),
· getUserRemote (HttpServletRequest).
Jeżeli serwlet jest tylko jednym z komponentów aplikacji i dla niego zostały zdefiniowanie role to mogą one posłużyć do określenia pozwoleń dla ról w innych komponentach aplikacji. Sytuacja taka może wystąpić, jeśli cześć funkcjonalności serwletu wykorzystuje kod innych komponentów aplikacji. Za pomocą deskryptora wdrożenia można obsłużyć taka ewentualność i przekazać pozwolenia roli określonej w serwlecie do roli zdefiniowanej w całej aplikacji. Rozwiązanie takie jest możliwe poprzez wykorzystanie elementu, będącego podelementem <>.
· isCallerInRole (EJBContext),
· getCallerPrincipal (EJBContext),
· isUserInRole (HttpServletRequest),
· getUserPrincipal (HttpServletRequest),
· getUserRemote (HttpServletRequest).
Metoda getUserInRole pozwala na uzyskanie informacji o roli, jaką posiada użytkownik, metoda getUserPrincipal zwraca obiekty klasy Principal z pakietu java.security.Principal, natomiast metoda getUserRemote zwraca nazwę użytkownika, który ma zostać uwierzytelniony. Wymieniony zestaw metod pozwala na podejmowanie biznesowych decyzji w oparciu o logiczną rolę użytkownika.
Przykładem wykorzystania mechanizmu programowalnego może być sytuacja w której aplikacja dokonuje autoryzacji w oparciu o parametry środowiskowe lub parametry wywołania komponentu webowego. Na listingu przedstawiony został szkielet kodu serwletu wykorzystujący metody getUserPrincipal i getName.
public void doGet(HttpServletRequest request, HttpServletResponse response) {
String userName;
... //inny kod
//Uzyskanie obiektu obiektu nadzorcy z żądania HTTP
Principal principal = request.getUserPrincipal();
if (principal != null) {
//Uzuskanie nazwy nadzorcy
userName = principal.getName();
}
... //inny kod
}
Listing: Szkielet kodu wykorzystanie metody getUserPrincipal i getName w serwlecie.
Jeżeli serwlet jest tylko jednym z komponentów aplikacji i dla niego zostały zdefiniowanie role to mogą one posłużyć do określenia pozwoleń dla ról w innych komponentach aplikacji. Sytuacja taka może wystąpić, jeśli cześć funkcjonalności serwletu wykorzystuje kod innych komponentów aplikacji. Za pomocą deskryptora wdrożenia można obsłużyć taka ewentualność i przekazać pozwolenia roli określonej w serwlecie do roli zdefiniowanej w całej aplikacji. Rozwiązanie takie jest możliwe poprzez wykorzystanie elementu
<security-role-ref>
<role-name>role_A</role-name>
<role-link>role_B</role-link>
</security-role-ref>
Listing: Konfiguracja w deskryptorze wdrożenia.
public void doGet(HttpServletRequest request, HttpServletResponse response) {
... //inny kod
//Uzyskanie obiektu obiektu nadzorcy z żądania
if (request.isUserInRole("role_A")) {
//przekierowanie do strony roli "role_B"
} else {
//przekierowanie do strony błędu autoryzacji
}
... //inny kod
}
Listing: Szkielet kodu serwletu ilustrujący sytuację, gdzie konieczne jest przekazanie pozwoleń przyznanej roli zdefiniowanej w jednym komponencie, do roli zdefiniowanej w innym komponencie.
- Mechanizm oparty o adnotacje (ang. annotations) – Adnotacje są metadanymi, pozwalającymi na podanie pewnych parametrów konfiguracyjnych dla kodu w języku Java. Wykorzystywane są do deklarowania zależności wykonania kodu od kontekstu i konfiguracji, w jakiej ma zostać wykonany. Zgodnie ze specyfikacją Java EE, adnotacje dla komponentów webowych zostały dołączone do specyfikacji serwletów. Dla komponentów webowych dostępne są adnotacje:
· @DeclareRole,
· @RunAs.
Adnotacja @DeclareRole jest alternatywą dla elementu
@DeclareRole("Admin")
public class nazwa_klasy {
...
}
To tyle tytułem wprowadzenia do pojęcia bezpieczeństwa w standardzie Java EE. Następny post w tym temacie będzie o uwierzytelnianiu klientów webowych.
Brak komentarzy:
Prześlij komentarz