How should we go about configuring a Desktop Client with Shiro in the Server?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

How should we go about configuring a Desktop Client with Shiro in the Server?

Malingo
This post has NOT been accepted by the mailing list yet.
Hello



I am a bit confused on the paradigm on how we are supposed to work our Application when we have 2 parts, a Desktop Client, and a Web Client on the server.   I have an INI set up on the server, but not sure how to go about connecting it up.

I would assume I would need to send login information via HTTP (using Apache HTTPClient), but I'm not sure how I would get information about users and such.

I notice that Session Data is what most applications use in order to verify the client, but the Session itself doesn't really contain much data, and I'm not 100% sure how I check to see the Sessions.

When creating new users and such, we need to get the SEcurity Manager, get a Subject and create the current user from the Subject... But the issue is that all that information is on the server.

Should I pass down my Factory or my Security Manager to the Desktop Application in order to get the information needed, or am I just going to contact the server each and every time to get a response (which seems a bit overkill/not-needed).  I'm just not sure if any of the information should be allowed into the Desktop application, just in case.

I am just curious how this will work for an Open Jar Java application that someone could maybe alter.  I am assuming that even if someone altered a "user.isAuthenticated()" it wouldn't matter because there is no information they can gain from altering to a yes, because everything resides on the server.


Essentially, I'm just curious what stays on the client, what goes on the server, and what information should the client receive, and how would I interact with the servlet/server?

Thanks a lot, sorry if this is a basic question, but I'm a bit confused on the best practices for this sort of thing...

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
All browsers handle sessions for you, so on the web client you need not check sessions but instead just do form authentication: https://shiro.apache.org/webapp-tutorial.html#step3 (you need not use a JSP page, any POST operation that results in the same HTTP request will work)
And then the browser will handle everything from there.

For the desktop client it depends very strongly on which technologies and frameworks you use to decide how best to handle everything. Just do not have the desktop client connect directly to your database and handle all the business logic itself. Especially, what you should not do is pass the SecurityManager or Subject to your clients. Instead keep all business logic on the server and have the clients just display data and offer buttons and such which trigger methods to run on the server.

Assuming that the desktop client and the web client offer the same functionality I suggest you create REST services to create users and such and then simply call those REST methods from within your desktop client and web client alike.

Depending on whether the desktop client and web client have already been implemented or not and which frameworks you use this may not be the best option, though.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse

Thanks for the information, I appreciate your time as does my friend.


That's interesting you don't need a JSP page, I thought that was needed in order to work with Shiro, but I guess that's just normal if you're going to make a JAva application with Shiro.


I believe his Desktop Client is JAvaFX, so there shouldn't be any issues, I would assume connecting.


So, essentially, everything gets done on the server, and only the responses should contain data that would be needed?  ie.., user.isauthenticated() we should just return true or false?   


All we really need to pass is the session cookie or whatnot?  I think he is using EHCache, which I really have no clue how that works (I assume the same for him).


I was looking at EHChache last night and it seems like it's something I should read up on to understand how they store.  Shiro Web Sessions seem to handle themselves, but it seems that Desktop sessions require more work.


Essentially the application is divided into 2 parts.  1 Part is a desktop portion that is for admins to manage users and  upload information to the server.  The other part, the web portion, is designed to allow users to use that information.


I have been looking at the terms "Web Service" and "REST" but not really sure what they fully encompass, or if there is something special needed for them to be called a "Web Service" or "REST" but it seems that if you call code on the server to run some CRUD or other operation that itself is a Web Service?


The functionality of both the Desktop and the Server have been implemented, but Shiro has not been really implemented properly on the client, which is what they are trying to fix now, not sure what aspect would change the answer to solving this, though.



Overall, it seems that we should NOT have anything related to Shiro on the Client, and everything should be sent via HTTP to the server for verification.  Now, do we just send the Session each time, or should we send the Login Token every time to verify?  I guess it doesn't really matter in the end as long as verification is present?  I know some people send the host information to the server to verify IP and such as well.  I guess we are just confused about the EHCache and how we verify the session with the Cache...  To me it sounds like sending the user token would be best, because you could prevent yourself from Session Poisoning/Session-hijacking, but that could also be said if their Username/Password was also stolen, but that's harder IMO.


Thanks a lot for helping us, I appreciate your time scSynergy :).


From: scSynergy <[hidden email]>
Sent: Wednesday, October 12, 2016 3:24:59 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
All browsers handle sessions for you, so on the web client you need *not*
check sessions but instead just do form authentication:
https://shiro.apache.org/webapp-tutorial.html#step3 (you need not use a JSP
page, any POST operation that results in the same HTTP request will work)
And then the browser will handle everything from there.

