Gestiunea securitatii de Glassfish
1. Adaugarea de user-i pe server
 Pornim serverul din Eclipse sau din linia de comand



Pentru a putea porni, serverul are nevoie de porturile default 8080 si 4848
Lansam admin console-ul Glassfish-ului (http://localhost:4848/common/index.jsf)
Alegem Realms conform urmatoarei imagini

Selectam Realm-ul caruia ii adaugam user-ul
o file: pentru a adauga useri care dorim sa acceseze aplicatiile din acest realm
o admin-realm: pentru a adauga utilizatori ca system administratori ai serverului
o nu putem adauga utilizatori din admin console in certificate realm, pentru ca
acolo se pot adauga doar certificate (discutii in capitolele urmatoare)
Selectam file si Manage Users


Apoi new:
(pentru admin realms Group List e read only). Vom crea un user pe care il asignam unui GroupList,
spre exemplu ExampleGroup
Intr-o aplicatie web exista mai multe roluri fiecare avand anumite drepturi si implicit view-uri in
aplicatie. Asadar, rolurile de securitate reprezinta o grupare logica abstracta a userilor, ce este
definita de persoana care asambleaza aplicatia.
Componentelor JavaEE, rolurile de securitate le sunt definite folosind anotatiile @DeclareRoles si
@RollesAllowed. Iata un exemplu:
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.RolesAllowed;
...
@DeclareRoles({"DEPT-ADMIN", "DIRECTOR"})
@Stateless public class DeptBean {
@RolesAllowed("DEPT-ADMIN")
public void reviewEmployeeInfo(EmplInfo info) {
}
@RolesAllowed("DIRECTOR")
public void updateEmployeeInfo(EmplInfo info) {
}
...
}
Pentru un servlet se folosesc anotatiile @HTTPConstraint din @ServletSecurity pentru a
specifica rolurile ce permit accesul la servlet. Iata un exemplu:
@WebServlet(name = "PayrollServlet", urlPatterns = {"/payroll"})
@ServletSecurity(
@HttpConstraint(transportGuarantee = TransportGuarantee.CONFIDENTIAL,
rolesAllowed = {"DEPT-ADMIN", "DIRECTOR"}))
public class GreetingServlet extends HttpServlet {
}
Dupa ce utilizatorii au furnizat informatiile de login si aplicatia a declarat ce roluri sunt autorizate sa
acceseze partile protejate ale aplicatiei, pasul urmator este maparea rolurilor, utilizatorilor sau
principalului.
Ca dezvoltatori de aplicatie web nu e nevoie sa stim categoriile de utilizatori definite pentru realm-ul
in care aplicatia ruleaza. Platforma ruleaza un mecanism de mapare a rolurilor definite in aplicatie si
user-ii sau grupurile definite in runtime realm.
Numele rolurilor definite in aplicatie sunt de obicei aceleasi cu numele grupurilor definite in
Glassfish. Acest mod de lucru se poate modifica folosind descriptorul glassfish-web.xml si tagurile specifice:
<security-role-mapping>
<role-name>Admin</role-name>
<group-name>Director</group-name>
</security-role-mapping>
Stabilirea unei Conexiuni securizate folosind SSL – Secure Sockets Layer
SSL permite browse-relor web si serviciilor web sa comunice printr-o conexiune securizata. Astfel,
datele sunt incriptate inainte de trimitere si decriptate la receptionare si inainte de procesare.
-
-
Autentificarea: inainte de a comunica cu un server web printr-o conexiune securizata,
serverul va trimite browser-ului un set de credentiale sub forma unui certificat (numit si
certificat cu chei publice). Rolul acestuia este de a verifica ca site-ul este cine pretinde ca este
Confidentialitatea: in timpul trimiterii datelor datelor intre client si server, alte parti pot
vedea si intercepta date. Datele raman insa confidentiale datorita incriptarii
Integritate: asemanator confidentialitatii, SSL garanteaza ca datele nu pot fi modificate in
timpul comunicarii
Protololul SSL nu trebuie sa ruleze pentru toata aplicatia, dar este necesar ca developerul sa
stabileasca care pagini este necesar sa foloseasca o comunicare securizata. Comunicarea printr-o
conexiune securizata se face prin prefixarea adresei cu https.
Folosirea host-uri virtuale name-based, intr-o conexiune securizata, poate fi problematica. SSL
handshake, adica momentul in care browser-ul accepta certificatul de server, trebuie sa fie inainte ca
requestul HTTP sa fie accesat. Ca rezultat, informatiile din request ce contin numele virtual host-ului
nu pot fi determinate inainte de autentificare si de accea nu este posibil sa asignam mai multe
certificate unei singure adrese IP. Daca toate virtual host-urile unui single IP se autentifica pe acelasi
certificat, adaugarea mai multor virtual host-uri nu trebuie sa interfere cu operatiile SSL de pe server.
Recomandarea este ca doar address-based virtual hosts sa fie folosite cu SSL intr-un mediu de
productie.
Pasi pentru configurarea unei comunicari SSL pe server:
-
Trebuie sa existe un element Connector pentru un SSL connector in deploymentul
descriptorul serverului
Trebuie sa existe fisiere valide de keystore si certificate
Locatia fisierului keystore si parola trebuie sa fie specificate in DD
In Glassfish SSL HTTPS conectorul este enabled default. Testarea conexiunii SSL se face prin:
https://localhost:8181/