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 <ronald.fei...@scsynergy.de>
Sent: Thursday, October 13, 2016 4:38:23 AM
To: user@shiro.apache.org
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 via email to