For the desktop client it depends very strongly on which technologies and
frameworks you use to decide how best to handle everything. Just do *not*
have the desktop client connect directly to your database and handle all the
business logic itself. Especially, what you should *not* do is pass the
SecurityManager or Subject to your clients. Instead keep all business logic
on the server and have the clients just display data and offer buttons and
such which trigger methods to run on the server.

Assuming that the desktop client and the web client offer the same
functionality I suggest you create REST services to create users and such
and then simply call those REST methods from within your desktop client and
web client alike.

Depending on whether the desktop client and web client have already been
implemented or not and which frameworks you use this may not be the best
option, though.



--
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-tp7581322p7581325.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse
In reply to this post by scSynergy

Sorry for the double email, but hit reply too fast.  I was looking at your comment about "not sending" the Subject, but isn't the Subject created based on the user's machine?  It seems that when you get the security info and then getSubject that it will get a Subject fo the current machine.  Is there some parameter that would change this, or does a call to "getSubject" return a new subject each time?  Why would it be bad to send the Subject data to the client, since it's really just their information, or anon if they aren't logged in?


Thanks for the help, appreciate it scSynergy.


From: scSynergy <[hidden email]>
Sent: Wednesday, October 12, 2016 3:24:59 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
All browsers handle sessions for you, so on the web client you need *not*
check sessions but instead just do form authentication:
https://shiro.apache.org/webapp-tutorial.html#step3 (you need not use a JSP
page, any POST operation that results in the same HTTP request will work)
And then the browser will handle everything from there.

For the desktop client it depends very strongly on which technologies and
frameworks you use to decide how best to handle everything. Just do *not*
have the desktop client connect directly to your database and handle all the
business logic itself. Especially, what you should *not* do is pass the
SecurityManager or Subject to your clients. Instead keep all business logic
on the server and have the clients just display data and offer buttons and
such which trigger methods to run on the server.

Assuming that the desktop client and the web client offer the same
functionality I suggest you create REST services to create users and such
and then simply call those REST methods from within your desktop client and
web client alike.

Depending on whether the desktop client and web client have already been
implemented or not and which frameworks you use this may not be the best
option, though.



--
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-tp7581322p7581325.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
In reply to this post by KonradZuse
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.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
In reply to this post by KonradZuse
It is not the Subject, but the SecurityManager which is based on the machine. So, the result of subject.isAuthenticated() on one machine can differ from subject.isAuthenticated() on another machine even for the same instance of 'subject'.

What 'getSubject' returns is entirely dependent on your configured realms (which are managed by the SecurityManager) and whether they use a cache or not. So, if you send the subject from the client to the server, it might behave differently on the server than on the client - a subject might be authenticated on the client but not on the server because the states of the two SecurityManagers differ.

Generally speaking the Shiro libraries should only be part of the server side application. The client should never use them if it is to authenticate against a server. The only exception to this rule I can think of is an offline capable Android app, but then you would need to synchronize (large) parts of your database between server and clients, anyway.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse
In reply to this post by scSynergy
>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 <img class="x_EmojiInsert" id="OWAEmoji520798" alt="&#55357;&#56842;" style="vertical-align:bottom" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABMAAAATCAYAAAByUDbMAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAYpJREFUeNpi/P//PwO1ACM2wf9njBWAVD4QBwCxApLUAyDeAMQTGU3OPkDRA3QUIxaD&#43;oFUAREOaQQa2IDTMKBB84FUAgk&#43;WwA0MBFmGBOaixJIDKYEoD6465igBjkge&#43;3CrW94TUCTr4eGMdxl8TCZxMYHDIZR1xk2HPiA1SCQOEgepA4J5CMbFgAPhM1vwfTFW9&#43;xGgYTh6lD1s8IdKIAkH4PEz1w9jOYVpBiZ1CQZMMw7MHzXwwPnv0Esx2MeRESxmcYWYCUAbJiFAVYAMgCbJbAvPmAWjmACZqS4aHdOOs5wdgEBcWE5a8Y0HIGPAIOwETtjXkYJqIqxAAgeQM1ThTzkQ2biB5mC7a8xZ7kgeICvMzoYTsRJaMDY3U9chIBpaMHz34xxPsKgwMcFIsLgckB5KL&#43;YllkgyYAg6oQJW9Ck8h&#43;5NgFhd3GAx/humAGI2cGIHYEGvYBW0YHGTgf2YX4MjkQF4IMwlkEIeXVfByGwsqzAwTLMywGg7wNcvED9AIR3TCAAAMAqh&#43;p&#43;YMVeBQAAAAASUVORK5CYII="> ).


