Ho due set di URL: un set è l'API REST, il secondo è il sito web piuttosto ordinario. Voglio applicare diverse regole di sicurezza per l'API REST in modo che l'utente/script che ha occasionalmente invocato API REST risponda con codice 401 (l'autenticazione di base va bene) o solo 403.Spring Security - configurazione separata per REST API e altri URL
Quindi voglio consentire accesso all'API REST per:
- l'utente che ha effettuato l'accesso (per javascript nella pagina del sito che richiama l'API REST condivide quindi la stessa sessione).
- uno script che richiama l'API REST con credenziali di autenticazione di base nell'intestazione dell'autenticazione WWW.
Al momento sto cercando di capire quale configurazione renderà la primavera "capire" ciò che voglio. Sono venuto con la seguente configurazione:
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd">
<http pattern="/" security="none" />
<http pattern="/static/**" security="none" />
<!-- REST API -->
<http pattern="/rest/*" use-expressions="true">
<http-basic />
<intercept-url pattern="/*" access="isAuthenticated()" />
</http>
<!-- Site -->
<http access-denied-page="/WEB-INF/views/errors/403.jsp" use-expressions="true">
<intercept-url pattern="/index.html" access="hasRole('ROLE_USER') or hasRole('ROLE_ANONYMOUS')" />
<intercept-url pattern="/login.html" access="hasRole('ROLE_USER') or hasRole('ROLE_ANONYMOUS')" />
<intercept-url pattern="/admin/*" access="hasRole('ROLE_ADMIN')" />
<intercept-url pattern="/**" access="hasRole('ROLE_USER')" />
<form-login login-page="/login.html"
default-target-url="/index.html"
authentication-failure-url="/login.html?error=1" />
<logout logout-url="/logout.do" logout-success-url="/index.html" />
<anonymous username="guest" granted-authority="ROLE_ANONYMOUS" />
<remember-me />
</http>
<authentication-manager>
<authentication-provider>
<user-service>
<user name="admin" password="2" authorities="ROLE_ADMIN,ROLE_USER" />
<user name="alex" password="1" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>
</beans:beans>
Purtroppo non solo l'autenticazione di base non funziona con questa configurazione, ma non v'è alcuna 403 risposte per le domande presentate dagli utenti anonimi - risposte di applicazione con reindirizzamento 302 Trovato che avevo piace disabilitare per gli URL API REST.
Ho provato ad aggiungere punto di ingresso personalizzato per REST API:
<beans:bean id="ep403" class="org.springframework.security.web.authentication.Http403ForbiddenEntryPoint"/>
<!-- REST API -->
<http pattern="/rest/*" entry-point-ref="ep403" use-expressions="true">
<intercept-url pattern="/*" access="hasRole('ROLE_USER')" />
<http-basic />
</http>
, ma questo non funziona neanche.
Riassumendo quello che voglio ottenere:
- Consenti all'utente autorizzato ad accedere API REST (impianto di autorizzazione dovrebbe tener conto la sessione utente nei cookie).
- Consenti allo script di accedere all'API REST se specifica il token di autenticazione corretto e non specifica la sessione nei cookie.
UPDATE
Dopo aver scavato in interni Primavera di sicurezza ho trovato il codice che decide se negare certa richiesta o meno. Questo è un cosiddetto "Voters di decisione di accesso", fondamentalmente tutti applicati a determinate richieste e se un elettore di decisione di accesso in una catena vota per negare l'accesso a determinate risorse la richiesta viene in definitiva negata.
Da qui il problema originale potrebbe essere risolto con l'introduzione di speciali decisione degli elettori di accesso che si comporta nel modo seguente: si cerca di estrarre ruolo associato dalla sessione (se del caso presente nella richiesta) e procede a passo di autorizzazione con questo ruolo; se non è presente alcuna sessione, tenta di autenticare l'utente con le credenziali nell'intestazione WWW-Authenticate e quindi passa alla fase di autorizzazione con i ruoli associati all'utente specificato.
Grazie, crea-session fa il trucco, ma sebbene questo faccia funzionare l'autenticazione di base, un'autenticazione per sessione si è rifiutata di funzionare (in altre parole javascript sulla pagina non sarà in grado di accedere all'API REST). – Alex
Sì è vero. Cambiare i modelli è stato utile? –
Il pattern non ha molta influenza dato che ora ho uno schema url REST API molto semplice (come/rest/book? Name = X - al momento sono bloccato con onere oneroso e non penso di estenderlo) . Ovviamente il mio pattern non funzionerà per gli URL con nidificazione profonda come/rest/one/two, grazie per averlo indicato. create-session = "stateless" rende l'autenticazione di base funzionante per entrambi i pattern, ma fa in modo che la molla ignori la sessione autorizzata esistente per entrambi i pattern. – Alex