czwartek, 5 czerwca 2014

introduce to spring security

Zabezpieczenia aplikacji.... Temat rzeka, problemy, decyzje projektowe, frameworki, rozwiązania.

Istnieje wiele różnych sposobów aby zabezpieczyć dobrze aplikację czy to aplikację Web opartą na URL'elach czy desktopową czy inną dowolnej maści.
Standard korporacyjny dostarcza nam dwa rozwiązania JAAS z J2EE oraz Spring Security ze Spring Enterprise.
Istnieją też inne możliwości jak open source Apache Shiro etc. Wybór należy do Ciebie, w każdym razie warto poczytać sobie o tych rozwiązaniach oraz sposobach ataku i obrony (OWASP) aby mieć lepszy przegląd sytuacji i dokonać trafnego wyboru. Ale tak czy inaczej w 90% będą to rozwiązania oparte na Spring Security.


Jego wszechestronność i dojrzałość plasują dają mu w tym momencie niekwestionowaną pozycję lidera.

Wstęp teoretyczny:

Mamy kilka sposób uwierzytelniania : 
basic authentication - serwer podaje nam formularz logowania z polami login + password. Nie musimy tworzyć strony logowania.
-Form-based authentication - uwierzytelnianie oparte na formularzu użytkownika
- Digest-based authentication - dane użytkownika są zahashowane stosownym algorytmem
- Certificate-based authentication - klient i serwer określają swoją tożsamość w oparciu o wygenerowany certyfikat. Komunikacja na łączu następuje w sposób szyfrowany po przez  SSL.



Historia :
2003 - Acegi Security - początek sagi
2008 - Acegi wchłonięte przez Spring - początek Spring Security


Spring Security to :
  - wszechstronność metod autoryzacji i autentykacji
  - zabezpieczenie przez atakami  (OWASP top ten)
  - integracja ze Spring MVC i Servlet API 3 i 3.1
  - w wersji 3.2 wsparcie dla javaConfig
  - zabezpiecznie przed CRFS, session fixation, clickjacking
  - przenośność rozwiązania
  - dojrzałość
  - pewność
  - integracja z różnymi protokołami i rozwiązaniami jak :
     - openID
     - OAuth
     - LDAP
     - SSO (CAS)
     -  RMI , HttpInvoker
     - JAAS
     - Kerberos
     - HTTP X.509
     - i wiele innych

najprostsza konfiguracja (maven) :
W gradle jeszcze prościej :


Teraz skład Spring Security : 
 - Core spring-security-core -> auth i access-control, remoting support etc
   - ogólnie jak to 'core' jest niezbędny do działania czegokolwiek w spring security framework. Zapewnia zabezpiecznie dla aplikacji standalone, zdalnych klientów, i metod biznesowych czy JDBC oraz obsługę kryptografii (Crypto)

 - WEB  spring-security-web - zawiera filtry, które możemy modelować w łańcuch  (Chain of responsiblity pattern) oraz integracje z Servlet API i URL-based access-control

- Config spring-security-config - zawiera Xml namespace dla wygodnej konfiguracji z poziomu XML znanej ze Springa oraz JavaConfig support

- LDAP - spring-security-ldap - autoryzacja oparta na protokole LDAP

- ACL - spring-security-acl - autoryzacja oparta na poziomie dostępu do obiektów domenowych. Znamy takie podejście z systemów Linux czyli kto i w jakim stopniu ma dostęp do zasobu.

- CAS - spring-security-cas - integracje z systemami SSO.

- OpenID - spring-security-openid - wsparcie dla protokołu openID. Autoryzacja użytkownika po przez zewnętrzne serwery OpenID np Google.

Wstęp do konfiguracji.
Spring Security jeśli chodzi o zabezpieczenie warstwy Web to tak naprawdę zbiór filtrów połączonych w łańcuch. Wszystko zostało stworzone tak aby zapewnić jak największą elastyczność rozwiązania a co za tym idzię konfigurowalność i moim zdaniem to jest największa siła SpringSecurity.