>"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). How to
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 <[hidden email]>
Sent: Thursday, October 13, 2016 2:38:12 AM
To: [hidden email]
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 | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse
In reply to this post by scSynergy

I'm not sure why that last message sent when I was adjusting font size...


I guess these double emails continue ....




>It is not the Subject, but the SecurityManager which is based on the machine.
So, the result of subject.isAuthenticated() on one machine can differ from
subject.isAuthenticated() on another machine even for the same instance of
'subject'.



I don't have my code in front of me, but isn't the Subject created from the SecurtyManager?   It doesn't seem, from what you said before, that we would use subject.isauthenticated()  on the client  in this instance though, what instances would we use it then?

>What 'getSubject' returns is entirely dependent on your configured realms
(which are managed by the SecurityManager) and whether they use a cache or
not. So, if you send the subject from the client to the server, it might
behave differently on the server than on the client - a subject might be
authenticated on the client but not on the server because the states of the
two SecurityManagers differ.


well the basic subject seems to return username, password, host, I think IP, and a few other things, but I would assume we could create a one with a lot more information.  Is there only one subject per machine for each security manager, or can we create multiple subjects per machine?  I would assume that multiple instances of a Subject can be created since the server, in this case, would be the one to create Subjects, right?


I would assume that we wouldn't need the security manager in the client if we are doing all of the security on the server.


>Generally speaking the Shiro libraries should only be part of the server
side application. The client should never use them if it is to authenticate
against a server. The only exception to this rule I can think of is an
offline capable Android app, but then you would need to synchronize (large)
parts of your database between server and clients, anyway.


So nothing of Shiro should be on the user machine, or nothing but the security manager as you mentioned above?  Not sure how that fits. 


It makes sense that Shiro would just be on the server, but wasn't sure if it would be needed on the client at all.   I'm confused by what you meant by "Based on the machine"  I'm thinking that only one is created per machine, or did you mean that every instance is different per instance and the creation of Subjects is irrelevant?


Thanks.




One last thing about the session storage (if I go that route), it seems that EHCache does the comparison automatically, but how do we compare the sessions if we store it ourselves.  I'm not sure if I saw an example of that.  I assume we could send it as a request every time we refresh the page, which I assume is the same if we went stateless which would mean we would send the un/pw each time to authenticate?


I do like the stateless idea a lot...



Thanks so much for your time and help.


From: scSynergy <[hidden email]>
Sent: Thursday, October 13, 2016 4:38:23 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
It is not the Subject, but the SecurityManager which is based on the machine.
So, the result of subject.isAuthenticated() on one machine can differ from
subject.isAuthenticated() on another machine even for the same instance of
'subject'.

What 'getSubject' returns is entirely dependent on your configured realms
(which are managed by the SecurityManager) and whether they use a cache or
not. So, if you send the subject from the client to the server, it might
behave differently on the server than on the client - a subject might be
authenticated on the client but not on the server because the states of the
two SecurityManagers differ.

Generally speaking the Shiro libraries should only be part of the server
side application. The client should never use them if it is to authenticate
against a server. The only exception to this rule I can think of is an
offline capable Android app, but then you would need to synchronize (large)
parts of your database between server and clients, anyway.



--
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-tp7581322p7581331.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
In reply to this post by KonradZuse
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.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
In reply to this post by KonradZuse
The subject is a kind of proxy to the underlying SecurityManager meaning some methods of Subject actually just trigger calls to the SecurityManager which in turn triggers methods on the configured realms.

You would use subject.isAuthenticated() on the server's HTTP interface to determine whether to proceed with server side code or return an HTTP 401.

Your subject only returns username and password because the realm(s) you use creates a UsernamePasswordToken - other realms may create tokens which look entirely different.

Let Shiro create the subjects for you from your realms - it is designed to work that way, do not create subjects yourselves.

Nothing Shiro goes on the client.

"Based on the machine": The SecurityManager is created from your Shiro environment which would most likely differ between client and server - resulting in SecurityManagers which behave differently.

If you use Shiro the way it was designed it will compare the session on its own without you having to do it yourselves - that way, you need not store the sessions yourselves, either.

Just to be absolutely clear: We only configure the Shiro environment and the Shiro realms and let Shiro handle everything else on its own. Then clients request data or trigger business logic via HTTP requests - some using sessions (browsers) others without sessions (Java, .NET, Python). None of the clients does any authentication or authorization - they just pass credentials on to the server to request data from the server and display the data to the user; or they trigger business operations on that data via HTTP requests to the server. This architecture is what Shiro really caters to and excels at.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse

Firstly, I want to say thanks again so much for all of the time/effort putting into answering my questions, I appreciate it very much.  


