I believe JSPs offer no benefit - they have been replaced by JSF within JEE. You can use servlets without JSP or JSF, but if you do use JSP or JSF you will need an application server like Wildfly or Glassfish or have to include the required components into Tomcat yourselves.
You do not check whether a user is authenticated on the client but only on the server because you want to prevent malicious people from viewing / modifying the data on the server. Your client only retrieves data from the server and triggers business logic on the server - it sends authentication data (either user / password or session cookie) to the server for each and every request to the server. If the authentication data is rejected by the server the client receives a HTTP 401 and should inform the user that it could not do what he desired. If you want to implement an alternative method to this scenario, then, I doubt Shiro will be of much use to you because it is designed to run server side where it has access to and can protect all your data. If you are not going to use Shiro's built-in architecture but instead rework how security is handled, then, you would probably be better off looking for a different security framework. When I talked about having a SecurityManager and Subject on the client it was only to explain the problems arising from this scenario - I did *not* mean to suggest you actually do it that way. Transactions are a feature of SOAP where you can specify that multiple SOAP requests may only be processed in entirety, so, if one SOAP request fails for whatever reason the other SOAP requests would either be aborted or rolled back. The token is implementation specific (Shiro classes do change) whereas user / password are just strings - sending tokens over the line could create issues when the Shiro libraries differ on client and server. Additionally, HTTP enforces restrictions on any data sent - e. g. you may only send strings, so, you would have to do proper marshaling / unmarshaling of the tokens. Using sessions or not has no influence on how secure an application is, it is the implementation that matters - implementing security badly is as easy to do with or without sessions. Example: Say your client is running on Android, then, the NSA could install their own app which reads out your phone's memory and sends it to them. If you use sessions then the username and password are only needed for one request and if the NSA app fails to capture that specific point in time then it will only have the session to go with, which has a limited lifetime. If, on the other hand, you decide to forfeit sessions then you will have to cache username and password on the client app meaning the NSA has access to it for as long as the user uses your app. So, using sessions or not does not naturally imply more or better security - it is more a matter of choice (mostly of the framework you choose server side). Storing session data (session cookie or Shiro session) in a database should work well. To prevent session hijacking, best to use tried and tested open source software where a lot of people contribute to - trying to implement it oneself has a high probability of failing. TLS is the improved SSL and should be provided as default out of the box with any HTTP security framework and on any and all application servers. -- View this message in context: http://shiro-user.582556.n2.nabble.com/How-should-we-go-about-configuring-a-Desktop-Client-with-Shiro-in-the-Server-tp7581322p7581335.html Sent from the Shiro User mailing list archive at Nabble.com.