1. Dodaj zależność Spring Security do projektu
   - podstawa to : spring-security-core i w przypadku projektu Web spring-security-web oraz dla Twojej wygody spring-security-config.
Jeśli używasz JSP pewnie przyda Ci się spring-taglibs - dostajesz tagi dzięki,  którym Twój widok wygląda nieco lepiej i prościej go stworzysz w domenie security.

  Tip : Użyj Gradle - przekonasz się z czasem, że warto.
  Tip : extend'uj commons-logging - użyj logback.

 2. Web. Zarejestruj Security Filter w web.xml.
  

Tip : Kolejność filtrów jest ważna - jeśli o tym nie wiedziałeś to już wiesz;)

Następna sprawa to użycje javaConfig zamiast web.xml.
Jeśli używasz Servlet API w specyfikacji powyżej 3.0 włącznie nie musisz definiować web.xml. Nie jest już on obligatoryjny.

Tip : Jeśli używasz Xml czy JavaConfig wyekstraktuj kod związany z security do innego zasobu.

3. Skonfiguruj kontekst według własnej potrzeby
kontext z xml
kontext z javaConfig

4. Skonfiguruj minimum tego co na początku potrzebujesz + stwórz formę do logowania.

Tip : Stoworzenie formularza nie jest obligatoryjne ponieważ SpringSecurity potrafi wygenerować swój własny prosty formularz.

Co jest ważne a wynika z konfiguracji XML'a :

1. Formularz do logowania stworzony jest przez użytkonika i zmapowany pod URL : /welcome i to jest nasz główny punkt dostępowy

2. W przypadku błędu system wykorzysta ponownie nasz formularz lecz tym razem z paremetrem error -> /welcome?error=true
Błędem może być na ten czas wszystko. SpringSecurity sprytnie sobie przetłumaczy dany błąd na wyjątek, a my musimy podczepić i18n z odpowiednim komunikatem lub wykorzystać opisy błędów dostarczone ze springSecurity.
Tip : możesz wymusić HTTPS na danym punkcie dostępowym przez użycie requires-channel .

Tip : Ważne jest aby akcja logowania /j_spring_security_check przebiegała po kanale szyfrowanym najlepiej jeszcze POST'em. Uchroni Cię to przed podsłuchaniem hasła na linii.
URL /j_spring_security_check - to standardowy URL służący do autentykacji przez Web

Tip : _username oraz  j_password to standard SpringSecurity podczas budowania formy lub obsługi żadania pamiętaj o tym.


3. Wylogowanie :  logout-url="/logout" - definiujemy zasób URL na którym nastąpi akcja wylogowania.

TIP: Używaj handlerów. Zostały stworzone aby tam defiować dane zachowania jak np po wylogowaniu zmiana statusu w bazie danych.
(przykład handler użyty podczas wylogowania z aplikacji : success-handler-ref="logoutHandler")

4. Opis reguł bezpieczeństwa :
     np : /secure/** - dostępna tylko dla użytkowników który przeszli autentykacje.
     Czyli definiujesz kto z jaką rolą ma dostęp do danego zasobu URL.
  

Modele :
  - ACL  - drobnoziarnisty. Można definiować zachowania dla każdego obiektu dziedzinowego bardzo precyzyjnie. Traktuj jako macież zachowań.
Uwaga : model  może okazać się trudny do zarządzania jeśli wystąpi mnogość obiektów i czy rodzajów dostępów.

 - oparty na rolach : ROLE VOTER
   Łatwy prosty i przyjemny.

- oparty na rolach 'biznesowych'. Musisz sam oprogramować dane przypadki stosując strategie voterów.


Tip : Informacje o aktualnie zalogowanym użytkowniku dobrze opakować w tools'a.

cdn oraz uzupełnienie posta niebawem

Brak komentarzy:

Prześlij komentarz