Second, I want to apologize for not getting back to you in almost 2 weeks.  Recently a family member became extremely ill, so I haven't been able to get to a computer much.


I understand what you  are saying, thanks a lot for clarifying it for me.  One thing I am a little unsure about is if we config the web application, and Desktop-client application, to use the same setup/ini-file?  Essentially I notice that the Shiiro Environment is already set up when calling my servlet from the desktop app, so wouldn't it be redundant to create a Factory using the ini file and setting up the security manager and such to use for the Desktop-Client when it's already set up through the web application part?  It seems I can use things such as the FormAuthenticationFIlter and pass data to it and do request/response, but is that the correct way to handle this?  Do I want to do something programatically, or am I going to be doing this another way?  I'm a bit confused on how to proceed with doing this.


I'm assuming  I would work with the "web application" that is setup already?   However how do I call that ini file programatically, to work with it?  Is it the same as just using the factory setup as normal, or is there something special I should do here?  I am also having trouble locating the ini file in order to create a factory instance myself.  Normally I would use "classpath:(location)" but that doesn't seem to work with web app pathing.


Or maybe I'm confused that I need to do something programatically, when I don't have to, but I would assume if I'm accessing something such as "FormAuthenticationFilter" that at I would need to work programatically with it's request/response handler to properly handle the Desktop-Application.


Thanks a lot for your time I greatly appreciate it.


From: scSynergy <[hidden email]>
Sent: Friday, October 14, 2016 2:55:11 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
The subject is a kind of proxy to the underlying SecurityManager meaning some
methods of Subject actually just trigger calls to the SecurityManager which
in turn triggers methods on the configured realms.

You would use subject.isAuthenticated() on the server's HTTP interface to
determine whether to proceed with server side code or return an HTTP 401.

Your subject only returns username and password because the realm(s) you use
creates a UsernamePasswordToken - other realms may create tokens which look
entirely different.

Let Shiro create the subjects for you from your realms - it is designed to
work that way, do not create subjects yourselves.

Nothing Shiro goes on the client.

"Based on the machine": The SecurityManager is created from your Shiro
environment which would most likely differ between client and server -
resulting in SecurityManagers which behave differently.

If you use Shiro the way it was designed it will compare the session on its
own without you having to do it yourselves - that way, you need not store
the sessions yourselves, either.

Just to be absolutely clear: We only configure the Shiro environment and the
Shiro realms and let Shiro handle everything else on its own. Then clients
request data or trigger business logic via HTTP requests - some using
sessions (browsers) others without sessions (Java, .NET, Python). None of
the clients does any authentication or authorization - they just pass
credentials on to the server to request data from the server and display the
data to the user; or they trigger business operations on that data via HTTP
requests to the server. *This architecture is what Shiro really caters to
and excels at.*



--
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-tp7581322p7581336.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
The Shiro environment is only initialized on the server - not on the clients. The clients need not know Shiro even exists, since they only use regular HTTP requests with either Basic Authentication (desktop client [REST]) or Form Authentication (Browser [HTTP session]). The server is initialized once with one ini file to serve requests for both web and desktop clients.

All Shiro filters (including FormAuthenticationFilter) are located on the server to serve incoming HTTP requests from the clients. Clients create regular HTTP requests (without Shiro) and send those to the server where the filters process the requests according to the configured Shiro environment (ini file).

The desktop client needs to create HTTP requests in order to retrieve data from the server - no Shiro is involved on the client side.

It is easiest to initialize Shiro on the server via web.xml. If for whatever reason this is not an option you need to write a class including the following code:

import static javax.servlet.DispatcherType.ASYNC;
import static javax.servlet.DispatcherType.ERROR;
import static javax.servlet.DispatcherType.FORWARD;
import static javax.servlet.DispatcherType.INCLUDE;
import static javax.servlet.DispatcherType.REQUEST;
import javax.servlet.FilterRegistration;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import org.apache.shiro.authz.permission.WildcardPermission;
import org.apache.shiro.config.Ini;
import org.apache.shiro.web.env.EnvironmentLoaderListener;
import org.apache.shiro.web.env.WebEnvironment;
import org.ops4j.pax.shiro.cdi.web.CdiIniWebEnvironment;
...
@WebListener
public class ShiroInitializer extends EnvironmentLoaderListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        super.contextInitialized(sce);
        initializeShiro(sce);
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        super.contextDestroyed(sce);
    }

    @Override
    protected void customizeEnvironment(WebEnvironment environment) {
            String iniFile = loadFromDatabaseOrFilesystem();
            Ini ini = new Ini();
            ini.load(iniFile);
            environment.setIni(ini);
    }

    private void initializeShiro(ServletContextEvent sce) {
        FilterRegistration.Dynamic dynamic = sce.getServletContext().addFilter("ShiroFilter", "org.apache.shiro.web.servlet.ShiroFilter");
        dynamic.setAsyncSupported(true);
        EnumSet<DispatcherType> enumSet = EnumSet.of(REQUEST, FORWARD, INCLUDE, ERROR, ASYNC);
        dynamic.addMappingForUrlPatterns(enumSet, true, "/*");
    }
