You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by cgabbadon <cg...@informant-tech.com> on 2009/05/17 04:36:27 UTC
Re: Subject access outside of a web environment
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.
Re: Subject access outside of a web environment
Posted by 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
Posted by 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
Posted by 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
Posted by 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.