Re: Subject access outside of a web environment

[Les Hazlewood <lh...@apache.org>]

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?

On Wed, Dec 31, 2008 at 2:09 PM, Jeremy Haile <jh...@fastmail.fm> wrote:

> Yeah - in my mind the web-specific portion of the subject binding is
> actually the filter (who binds it to the thread local).  But there are lots
> of cases where the thread local stuff is useful (offline clients, daemon
> threads, and yes, web clients)  But I'm open to better ideas for doing this
> that make it more cross platform.  No matter which solution we do, it will
> be easy for the end user to access, so it's really a behind-the-scenes
> question for the most part.
>
>
>
> On Dec 31, 2008, at 12:49 PM, Les Hazlewood wrote:
>
>  On Wed, Dec 31, 2008 at 10:40 AM, Jeremy Haile <jh...@fastmail.fm>
>> wrote:
>>
>>>
>>> This may even eliminate the need entirely for a Thread-bound
>>> ServletRequest
>>>
>>>> and ServletResponse.  They were originally bound to the thread
>>>> specifically
>>>> to aid in Subject construction.  But I'd have to see whether or not a
>>>> thread-bound request/response is used in other ways before we can
>>>> definitively say binding is not necessary anymore.
>>>>
>>>>
>>> Not totally accurate in my opinion - the ThreadLocal is used so that we
>>> can
>>> access the subject anywhere without having to get access to JSecurity
>>> objects, such as the SecurityManager.  This to me implies one of two
>>> things
>>> a) you're proposing we store the Subject in the session or b) the
>>> security
>>> manager is pulling stuff out of the session and constructing a subject
>>> every
>>> time you ask for it.
>>>
>>
>>
>> I didnt' say anything about how the Subject is stored/accessed :).  I was
>> talking about a "Thread-bound ServletRequest
>> and ServletResponse".   But, after thinking about this, and based on your
>> reply, then maybe we need to still do that in a web environment so the
>> WebAccessor has something to pull from.
>>
>> Consider this alternate implementation of JSecurityFilter's
>> doFilterInternal
>> method.  Hopefully it will illustrate my thoughts:
>>
>> HttpServletRequest request = (HttpServletRequest) servletRequest;
>> HttpServletResponse response = (HttpServletResponse) servletResponse;
>>
>> //here is where we bound the InetAddress - maybe not necessary anymore
>>
>> //construct JSecurityHttpServletRequest/JSecurityHttpServletResponse same
>> as
>> in
>> //existing implementation
>>
>> //here is where we called WebUtils.bind(request)/.bind(response) - maybe
>> not
>> necessary anymore.
>>
>> Subject subject = getSecurityManager().getSubject( new HttpPair(request,
>> response) );
>> ThreadContext.bind(subject);
>> ThreadContext.bind(getSecurityManager());
>>
>> FilterChain chain = getConfiguration().getChain(request, response,
>> origChain);
>>
>> //rest of the implementation stays the same...
>>
>> Again, I don't know if this is the way it should work, its just an idea.
>> Maybe
>>
>> getSubject( new HttpPair(request, response) );
>>
>> is never called.  Maybe the request and the response ARE bound to the
>> thread, and the WebAccessor implementation knows to pull them off of the
>> thread when building the subject upon the very first request to
>> securityManager.getSubject().
>>
>> Maybe that's the cleanest way to go - I dunno yet ;)
>>
>> Automatically assuming a Thread-based model causes problems that could be
>>
>>> easily mitigated by this approach (for example, in a daemon environment,
>>>> when the thread executing isn't the same as a user request).  Lots of
>>>> flexibility there.
>>>>
>>>>
>>> Well - there are ways to support a thread-based model, even for daemon
>>> threads.  And I think daemon threads are even harder to support by
>>> assuming
>>> a request/response based model.
>>>
>>
>>
>> I'm not assuming any model - that's up to the Accessor implementation.
>>  One
>> implementation could use the ThreadContext.  Another can use Http
>> request/response pairs.  Another can pull it from a file if it is a
>> desktop
>> app.  Sure the daemon-compatible implementation can use the ThreadContext
>> -
>> I'm just saying that the SecurityManager doesn't need to know that - it is
>> up to the Accessor implementation.
>>
>> But, let's say we leave the Accessor out of it.  We'll probably need
>> securityManager.getSubject( initData) just to suport
>> runAs/assumedIdentity,
>> where 'initData' is the identiy being assumed...
>>
>
>

Re: Subject access outside of a web environment

[cgabbadon <cg...@informant-tech.com>]

Hi Les,

I think that exposing those two methods works just fine.  I think it makes
sense since they are already there and it obviously wouldn't be invasive or
anything to expose them now.  Last night I actually made the
getSubjectBySessionId a public method for my project, and it worked just as
I needed it to.  No objections on this side :-).

Craig


Les Hazlewood-2 wrote:
> 
> 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
> 
> 

-- 
View this message in context: http://n2.nabble.com/Subject-access-outside-of-a-web-environment-tp1694632p2929020.html
Sent from the JSecurity Developer mailing list archive at Nabble.com.

Re: Subject access outside of a web environment

[Les Hazlewood <lh...@apache.org>]

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 <lh...@apache.org>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 <cg...@informant-tech.com>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.
>>
>>
>

Re: Subject access outside of a web environment

[Les Hazlewood <lh...@apache.org>]

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 <cg...@informant-tech.com>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.
>
>

Re: Subject access outside of a web environment

[cgabbadon <cg...@informant-tech.com>]

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.

Re: Subject access outside of a web environment

[cgabbadon <cg...@informant-tech.com>]

Is there any update on  https://issues.apache.org/jira/browse/KI-22 this
issue ?  I am getting into the Apache Ki project and I believe I am running
into this exact issue.  Basically, it would be ideal to get a Subject using
some data, such as the session ID, as I am trying to use Ki outside of the
typical web application context.  Since getting a session/subject seems to
be tied to the thread context coming from an InetAddress, I can't get the
proper subject.

I'm a bit new to Apache Ki, so forgive me if I am missing anything obvious. 
It's a great project based on my experience so far.  What I'm trying to do
is implement something similar to 
http://blogs.sun.com/indira/entry/rest_based_identity_services_in OpenSSO's
REST interface .  So basically, I would like to have a dedicated Apache Ki
powered security service application that is functioning as a simple
identity management/SSO/security service solution that other applications
can use via a REST interface or something else.

If you take a look at OpenSSO's REST interface, it uses the session id token
(returned from a successful authentication request) in a similar way.  I'm
not saying this is exactly how it should be done, of course - just pointing
it out.

Any suggestions?

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-tp1694632p2914755.html
Sent from the JSecurity Developer mailing list archive at Nabble.com.