...
}
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse

Thanks for the information.  I understand that Shiro is not initialized on the client, I think I am just not wording my question well, so sorry about that.


Essentially I want to know how to access the ini and Shiro properties from my servlet in response to a request from the desktop-client.  As mentioned previously as shown in the docs we would place the ini file in a certain spot in the classpath and then create a factory out of it, and work from there.  This, from what I've seen would initialize everything, but in the case of a web-application it is already initialized, so I want to know how to work with/access the ini file in the case of accessing from the server?  I am also curious how I would access the FormAuthenticationFIlter, or another default Shiro class that would be setup in the ini file form the docs.  Should we create custom classes, and not rely on any of these defaults then in my case?


Thanks a lot for the help, much appreciated.




From: scSynergy <[hidden email]>
Sent: Thursday, October 27, 2016 2:14:52 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
The Shiro environment is only initialized on the server - *not* on the
clients. The clients need not know Shiro even exists, since they only use
regular HTTP requests with either Basic Authentication (desktop client
[REST]) or Form Authentication (Browser [HTTP session]). The server is
initialized once with one ini file to serve requests for both web and
desktop clients.

All Shiro filters (including FormAuthenticationFilter) are located on the
server to serve incoming HTTP requests from the clients. Clients create
regular HTTP requests (without Shiro) and send those to the server where the
filters process the requests according to the configured Shiro environment
(ini file).

The desktop client needs to create HTTP requests in order to retrieve data
from the server - no Shiro is involved on the client side.

It is easiest to initialize Shiro on the server via web.xml. If for whatever
reason this is not an option you need to write a class including the
following code:

import static javax.servlet.DispatcherType.ASYNC;
import static javax.servlet.DispatcherType.ERROR;
import static javax.servlet.DispatcherType.FORWARD;
import static javax.servlet.DispatcherType.INCLUDE;
import static javax.servlet.DispatcherType.REQUEST;
import javax.servlet.FilterRegistration;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import org.apache.shiro.authz.permission.WildcardPermission;
import org.apache.shiro.config.Ini;
import org.apache.shiro.web.env.EnvironmentLoaderListener;
import org.apache.shiro.web.env.WebEnvironment;
import org.ops4j.pax.shiro.cdi.web.CdiIniWebEnvironment;
...
@WebListener
public class ShiroInitializer extends EnvironmentLoaderListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        super.contextInitialized(sce);
        initializeShiro(sce);
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        super.contextDestroyed(sce);
    }

    @Override
    protected void customizeEnvironment(WebEnvironment environment) {
            String iniFile = loadFromDatabaseOrFilesystem();
            Ini ini = new Ini();
            ini.load(iniFile);
            environment.setIni(ini);
    }

    private void initializeShiro(ServletContextEvent sce) {
        FilterRegistration.Dynamic dynamic =
sce.getServletContext().addFilter("ShiroFilter",
"org.apache.shiro.web.servlet.ShiroFilter");
        dynamic.setAsyncSupported(true);
        EnumSet<DispatcherType> enumSet = EnumSet.of(REQUEST, FORWARD,
INCLUDE, ERROR, ASYNC);
        dynamic.addMappingForUrlPatterns(enumSet, true, "/*");
    }
...
}



--
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-tp7581322p7581343.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
I think I do not understand your questions - if Shiro has been already initialized on the server for the web application, then, why do it a second time? What do you mean with 'work with / access the ini file"? What do you mean by "access the FormAuthenticationFilter"? You do not need to access it, but instead specify it in the [url] section of the ini file. Then any user that sends a valid HTTP POST with valid HTML structure, username and password will automatically be authenticated by Shiro and you can check this by calling 'SecurityUtils.getSubject().isAuthenticated()' in your server side Java code.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse

I'm sorry, I was just very confused overall, and my explanations weren't all that good in the end.


Essentially, what I read in the docs and what I was using on the Client originally, is that you have the ini file setup in some folder and then call it in Java code by creating a factory and then creating other objects such as  Subject, or use the SecurityUtils(I think that's what it's called) class to do useful things.



I was confused if I use that on the server, or not, because I was having trouble locating the file path of the ini file, and getting it work when direct pathing to the ini file; however last night somehow the direct path worked and I have been able to log in and send data back for now.


