Primavera Boot 1.3.3 @EnableResourceServer e @ EnableOAuth2Sso allo stesso tempo

Question

voglio che il mio server sia un ResourceServer, che può accettare un token di accesso al portatore

Tuttavia, se tale token non esiste, voglio usare OAuth2Server per autenticare il mio utente.

cerco di fare come:

@Configuration 
@EnableOAuth2Sso 
@EnableResourceServer 
public class SecurityConfiguration extends WebSecurityConfigurerAdapter{ 

    @Override 
    protected void configure(HttpSecurity http) throws Exception { 
     http.authorizeRequests().anyRequest().authenticated(); 
    } 
} 

Tuttavia, in questo caso, solo le opere di annotazione @EnableResourceServer. Esso restituisce

Full authentication is required to access this resource 

E non mi reindirizzamento alla pagina di login

ho detto che il @Order è importante, se aggiungo il @Order(0) annotazione, sarò redirect alla pagina di login, però, ho non può accedere al mio risorsa con l'access_token nell'intestazione HTTP:

Authorization : Bearer 142042b2-342f-4f19-8f53-bea0bae061fc 

Come posso raggiungere il mio obiettivo? Voglio che utilizzi Access token e SSO allo stesso tempo.

Grazie ~

Answer 1

utilizzando sia la configurazione sulla stessa richiesta sarebbe ambigua. Ci potrebbe essere una soluzione per questo, ma più chiaro per definire i gruppi richiesta separata:

• OAuth2Sso: per gli utenti provenienti da un browser, vogliamo per orientarle verso il provider di autenticazione per il token
• ResourceServer: di solito per le richieste API, arrivando con un token che hanno ottenuto da qualche parte (più probabilmente dalla stessa provider di autenticazione)

per raggiungere tale obiettivo, separare le configurazioni con richiesta matcher:

@Configuration 
@EnableResourceServer 
public class ResourceServerConfiguration extends ResourceServerConfigurerAdapter { 

    @Bean("resourceServerRequestMatcher") 
    public RequestMatcher resources() { 
     return new AntPathRequestMatcher("/resources/**"); 
    } 

    @Override 
    public void configure(final HttpSecurity http) throws Exception { 
     http 
      .requestMatcher(resources()).authorizeRequests() 
      .anyRequest().authenticated(); 
    } 

} 

ed escludere questi dal catena dei filtri sso:

@Configuration 
@EnableOAuth2Sso 
public class SsoSecurityConfiguration extends WebSecurityConfigurerAdapter { 

    @Autowired 
    @Qualifier("resourceServerRequestMatcher") 
    private RequestMatcher resources; 

    @Override 
    protected void configure(final HttpSecurity http) throws Exception { 
     RequestMatcher nonResoures = new NegatedRequestMatcher(resources); 
     http 
      .requestMatcher(nonResoures).authorizeRequests() 
      .anyRequest().authenticated(); 
    } 
} 

E mettere tutte le risorse sotto /resources/**

Naturalmente in questo caso sia utilizzerà lo stesso OAuth2 configurazione (accessTokenUri, jwt.key-value , ecc.)

UPDATE1:

In realtà si può raggiungere il tuo obiettivo originale utilizzando questa richiesta matcher per la configurazione di cui sopra:

new RequestHeaderRequestMatcher("Authorization") 

UPDATE2: (Spiegazione di @ sid-morad commento di)

Primavera Security crea un filtro catena per ogni configurazione. Il matcher della richiesta per ciascuna catena di filtri viene valutato nell'ordine delle configurazioni. WebSecurityConfigurerAdapter ha l'ordine predefinito 100 e ResourceServerConfiguration è ordinato 3 per impostazione predefinita. Il che significa che il matcher della richiesta di ResourceServerConfiguration è stato valutato per primo. Questo ordine può essere ignorata per queste configurazioni come:

@Configuration 
@EnableResourceServer 
public class ResourceServerConfiguration extends ResourceServerConfigurerAdapter { 

    @Autowired 
    private org.springframework.security.oauth2.config.annotation.web.configuration.ResourceServerConfiguration configuration; 

    @PostConstruct 
    public void setSecurityConfigurerOrder() { 
     configuration.setOrder(3); 
    } 
... 
} 

 

@Configuration 
@EnableOAuth2Sso 
@Order(100) 
public class SsoSecurityConfiguration extends WebSecurityConfigurerAdapter { 
... 
} 

Quindi sì, richiesta matcher non è necessario per SsoSecurityConfiguration nell'esempio precedente. Ma bello sapere le ragioni dietro :)