>The original developer (Lez Hazelwood) went with what he knew best, which was
the Spring Framework which uses JSP pages as far as I know for web
development. But as long as the resulting HTTP request is the same it does
not matter whether that request was generated by JSP, naked HTML5, node.js,
Python or whatnot.


It makes sense that it would work for any HTTP request in a browser, but are 
there any advantage in keeping this in  a JSP?  I would assume that the only 
reason would be for Servlet use, which some people might not need, but I'm not 
sure if extra configuration would be needed for a regular html page?

>Yes everything gets done on the server and the responses should only contain
data that is to be displayed /updated on the client. No data should be
returned by the server if the calling request fails to pass authentication.
So, you would not check whether user.isAuthenticated() but instead fire a
request to the server to load all users to display them in a list on the
client. You would need to do a login on the first request and then resend
the session cookie for subsequent calls to the server. If the request fails
to pass authentication the client would have to react appropriately, e. g.
by requesting the user to login (again after session has expired).

Thanks for the information.  You mention I wouldn't check if the user is 
authenticated, but in the other email you mention I would still have the 
SecurityManager and Subject on the client's machine, so where exactly do they 
come in if we don't check authentication?  I understand the method you 
mentioned, but I'm curious about alternate  methods and how well they would 
work(not looking to go against best practices,m but curious is all [?]  ).


>"Web Service" generally means "pull data from server via the HTTP protocol"
and it can be done by either SOAP (which I would only recommend if you need
transactions) or REST (plain HTTP GET, PUT, POST, DELETE). With both SOAP
and REST you can use either session cookies or not, depending on what you or
your framework(s) prefer. If you decide not to use session cookies you would
have to send username and password on each request to pass authentication.
Do not send the login token as that is created form the username and
password from the request on the server during the authentication process.

Thanks for the information on this.   What exactly do you mean by 
"transactions?"  I wasn't sure if we would send a token or just the un/pw combo 
to create the token on the server?  Is there something special about the  token 
that  it shouldn't be created on the user's machine, or is it more along the 
lines of text vs an object that has to be sent?  I was looking at the Session 
information on the forum and  noticed that it spoke about the stateless 
protocol, which might be useful for me.  Is there an advantage of the fact that 
you cannot steal sessions and have to authenticate each time?  I'm not sure if 
that is more secure, or what the pros vs cons of that would be overall.


> I do not think EhCache is the proper tool here as it does not work on
distributed machines without an added layer for synchronization between
client and server and it completely bypasses HTTP and generally all Shiro
authentication mechanisms and instead stores and manipulates Shiro sessions
directly. We use EhCache to share Shiro's session cache for single sign on
between independent Java applications on the *same* server (independent war
files) - user logs in to one application and is automatically logged in to
the other applications, too.


I wasn't really sure what should be used in my case, but EHCache was what I saw 
shown in the examples, but my usercase is different. I am thinking more along 
the lines of storing my session data in a database, would that work well?  I 
would also like to store some other information such as IP, but not really sure 
what I am allowed to store, or what information I could get.  Thanks for the 
information on why it wouldn't be a good choice for me.

> Addressing your concerns about session hijacking / poisoning: that can
happen, too, when using EhCache and a synchronization layer. A friendly tip
on this behalf: It is generally considered impossible for a single person or
small group to pinpoint and solve all security issues introduced by modern
day applications. Instead one should use frameworks and tools which are in
wide-spread use and have been well tested over time to address security
issues. Using HTTP gives you the option to use TLS and a secure web
framework to harden your communication between client and server - these
tasks are generally well understood and you can find tons of information on
how to achieve this
(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project[https://gc.kis.v2.scr.kaspersky-labs.com/C9E11F2E244D-C389-B41C-613F-DD68A941/ua/UrlAdvisorGoodImage.png]).
 How to
Category:OWASP Top Ten Project - 
OWASP<https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project>[https://gc.kis.v2.scr.kaspersky-labs.com/C9E11F2E244D-C389-B41C-613F-DD68A941/ua/UrlAdvisorGoodImage.png]
www.owasp.org
OWASP Top 10 - 2016 Data Call Announcement. Public Notice: The OWASP Top 10 
project is launching its effort to update the Top 10 again. The current version 
...



secure EhCache and its underlying synchronization layer in contrast is a
task you would have to find out for yourselves.



Yeah it seems that EhCache is not for me.  There are many security threats out 
there, but it's all very interesting how it all works to crack and then fix.  
As mentioned above would using stateless over sessions be better for protection 
against Session hijacking?  As for TLS, would that be preferred over SSL?  I'm 
not very knowledgeable on ssl and the like, but appreciate the advice/help.
________________________________
From: scSynergy <ronald.fei...@scsynergy.de>
Sent: Thursday, October 13, 2016 2:38:12 AM
To: user@shiro.apache.org
Subject: Re: How should we go about configuring a Desktop Client with Shiro in 
the Server?

The original developer (Lez Hazelwood) went with what he knew best, which was
the Spring Framework which uses JSP pages as far as I know for web
development. But as long as the resulting HTTP request is the same it does
not matter whether that request was generated by JSP, naked HTML5, node.js,
Python or whatnot.

Yes everything gets done on the server and the responses should only contain
data that is to be displayed /updated on the client. No data should be
returned by the server if the calling request fails to pass authentication.
So, you would not check whether user.isAuthenticated() but instead fire a
request to the server to load all users to display them in a list on the
client. You would need to do a login on the first request and then resend
the session cookie for subsequent calls to the server. If the request fails
to pass authentication the client would have to react appropriately, e. g.
by requesting the user to login (again after session has expired).

Alternatively, you could make all calls to the server stateless by
configuring Shiro to not create sessions on successful authentications:
[urls]
/login.xhtml = ssl[8443], user, authc
/logout = logout
# the next line is needed to retrieve jsf resources from jar library
/javax.faces.resource/** = ssl[8443], anon
/rest/** = *noSessionCreation*, ssl[8443], authcBasic
/SoapService/** = *noSessionCreation*, ssl[8443], authcBasic
/** = ssl[8443], user, authc

"Web Service" generally means "pull data from server via the HTTP protocol"
and it can be done by either SOAP (which I would only recommend if you need
transactions) or REST (plain HTTP GET, PUT, POST, DELETE). With both SOAP
and REST you can use either session cookies or not, depending on what you or
your framework(s) prefer. If you decide not to use session cookies you would
have to send username and password on each request to pass authentication.
Do not send the login token as that is created form the username and
password from the request on the server during the authentication process.

I do not think EhCache is the proper tool here as it does not work on
distributed machines without an added layer for synchronization between
client and server and it completely bypasses HTTP and generally all Shiro
authentication mechanisms and instead stores and manipulates Shiro sessions
directly. We use EhCache to share Shiro's session cache for single sign on
between independent Java applications on the *same* server (independent war
files) - user logs in to one application and is automatically logged in to
the other applications, too.

Addressing your concerns about session hijacking / poisoning: that can
happen, too, when using EhCache and a synchronization layer. A friendly tip
on this behalf: It is generally considered impossible for a single person or
small group to pinpoint and solve all security issues introduced by modern
day applications. Instead one should use frameworks and tools which are in
wide-spread use and have been well tested over time to address security
issues. Using HTTP gives you the option to use TLS and a secure web
framework to harden your communication between client and server - these
tasks are generally well understood and you can find tons of information on
how to achieve this
(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). How to
secure EhCache and its underlying synchronization layer in contrast is a
task you would have to find out for yourselves.



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

Reply via email to