The loginURL is specified to a certain link, do I just send my request it there?  I figured we could only send requests to Servlets, but we could access any page then, and send the request there?


I do want specific actions to be done than from the norm, so I'm not sure if I would create a special class (only the desktop client needs this info, not the web app).  Currently, as I said, I call the Factory and just do the code on the server, but maybe that isn't correct?  Everything seems to work as intended though.  Get user/pass, create factory and such, then create a token, pass token to user.login(), if it works then I get a 200 OK if not then I get a 500 Internal Server error and a message saying that the credentials are incorrect in my Tomcat logs created by Shiro.  If I'm authenticated then Shiro automatically creates the Session Cookie for the user.  


The only thing I've looked at changing was the SecurityManager when coding it myself on the server.  It doesn't seem to be needed to be called since it's already set up.  I also noticed that I had some weird loading issues if I didn't specify that authc = FormAuthenticationFilter, which I believe is supposed to automatically be set, but maybe I am wrong on that...  I have never had that issue before, and have been logging into the application fine from the browser.... weird....


From what you're saying we can just use the SecurityUtils class and manipulate things from there?  I was thinking about that earlier, but wasn't sure we didn't need more... So I don't need to create a Factory for the inifile then I wonder....???  BUt we still need a Servlet or special code to handle this, which would be different from the code in the ini file then?



By the way, I was curious if it's also difficult to set up SSL with Shiro?  I've seen some code on the "SSL Filter," but is that all we need for SSL?



Thanks for the help, much appreciated.


From: scSynergy <[hidden email]>
Sent: Thursday, October 27, 2016 7:07:02 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
I think I do not understand your questions - if Shiro has been already
initialized on the server for the web application, then, why do it a second
time? What do you mean with 'work with / access the ini file"? What do you
mean by "access the FormAuthenticationFilter"? You do not need to access it,
but instead specify it in the [url] section of the ini file. Then any user
that sends a valid HTTP POST with valid HTML structure, username and
password will automatically be authenticated by Shiro and you can check this
by calling 'SecurityUtils.getSubject().isAuthenticated()' in your server
side Java code.



