>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 <[email protected]> Sent: Thursday, October 13, 2016 2:38:12 AM To: [email protected] 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.
