Re: Use of Session as a context bucket

[versatec <ro...@versatec.de>]

Quote: "i want our Services to be stateless and authenticate and authorise in
every request"
I would implement my services to be as stateless as may be and retrieve the
data from the SSO server on every request.
Now, if I understand correctly, you are trying to cache some data from the
SSO server. In my opinion, the clean way would be to retrieve the user
specific security context data on every request since on the SSO server
things might have changed during the meantime. Otherwise, you might be
giving users permissions which have been withdrawn recently?





--
View this message in context: http://shiro-user.582556.n2.nabble.com/Use-of-Session-as-a-context-bucket-tp7579404p7579414.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Use of Session as a context bucket

[versatec <ro...@versatec.de>]

I believe you can be sure your security data is specific to the authenticated
user if bound to shiro session and that it is disposed of when calling
session.stop(); at least that is how I read the API. 

Yet, quote from API:
"org.apache.shiro.session
Interface Session
  All Known Subinterfaces:
      ValidatingSession
  All Known Implementing Classes:
      DelegatingSession, *HttpServletSession*, ImmutableProxiedSession,
ProxiedSession, SimpleSession"

"public class HttpServletSession
extends Object
implements Session

Session implementation that is backed entirely by a standard servlet
container HttpSession instance. It does not interact with any of Shiro's
session-related components SessionManager, SecurityManager, etc, and instead
satisfies all method implementations by interacting with a servlet container
provided HttpSession instance. "

Does this mean your session's data might get leaked because the container
exposes its HttpServletSession to something I am not aware of? As far as I
understand it, in a web context the shiro session is actually an
HttpServletSession provided by the container.

Hm, not sure, not sure at all, but I would feel kind of uneasy not knowing
who / what has access to the session and whether sensitive data might get
leaked. 

Sorry, I do not know enough about this topic to assist you but maybe
somebody else?



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Use-of-Session-as-a-context-bucket-tp7579404p7579416.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Use of Session as a context bucket

[pparth <pp...@odesk.com>]

Thanks for your time!

Yes, i do all these things per request. I go to the SSO server per request
in order to authenticate. But, as a result of this call, we also get some
extra info that have to do with the user. E.g. the company and the team the
user is working for. We want this kind of info to be available later, in the
same request, in a nice way. But only until the request ends. I don't want
to persist this info any longer.
I know that i can keep this info into some request-scoped structure. But due
to the fact that this is security-related data, i would like to keep them
close to Shiro entities. e.g. i would like to say:
subject.getSecurityInfo(). As i don;t want to extend the subject, i found
that a possible place is to use the Session but only in a request-scoped
approach. I don't need to persist to datastore, i dont need caching etc. But
i really like the idea of using:
subject.getSession().getAttribute("securityInfo")
Can i setup Session to be used in this specific way?



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Use-of-Session-as-a-context-bucket-tp7579404p7579415.html
Sent from the Shiro User mailing list archive at Nabble.com.