--
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-tp7581322p7581345.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
If you configure the FormAuthenticationFilter to protect every HTTP request in the [urls] section (/** = authc) then users would not be able to access your login page without being authenticated. So, in order to let users access the login page you specify it in the ini file which causes Shiro to exempt it from access restrictions and also do an automatic redirect to the login page whenever someone tries to navigate to an URL without being authenticated.

You only need to enable Shiro via web.xml file as described here https://shiro.apache.org/webapp-tutorial.html#step1, chapter 1b: Enable Shiro in web.xml and configure Shiro via ini file and everything is ready to work. You do not need manipulate any SecurityManager, token, factory or whatsoever.

You need to supply a login page for browsers to authenticate through and some server side code (JSF, servlet, jax-rs ...) to handle requests and deliver data from the database to the client or trigger business methods on the database. This server side code must check whether SecurityUtils.getSubject().isAuthenticated() == true to execute the code or return an HTTP 401 otherwise. For REST requests you should use BasicAuthentication over TLS because it is built into Shiro. You can also use other authentication methods like OAuth tokens or something completely different but that is not provided out of the box and therefore must be somehow implemented by you beforehand.

This is what part of our ini file looks like - we only accept TLS connections to port 8443 and do not use a FormAuthenticationFilter but instead use a PassThroughAuthenticationFilter in combination with our own login page which differs from what the FormAuthenticationFilter would require:

[main]
...
authc = org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter
logout=org.apache.shiro.web.filter.authc.LogoutFilter
authc.loginUrl = /login.xhtml
authc.successUrl = /welcome.xhtml
logout.redirectUrl = /login.xhtml

[urls]
/login.xhtml = ssl[8443], 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], authc
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse

I'm really sorry it took me awhile to get back to you, I greatly appreciate your time and patience with my questions.


I tried to do /** = authc and got an issue where my Status code changed from a 200 OK to a 302 "FOUND" but I couldn't log in with the changes.


I am able to log in just fine using my own manual login attempt, but not sure if t is recommended, even though it works and is parft of Shiro's login scheme.




Yeah, I didn't realize that I could just called "SecurityUtils" until the end when looking at my code, and I thought I had to call a Factory in order to manipulate the subjetcs and such, which I was wrong.  Everything is setup in the web.xml file as shown in the docs.


Yeah, I have a login page setup for the browsers.  I notice that I get a 500 Internal server error whenever I am not logged in and try to do something.  Should I change that to a 401, or just leave it as a 500 error?  Nothing gets sent to the client, so I assume it's okay to just leave it as is?

Hmm, so with REST we want to use the built in Authentication?  Ia m using Apache HTTPClient, and there is a ecample for Basic Auth, but i thought the point is to send the credentials to Shiro, and then log into the application that way?  What is the point of the Basic Authentication?  Maybe I'm confused what exactly "Basic Authentication" requires.  Maybe this has something to do with SSL then, sinc eI haven't done the SSL portion for my Shiro config yet....

Is there specific ports we should use for TLS connections?  I believe I've seen 8443 used, so is that the default we should be using?  What's the difference between PassThrough and Form?  I'll check the docs also for that, but figured I would ask.  I don't think I need something different, since the Form works, but maybe there are better option for my need.


Now normally authc is default to the FormAuthetnicationFilter right?  I've had issues where adding the line would make a comment about it already existing, and sometimes it would ask me to add the authc = (when I was recreating the factory which was the wrong thing to do).

Thanks for the URL info, I still need to set taht up fully, but I think everything is okay.  I should try to see what would happen if I do my servlet page = autnc instead of /**.  I'm pretty sure I tried that also and still got the 302 FOUND status code..

Thanks a ton for the help, you're truly a lifesaver, I appreciate it., I've learned a lot.

From: scSynergy <[hidden email]>
Sent: Monday, October 31, 2016 2:20 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
If you configure the FormAuthenticationFilter to protect every HTTP request
in the [urls] section (/** = authc) then users would not be able to access
your login page without being authenticated. So, in order to let users
access the login page you specify it in the ini file which causes Shiro to
exempt it from access restrictions and also do an automatic redirect to the
login page whenever someone tries to navigate to an URL without being
authenticated.

You only need to enable Shiro via web.xml file as described here
https://shiro.apache.org/webapp-tutorial.html#step1, chapter 1b: Enable
Shiro in web.xml and configure Shiro via ini file and everything is ready to
work. You do *not* need manipulate any SecurityManager, token, factory or
whatsoever.

You need to supply a login page for browsers to authenticate through and
some server side code (JSF, servlet, jax-rs ...) to handle requests and
deliver data from the database to the client or trigger business methods on
the database. This server side code must check whether
SecurityUtils.getSubject().isAuthenticated() == true to execute the code or
return an HTTP 401 otherwise. For REST requests you should use
BasicAuthentication over TLS because it is built into Shiro. You can also
use other authentication methods like OAuth tokens or something completely
different but that is not provided out of the box and therefore must be
somehow implemented by you beforehand.

This is what part of our ini file looks like - we only accept TLS
connections to port 8443 and do not use a FormAuthenticationFilter but
instead use a PassThroughAuthenticationFilter in combination with our own
login page which differs from what the FormAuthenticationFilter would
require:

[main]
...
authc = org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter
logout=org.apache.shiro.web.filter.authc.LogoutFilter
authc.loginUrl = /login.xhtml
authc.successUrl = /welcome.xhtml
logout.redirectUrl = /login.xhtml

[urls]
/login.xhtml = ssl[8443], 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], authc




--
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-tp7581322p7581359.html
shiro-user.582556.n2.nabble.com
How should we go about configuring a Desktop Client with Shiro in the Server?. Hello I am a bit confused on the paradigm on how we are supposed to work our Application when we have 2 parts, a...


Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
If you cannot log in then something is wrong - did an exception get thrown or some other hint show up as to what might be the cause?

A failed login attempt should return an HTTP 401 response so as to behave in a way that most people would expect - but there is no technical reason for it.

Basic Authentication is the most simple and widespread means for authentication with REST services but it is definitely not a must. Also, BasicAuth sends username and password in clear text (base64 encoded is not encrypted) so in a production environment you should only use it in conjunction with TLS to prevent passwords from getting stolen. Depending on your needs and preferences you may want to use a different secure alternative instead, but that is totally up to you. I only recommend BasicAuth because it is easy to do since it is part of the HTTP specification and comes with lots of examples on the internet.

The port most people use for TLS is 443, we only use 8443 to prevent port conflicts with other applications running on the same server and because having non-root users open ports to listen below 1024 requires additional magic under unix.

Yes, FormAuthenticationFilter defaults to authc with Shiro. We only use the PassThruAuthenticationFilter because we do not need the additional features that FormAuthenticationFilter offers.
PassThruAuthenticationFilter
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

KonradZuse

Thanks for the info.


Yeah, I don't know what's up, but I just get the 302 "FOUND" status code, do you have any idea why that would be?  I will try to find out what gets passed down, or see if there is some sort of error, but it seems to not pass any error since it is "FOUND"| just not sure why that's the statuscode I get.


Gotcha, not sure if I would return the status code 401 or not, because I'm not sure if that information is relevant to the users over a "cannot log in" message,.

Thanks, I actually saw a comment on Apache HTTP"' Client that was talking about BASIC vs DIGEST authentication, so I'm assuming there are a few authentication schemes.


I see there are ways to use the built in HTTP/HTTPClient Login with authentication, but not sure if I'm supposed to work with that that, or just send the information to the servlet via a form login which is what I see mentioned in HTTPClient as a basic example?  I didn't think there was a special way to do this, and the example on HTTPClient just shows us how to create a form as if we were logging in a web page.  Is there something special I must tdo in order to do this "correctly?"  I'm a litle confused what the difference between just sending the username/password as a form request over a "BASIC AUTH" would be....  I'll check onto the wiki and such so that might also answer my question.



Thanks for the info on TLS I'll try to setup it properly, but not sure if users will have issues with non-admin access.  My target should be pretty much only Windows machines I would assume.




I noticed from looking at the docs that essentially the PassThru filter will send everything to the loginUrl, which they said is something you do if you have created your own login scheme and calling .login(token) yyourself?  I'm assuming most people will use the formauthentnication filter?  "I'll check out to see what hte differences are.  I might use this eventually since I need to set up my own Authentication class at some point, but maybe there is another filter that might be better, but this seemst o be the one if you use it with your own login code, at least that's what the docs mention.




Also, I thought I read somewhere that Shiro only works with Servlet spec 2.5?  I notice I am using that spec in my Web.xml, but I am curious if I should upgrade to something better such as 3.1?  I have a feeling that I lowered my spec because I was using Tomcat 6 originally, but now that I'm using Tomcat8 I feel that it might be better to Upgrade.  I'm just not sure if there are any issues with upgrading that could affect my Libraries/projects.


Is there anything to worry about when upgrading specs that might affect Shiro/Other Apache Products?  I'm pretty sure I saw something that specifically mentioned we should use 2.5 in Shiro, but cannot find that information now so 'i don't know what the truth is.

From what I read in 3.0+ we can use certain methods to get multi-part entities read, or else we have to use another library such as Apache FileUpload which I've used before if we use Servlet Spec 2.5...?



Thanks for all of the help, much appreciated.


From: scSynergy <[hidden email]>
Sent: Wednesday, November 16, 2016 2:22:37 AM
To: [hidden email]
Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server?
 
If you cannot log in then something is wrong - did an exception get thrown or
some other hint show up as to what might be the cause?

A failed login attempt should return an HTTP 401 response so as to behave in
a way that most people would expect - but there is no technical reason for
it.

Basic Authentication
<https://en.wikipedia.org/wiki/Basic_access_authentication>   is the most
simple and widespread means for authentication with REST services but it is
definitely not a must. Also, BasicAuth sends username and password in clear
text (base64 encoded is *not* encrypted) so in a production environment you
should only use it in conjunction with TLS to prevent passwords from getting
stolen. Depending on your needs and preferences you may want to use a
different secure alternative instead, but that is totally up to you. I only
recommend BasicAuth because it is easy to do since it is part of the HTTP
specification and comes with lots of examples on the internet.

The port most people use for TLS is 443, we only use 8443 to prevent port
conflicts with other applications running on the same server and because
having non-root users open ports to listen below 1024 requires additional
magic under unix.

Yes, FormAuthenticationFilter defaults to authc with Shiro. We only use the
PassThruAuthenticationFilter because we do not need the additional features
that FormAuthenticationFilter offers.
PassThruAuthenticationFilter
<https://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/web/filter/authc/PassThruAuthenticationFilter.html




--
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-tp7581322p7581390.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: How should we go about configuring a Desktop Client with Shiro in the Server?

scSynergy
Sorry, I have no idea where the 302 might originate from.

You would use the web form for the web client and BasicAuth for the requests from the desktop client to the REST services since the desktop client is probably not designed to handle web pages (string parsing is just sooo awful). If you have some service exposed via REST and secured through Shiro with BasicAuth, then a user with a valid session (previously acquired via the login form) will be able to call said REST service without any need to reauthenticate again via BasicAuth.

Sending username / password as a form request is done via HTTP POST, BasicAuth on the other hand can be used with anything (GET, PUT, HEAD, OPTIONS, DELETE, PROPFIND, MKCOL ...).

Yes, we do Subject.login(token) in our backing bean manually because the FormAuthenticationFilter will always fail while trying to call login(token) automatically since our web page differs from what FormAuthenticationFilter expects.

Shiro works with servlet spec 3+ so feel free to upgrade - we use Shiro on Wildfly 10 which comes with fairly recent libraries and we never had issues with Shiro.