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

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: 
Sent from the Shiro User mailing list archive at Nabble.com.

Reply via email to