Rest API secure

Cześć.

Tworzę w springu aplikację restową i przyszedł moment na autoryzację i teraz nie mam pomysłu jak to wykonać.
Aplikacja ma opierać sie o spring boot + embedded tomcat + angularjs

1. myślałem o http basic + https, ale to korzysta z httpSession wieć niezbyt stateless
2. digest auth, ale jak zrozumiałem dane w bazie muszę trzymać jako plain text? więc odpada
3. oaut2? jeszcze jakoś się w to nie wgryzłem, rozumiem że oddzielny serwer który przydziela tokena?
4. coś innego?

Mógłbym prosić o jakieś wskazówki i ewentualne rady na co mam szczególnie zwrócić uwagę.
Aplikacja to ma być taki POC, coś to pokazania na rozmowie kwalifikacyjnej itp to może nie warto się bawić w jakieś wodotryski i http basic?

a i rejestracja w app to po prostu po https i nic więcej?

Dzięki ;)

1. prosto i przyjemnie....statelessa po co CI to?

I rozumiem że SSL załatwi mi wszystko? A stateless bo niby rest powinien być statelessowy ...
Hasło na bazce jakimś bcryptem.
A w takim projekcie na rozmowe kwalifikacyjną bawić się http session i redisem?

Dzięki szczery za odpowiedź.

też się zastanawiam w jaki sposób zrobić autoryzacje po RESTcie żeby było przyjemnie i prosto
jeśli ktoś ma doświadczenie w tym to chętnie się dowiem czegoś czego nie wiem :)

Może takie coś?

http://stackoverflow.com/questions/24150621/spring-security-token-authentication-restful-json-service

Basic authentication po SSL

Basic + SSL jako podstawa. Następnie można bawić się jeszcze z:

1. dodatkowe nagłówki z tokenami
2. podpis cyfrowy żądania (stosunkowo skomplikowane jak na REST).
3. separacja na poziomie infrastruktury (jeden punkt wejścia, który wewnątrz zawiera pełen routing).

@azalut, pamiętam o tobie.

Aj pomyliło mi się, raz jeszcze.
Co będzie lepsze:
http basic czy form auth z cookiesem + jsessionID.

A co chcesz uzyskać? Jak kompletnie bezstanowy REST to base +ssl + rozszerzenia. Jeżeli jednak robisz normalną apkę to łatwiej jest na początku ogarnąć wersję z ciastkiem, bo transmisją tego czegoś zajmuje się przeglądarka.

Aplikacją ma być sklep i będę korzystał z sesji dla koszyka tylko myślę tę sesję podlinkować po jakąś BD.
Z chęcią zrobiłbym to z ciastkami i zajął się bebechami, np na blogu springa jest cykl kilku wpisów o tematyce właśnie rest + angular i piszą że do sporej ilości sytuacji jest to ok i nie ma po co komplikować.Tylko że nie posiadam punktu odniesienia. Nie mam doświadczenia i chciałbym uzyskać odpowiedź czy takie rozwiązanie zostanie potem dobrze przyjęte w przypadku właśnie takiego projektu w stylu POC. W skrócie co być powiedział gdyby z czymś takim przypałętał się do Ciebie junior ;)

To bym powiedział rób to na ciastkach, ale zrób tak, żeby później można było to w miarę łatwo zmienić. BTW, trzymanie koszyka w sesji to zuo (bo się to nie skaluje).

A koszyk chciałbym jakoś zapamiętać dla zalogowanego użytkownika (bo to spore źródło danych), więc dlatego chciałbym sesję pod BD podlinkować, a myślałem też o redisie - spring-session-redis.
Bo koszyk mógłbym jeszcze trzymać w ciastku lub local storage po stronie klienta. Aktualnie nie mam więcej pomysłów, więc szukam, czytam.

Redis ok. Storage po stronie klienta średnio (jedynie responsywność), ale obecnie to taka "norma". Dobrze, że tak bo już myślałem, że zwykły obiekt w ramach Session.

