Spring boot - autentizace/autorizace endpointu

[vesterna12]

V tutorialu pro spring-boot byla kapitola pro implementaci JWT tokenu, ktere jsou nasledovne pouzity pro autentizaci a autorizaci.
Implementace mi prijde naprosto silene slozita, ale mozna je to prvnim dojmem.
V realu jsem se setkal nejcasteji s resenim, kdy jednotlive koncove body nemaji implementovanou autentizaci ani autorizaci a jsou chraneny web serverem, kteremu je tato aktivita delegovana.
Da se tohle reseni povazovat za "standard"? Ma smysl se snazit do hloubky porozumet implementaci spring-security?

[Reklama]

[none_]

Ja jsem se naopak nikdy nesetkal s tim, ze by aplikace byla chranena jen nejakou proxy. Authentication je mozny delegovat, ale authorization si resi aplikace sama. Ale to neznamena, ze odpovi komukoliv. Naopak ocekava treba ten JWT token, ktery je dukazem authentication provedene nekde jinde.

[Filip Jirsák]

Autorizaci obvykle musí řešit koncová aplikace, protože jenom ona ví, kdo má k čemu přístup. Např. v e-mailu asi nechcete, aby vaše e-maily mohl číst někdo jiný, v e-shopu aby mohl vaše objednávky zobrazovat, vytvářet či stornovat někdo jiný, v bance aby někdo jiný mohl vidět váš stav účtu, minulé transakce a mohl provádět odchozí platby z vašeho účtu.

[vesterna12]

Dobre, pokud tedy web server provede autentizaci a v hlavicce posle seznam roli, ktere uzivatel ma je pak dostacujici kontrolovat jestli je aktualni pozadavek autorizovan na zaklade poskytnutych roli pomoci "if..." pri volani @RequestMapping nebo je to porad antivzor a mel by se i v tomto pripade pouzit "SecurityFilterChain" ?

[Filip Jirsák]

Za mne je lepší použít anotace na servisních metodách. SecurityFilterChain a podobné věci založené na textovém zadání URL se snažím nepoužívat a považuju je za nebezpečné. Mezi stringem popisujícím URL, které zabezpečuju, a URL, které vzniká definicí controlleru, není vůbec žádná vazba. Takže stačí překlep, a ,,zabezpečuju" špatné URL. V lepším případě, kdy je přístup všude zakázán a povoluje se, jenom znepřístupním nějaké URL. V horším případě, kdy je výchozí stav ,,vše povoleno" a přístup na vybrané adresy zakazuju stačí jeden hloupý překlep k tomu, abych dal přístup někam, kam být nemá.

[Reklama]

[luvar]

spring-security je moloch... Odporucam video https://www.youtube.com/watch?v=8rnOsF3RVQc (dve poznamky: 1. toto imho "deep dive" nieje 2. podobne informacie v textovej podobe sa mi nepodarilo najst ani v dokumentacii a ani v roznych blogoch. Len tuna to je pekne pokopy a vysvetlene pre zaciatocnika)

So springom a jeho oauth2 podporou sa da pohodlne pouzit napriklad Keycloack. Pripravte sa ale na kusok ucenia sa, alebo aspon citania blogov a stackoverflow, kym dosiahnete, co chcete...

Druha vec je, ked sa zamotate do CSRF a CORS... Napriklad ked zabezpecite endpointy cez OAuth2 (napriklad tak, ako to spravi defoltne vygenerovany projekt cez JHipster generator), tak je znacna sanca, ze /actuator/info endpoint nebude mat korektne nastavene CORSy a nepojde prevolat z webovej aplikacie, ktora by rada zistila verziu backendu. Neprejde pre-flight check (ak teda chceme ziskat json, kde je preflight povinny).

Proste security pri ako-tak serioznom projekte moze zozrat znacne mnozstvo casu, ked to robite prvy krat a poznate http len ako transportny protokol a nie ako "totie web technologie, co su aktualne v totých browseroch".

[vesterna12]

Za mne je lepší použít anotace na servisních metodách. SecurityFilterChain a podobné věci založené na textovém zadání URL se snažím nepoužívat a považuju je za nebezpečné. Mezi stringem popisujícím URL, které zabezpečuju, a URL, které vzniká definicí controlleru, není vůbec žádná vazba. Takže stačí překlep, a ,,zabezpečuju" špatné URL. V lepším případě, kdy je přístup všude zakázán a povoluje se, jenom znepřístupním nějaké URL. V horším případě, kdy je výchozí stav ,,vše povoleno" a přístup na vybrané adresy zakazuju stačí jeden hloupý překlep k tomu, abych dal přístup někam, kam být nemá.

Muzu se zeptat o jake anotace jde?

[none_]

Nejcasteji: PreAuthorize, PostAuthorize a Secured.
https://www.baeldung.com/spring-security-method-security

[Standa Blábol]

Za mne je lepší použít anotace na servisních metodách. SecurityFilterChain a podobné věci založené na textovém zadání URL se snažím nepoužívat a považuju je za nebezpečné. Mezi stringem popisujícím URL, které zabezpečuju, a URL, které vzniká definicí controlleru, není vůbec žádná vazba. Takže stačí překlep, a ,,zabezpečuju" špatné URL. V lepším případě, kdy je přístup všude zakázán a povoluje se, jenom znepřístupním nějaké URL. V horším případě, kdy je výchozí stav ,,vše povoleno" a přístup na vybrané adresy zakazuju stačí jeden hloupý překlep k tomu, abych dal přístup někam, kam být nemá.

Muzu se zeptat o jake anotace jde?

https://www.baeldung.com/spring-security-method-security

