I thought about this a bit today, and I think the following on the SecurityManager interface (and then also SecurityUtils) would be suitable:
SecurityManager#getSubjectBySessionId( Serializable sessionId ); SecurityManager#getSubject(PrincipalCollection principals); Both methods would help framework developers - the first is useful in remoting/SSO scenarios, the 2nd useful in daemon process calls when you may not need to authenticate or have a session. The 2nd call is essentially what happens in a 'remember me' scenario when someone first visits a website without a session - the identity is assumed, but there is no initial session and it is not authenticated. Any objections from anyone? The interesting thing about these two methods is that they already exist as private/protected methods on the underlying DefaultSecurityManager implemetation - maybe the should exposed now that we have some decent use cases? - Les On Sun, May 17, 2009 at 3:45 PM, Les Hazlewood <[email protected]>wrote: > Hi Craig, > > There hasn't been much movement on this issue lately, but I started > thumbing through issues this weekend, and this is something I think we > should open up to end-users. I myself have found the need for this on > occasion, especially with my latest project - a distributed security > environment, with multiple SecurityManagers across more than one web > application. > > I'll post back to the list a little later today when I think I have a > decent solution to allow others to comment. If the community finds value in > the solution, we can definitely add it. > > Cheers, > > Les > > > On Sun, May 17, 2009 at 12:34 AM, cgabbadon > <[email protected]>wrote: > >> >> One thing I just noticed - I looked at the DefaultSecurityManager class >> and >> noticed the private method getSubjectBySessionId(Serializable sessionId) >> that seems to be what I'm looking for. Is there a reason why this is a >> private method instead of a public one? >> >> Thanks much, >> Craig >> >> >> Les Hazlewood-2 wrote: >> > >> > I was playing around with potential solutions this weekend for assumed >> > identity support as well as thinking about how to acquire a Subject >> > without >> > requiring a log in by the software developer and this issue: >> > >> > https://issues.apache.org/jira/browse/JSEC-17 >> > >> > is very much related to this thread. It goes back to being able to >> > acquire >> > a Subject instance based on some initial set of data. In SSO >> > applications, >> > that 'initial set of data' might be just an SSO Token (e.g. session id). >> > In >> > a daemon process, it could be a PrincipalCollection instance. Or maybe >> > its >> > just a single principal. >> > >> > I think we'll need to the ability to do this - not just get the >> 'current' >> > subject. >> > >> > Might this be related to assuming an identity? At first glance, I think >> > it >> > is an orthoganal issue. I'm not sure that this: >> > >> > securityManager.getSubject( initData ); >> > >> > is (or should be) semantically equivalent to this: >> > >> > Subject subject = securityManager.getSubject(); >> > subject.assumeIdentity( initData ); >> > >> > Thoughts? >> > >> > >> >> -- >> View this message in context: >> http://n2.nabble.com/Subject-access-outside-of-a-web-environment-tp1694632p2915136.html >> Sent from the JSecurity Developer mailing list archive at Nabble.com. >> >> >