@Koziołek super dzięki wielkie!
A zamiast redisa może byc na początek h2 czy coś w tym stylu zanim bardziej zapoznam sie z ideą redisa.
A i rozumiem że taką sesje to przed końcem jej trwania zrzucam na bazkę czy całkowicie operuję na bazie zamiast na sesji.
I jeszcze jak używam ssl to mieć projekt od razu skonfigurowany pod https czy np profil który będzie mi konfigurował embedded tomcata

Jeżeli chcesz się zapoznać z ideą Redisa używaj Redisa. Nie ma lepszej metody. Co do zrzucania sesji do bazy przed zakończeniem to jest to niezbyt dobre. Powolne i generalnie potrafi zarówno zapchać serwer jak i bazę. Lepiej zrzucać tylko najpotrzebniejsze elementy. Co do SSL to zrób to na tyle elastycznie by móc go włączać i wyłączać jednym parametrem. Ułatwi ci to testy.

@Koziołek
z tego co wiem Spring Security ma taki moduł Spring-Security-OAuth2 - co myślisz o OAuth2? Obecnie w swojej aplikacji która pisałem jakis czas temu nie użyłem OAuth2, ale jak o tym poczytałem to sama koncepcja jest podobna, ale wciąż mam wrażenie, że to za mało bezpieczne :P (nie wiem czy to się nie podszywa pod punkt 1 na twojej liście która wczesniej podałeś - nagłówek z tokenem)
Np. stron banków to w ten sposób się raczej nie zabezpiecza, co?

@azalut ale to ma konkretne zastosowanie. Jeżeli chcesz mieć portal na którym ludzie dzielą się swoimi samojebkami i korzystają z albumów na FB to OAuth będzie OK. Jednak np. dostępu do konta firmowego na tym mechanizmie bym nie opierał.

CzerownyPomidor napisał(a):

Cześć.

1. myślałem o http basic + https, ale to korzysta z httpSession wieć niezbyt stateless

Możesz spróbować ustawić politykę tworzenia sesji. Przykładowa konfiguracja:

public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        /**
         * Tu jakas konfiguracja HTTP Basic
         */
        http.sessionManagement().sessionCreationPolicy(
                SessionCreationPolicy.STATELESS);
    }
}

Powinno być bardziej "stateless" :)

@Koziołek w takim razie jaka metoda autoryzacji jest na tyle bezpieczna żeby używać ją w systemach np bankowych czy innych wymagających dużego bezpieczeństwa?

Z tym bywa różnie i różne banki stosują różne zabezpieczenia.
Podstawą jest oczywiście odpowiedni certyfikat SSL (certyfikaty maja swoje "klasy", które przekładają się na odpowiednio wysokie poziomy zabezpieczenia oraz ubezpieczenie wystawców), który zabezpiecza komunikację.
Większość banków stosuje uwierzytelnianie jedno składnikowe dla logowania. Zazwyczaj hasło. Zarówno jako całość (podajesz pełne jak w np. mBanku) jak i wybrane znaki z hasła (np. ing). Rzadziej stosuje się uwierzytelnianie dwuskładnikowe, gdzie poza hasłem podajemy czy to kod wysłany smsem czy też odczytujemy kod z odpowiedniego tokena hardwerowego (bodajże z rsa id korzystał dawny lukas).
Kolejnym elementem są kody jednorazowe, które bank wymaga do potwierdzenia poszczególnych operacji np. przelewów, dodawania odbiorców do książki adresowej, modyfikowania zleceń stałych itp.

Tak oczywiście zabezpieczane są dostępy przez kanał internetowy. Trochę inaczej wygląda to w przypadku aplikacji na komórki, ale tu nie miałem do czynienia z tego typu rozwiązaniami.

Kolejna sprawa to oczywiście zabezpieczenie innych kanałów jak IVR czy telefon.

Osobiście używam OAuth w aplikacjach springowych i działa bardzo fajnie. Daje dużo możliwości, jeśli chodzi o dostęp innych klientów do twoich zasobów.