Pred pul rokem jsem si s JWT hral podle tohoto tutotrialu
https://www.javainuse.com/spring/boot-jwt

Je u krapet outdated, knihovna JJWT ma novou verzi a onen tutorial pouziva deprecated metody.

Implemetace JWT je slozita, protoze to je slozite.
Jinak doporucuju zvazit nasazeni Keycloak, na strane Frontendu i backendu se to velice zjednodusi, pribyde ale prace s keycloak.
Osobne jsem pred casem delal vlastni JWT jenom proto, ze zakaznik pozadovat velice divoukou autentizaci/autorizaci oprenou o RADIUS, kde role byly v plaintextu v jakemsi atributu...

[Filip Jirsák]

Muzu se zeptat o jake anotace jde?

Nebo v tom tutorialu, podle kterého asi postupujete, je to o kousek dál: Method Security. Na Web Security bych se úplně vykašlal, protože jak říká drobná poznámka na konci celé kapitoly, je to aktuálně svázáno jen se Servlet API. Takže je to založené na divném a nespolehlivém principu a ještě na technologii, která je (dokonce i ve Springu) pomalu nahrazována modernějšími variantami (které jsou založené na reaktivním programování).

[Ziktofel]

K jakym datum ma uzivatel pristup, se ma resit na service, nekdy v zavislosti na pravech uzivatel dostava ruzna data - Service resi operaci. Pokud ke spusteni nejake operace je potreba role, pouziju @Secured. Pro vsechny komunikacni kanaly ma uzivatel porad pristup ke stejnym datum a moznostem s nimi nakladat (je jedno, jestli leze pres webovou stranku, REST, nebo GraphQL API)
Controller ma resit jenom precteni vstupu uzivatele a zaslani vystupu - resi komunikaci s klientem (prectu pozadavek a vratim vystup)
Spring security filtery pouzivam na nastaveni prav uzivatele

[vesterna12]

Nejjednodussi kod ze ktereho jsem konecne presne pochopil jak autentizace a autorizace funguje ve springu jsem nasel tady

https://github.com/Java-Techie-jt/spring-boot-security-3.0/tree/main/src/main/java/com/javatechie

SecFilterChain jsem chapal, ale porad jsem uplne nechapal instance ostatnich trid a jejich ucel. Tohle je maly kod ze ktereho je to snadno pochopitelne.
Jako zacatecnik ve Spring se jeste moc neorientuju...

[Filip Jirsák]

No, nevím. V tom příkladu se pořád používá SecurityFilterChain a pak se ještě přístupová práva řeší na controlleru. Na servisních metodách naopak zabezpečení není. To podle mne není dobrá cesta.

[vesterna12]

S tim si pak uz poradim, ale aktualne mam problem s autentizaci kdy se kazdy uzivatel muze autentizovat pouze jednou.
Pri druhem pokusu vidim hlasku

Kód [Vybrat] Rozbalit

023-04-26T20:06:01.343+02:00  WARN 160351 --- [io-8080-exec-10] o.s.s.c.bcrypt.BCryptPasswordEncoder     : Empty encoded password

Kód [Vybrat] Rozbalit


public class SecurityConfig {

    @Bean
    //authentication
    public UserDetailsService userDetailsService() {
        return new UserInfoUserDetailsService();
    }
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public AuthenticationProvider authenticationProvider(){
        DaoAuthenticationProvider authenticationProvider=new DaoAuthenticationProvider();
        authenticationProvider.setUserDetailsService(userDetailsService());
        authenticationProvider.setPasswordEncoder(passwordEncoder());
        return authenticationProvider;
    }


    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http.csrf().disable()
                .authorizeHttpRequests()
                .requestMatchers("/products/welcome","/products/new").permitAll()
                .and()
                .authorizeHttpRequests().requestMatchers("/products/**")
                .authenticated().and().formLogin().and().build();
    }
}



Kód [Vybrat] Rozbalit


@Repository
public class UserDao {
    private final static List<UserDetails> APPLICATION_USERS = Arrays.asList(
            new User("email@email","$2a$12$rEGy9.W4cVmwftdHed74quwkJVfPRZt1TgAsF8le9isOWvOWdlscW", Collections.singleton(new SimpleGrantedAuthority("ROLE_ADMIN"))),
            new User("email2@email","$2a$12$rEGy9.W4cVmwftdHed74quwkJVfPRZt1TgAsF8le9isOWvOWdlscW", Collections.singleton(new SimpleGrantedAuthority("ROLE_VIEW"))),
            new User("email2@email","password2", Collections.singleton(new SimpleGrantedAuthority("ROLE_CLIENT")))
    );
    public UserDetails findUserByEmail(String email){
        System.out.println("search user");
        System.out.println(APPLICATION_USERS.stream().filter(u->u.getUsername().equals(email)).findFirst());
        return APPLICATION_USERS.stream().filter(u->u.getUsername().equals(email)).findFirst().orElseThrow(()->new UsernameNotFoundException("User not found"));
    }
}


[registrovany123]

No tak snad víš, co a proč potřebuješ autorizovat, a podle toho se pak rozhodneš, jak to budeš dělat, ne? Jestli ti stačrí ochránit endpointy a nic víc, nebo ti stačí ochrana intranetem atd.

Autorizace a Autentizace s JWT může být jednoduchá i složitá. Když děláš profi, musíš použít standard, např. OAuth 2.0, k tomu potřebuješ použít spring-security abys to měl podle standardu, ručně to hadnlovat nemá v Javě smysl. Ale pokud někdo si dělá jednoduchý web v Pythonu pro osobní použití, tak nemusí použít standard.

Proste, najdi si lepsi tutorial ktery ti to vysvetli polopaticky, protoze tak tezke to neni.