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.
