Java: concessione della licenza a una webapp. Verifica la licenza prima che avvenga il login

Question

Voglio rendere la mia licenza webapp protetta. Quando viene richiesta una pagina/risorsa di webapp, voglio prima controllare la licenza. Se la licenza non viene trovata, desidero reindirizzare alla pagina di caricamento della licenza.

Ho creato un filtro che mappa tutte le richieste in cui posso controllare la licenza e reindirizzare se necessario. Il problema è che la mia webapp ha un vincolo di sicurezza per l'autenticazione di login. vedi web.xml alla fine per maggiori informazioni.

A causa del vincolo di sicurezza, tutte le richieste vengono prima intercettate dall'autenticazione di accesso e quindi inoltrate al mio filtro. Tuttavia, voglio verificare la licenza prima che il login possa accadere.

Ecco una domanda correlata che ho chiesto.

Java : Intercept all requests before they go to login authentication

Dare priorità filtro sopra il vincolo di sicurezza sembra essere impossibile. Quindi, voglio chiedere c'è un altro modo in cui posso affrontare questo caso d'uso?

web.xml

<?xml version="1.0" encoding="UTF-8"?> 
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    id="WebApp_ID" version="2.5"> 
    <display-name>Tango</display-name> 

    <filter> 
     <filter-name>SalsaValidationFilter</filter-name> 
     <filter-class>net.semandex.salsa.validationFilters.SalsaValidationFilter</filter-class> 
    </filter> 

    <filter-mapping> 
     <filter-name>SalsaValidationFilter</filter-name> 
     <url-pattern>/*</url-pattern> 
     <!-- <servlet-name>SalsaValidationServlet</servlet-name> --> 
     <dispatcher>REQUEST</dispatcher> 
    </filter-mapping> 

    <session-config> 
     <session-timeout>20</session-timeout> 
    </session-config> 

    <security-constraint> 
     <web-resource-collection> 
      <web-resource-name>Login page images</web-resource-name> 
      <url-pattern>/images/salsadb-logo2.png</url-pattern> 
      <url-pattern>/images/salsa-icon.png</url-pattern> 
      <url-pattern>/images/shadow_box.png</url-pattern> 
      <url-pattern>/images/header.png</url-pattern> 
      <url-pattern>/images/bg.png</url-pattern> 
      <url-pattern>/css/splash.css</url-pattern> 
      <url-pattern>/WEB-INF/licenseValidation.html</url-pattern> 
      <url-pattern>/auth/licenseValidation.html</url-pattern> 
     </web-resource-collection> 
    </security-constraint> 

    <security-constraint> 
     <web-resource-collection> 
      <web-resource-name>The entire webapp</web-resource-name> 
      <url-pattern>/*</url-pattern> 
     </web-resource-collection> 
     <auth-constraint> 
      <role-name>SalsaUser</role-name> 
     </auth-constraint> 
    </security-constraint> 

    <security-role> 
     <role-name>SalsaUser</role-name> 
    </security-role> 

    <login-config> 
     <auth-method>FORM</auth-method> 
     <form-login-config> 
      <form-login-page>/auth/login.jsp</form-login-page> 
      <form-error-page>/auth/loginError.jsp</form-error-page> 
     </form-login-config> 

     <realm-name>mongo_login</realm-name> 
    </login-config> 
</web-app> 

Answer 1

Se è necessario verificare la licenza prima di autenticazione, l'unico modo sarebbe utilizzando la sicurezza programmatica e compresa la verifica della licenza come parte del processo.

La sicurezza programmatica è utile quando la sola sicurezza dichiarativa è non sufficiente per esprimere il modello di sicurezza di un'applicazione. L'API per la sicurezza programmatica è costituita dai metodi dell'interfaccia EJBContext e dall'interfaccia HttpServletRequest. Questi metodi consentono ai componenti di prendere decisioni di business logic in base al ruolo di sicurezza del chiamante o dell'utente remoto.

https://docs.oracle.com/javaee/7/tutorial/security-intro003.htm#BNBXH

Ecco alcuni brevi esempi: https://docs.oracle.com/javaee/7/tutorial/security-webtier003.htm#GJIIE

Non ho fatto la sicurezza programmatica me stesso, ma dagli sguardi di esso si potrebbe fare qualcosa di simile:

1. Eliminate la sicurezza del contenitore dal vostro web.xml: progettandolo, precederà tutto il resto e quindi vi metterà sulla vostra strada. Idealmente, puoi semplicemente impostare auth-method su NONE e mantenere il vincolo di sicurezza -presumibilmente ti verrà mostrata la pagina di errore direttamente quando provi ad accedere e quindi puoi fare 2) e 3) (sotto) da lì in servlet prima di riprovare . Se è necessario eliminare anche il vincolo di sicurezza, utilizzare i filtri come segue.
2. Aggiungere un filtro che verificherà la licenza. Non riesce, verrà reindirizzato a una pagina per caricare la licenza e riprovare. In caso contrario, farai il prossimo filtro nella catena.
3. Il prossimo filtro della catena sa che la licenza è valida. Se l'utente non è registrato, proverà a ottenere l'utente e la password come parametri di richiesta. Se esistono, cercheranno di autenticarsi a livello di codice con loro -questo punto stai facendo uno degli esempi nel link precedente. Se l'utente è registrato, procedere. Se le credenziali non corrispondono o non ci sono credenziali da provare, reindirizza a una pagina di accesso personalizzata per consentire all'utente di compilare le sue credenziali e riprovare.
4. Se dovessi eliminare il vincolo di sicurezza dal tuo web.xml, disponi di un altro filtro per controllare i ruoli qui e qualsiasi altra cosa tu possa avere bisogno.

Assicurati di reindirizzare su un percorso diverso, in modo che quelle pagine non chiamino più i filtri e il ciclo. (I filtri possono essere configurati per essere saltati durante l'inoltro/reindirizzamento e penso che sia l'impostazione predefinita, ma se dovessi abbandonare il vincolo di sicurezza allora vuoi essere sicuro che vengano chiamati a prescindere.)

Si potrebbe fare tutto questo in un singolo filtro e/o invece di reindirizzare quando fallisce di scrivere la risposta appropriata (un po 'simula un servlet che esegue il POST a se stesso più volte). Un filtro è meglio per questo di un servlet perché puoi essere sicuro che sia stato chiamato per qualsiasi tentativo di accesso.

Un altro modo sarebbe scrivere tutto in 2) e 3) come un singolo servlet a parte l'app "reale" e avere un filtro che reindirizza ad esso se la sessione non è autenticata e non ha il corretto " set di attributi "licenza valida" (lo hai impostato nel servlet). Questo potrebbe essere più veloce e forse più semplice da mantenere, ma non così strettamente accoppiato.

Answer 2

Questo è niente a che fare con JACC. Il controllo della licenza dell'applicazione Web normale viene eseguito una volta eseguita l'autorizzazione dell'utente. Il modo in cui lo si convalida dipende dal design dell'applicazione.

1. You can add a filter to the filter chain that intercepts to after 
    the user authorization. In this approach you need to properly 
    communicate user that license is failed. 


2. Redirect the user to license verification page after user 
     authorization is done. Ask user to verify the license. If the verification fails then redirect user again login page. In this approach you have advantage of displaying the web apps he is licensed in the suite of web apps. 

Thank in advance 
-Bharat