Re: Using Shiro in a Web + EJB environment

[Narcom <na...@yahoo.com>]

I also need Web + EJB + Standalone client integration. is there any example
available how to use CacheManager?


Les Hazlewood-2 wrote:
> 
> On Tue, Oct 6, 2009 at 2:07 PM, Jaco <ja...@gmail.com> wrote:
>> Not having access to the annotations isn't a train wreck (I guess I could
>> always write my own Interceptor), as long as I can still do everything
>> programmatically. The part that I'm missing is how to configure Shiro in
>> my
>> EJB project (specifically the realm). For comparison in order to
>> configure
>> Shiro in my Web application I'd register the ShiroFilter and set the
>> config
>> param.
> 
> That hasn't been worked out to a 'standard way', so to speak.
> 
> The absolutely minimal thing required to work is that a
> SecurityManager instance has been created and that it has been
> configured with 1 or more realms.  In simple Java code (non-web
> environment):
> 
> DefaultSecurityManager securityManager = new
> org.apache.shiro.mgt.DefaultSecurityManager();
> Collection<Realm> myRealms = acquireOrInitOneOrMoreRealms();
> securityManager.setRealms(myRealms);
> 
> Then this securityManager instance must be made available to the
> application, both to any components that need to access it directly as
> well as to SecurityUtils so the methods on that class function
> properly.
> 
> So, I guess that could mean wrapping up the securityManager instance
> in an SLSB (or subclass DefaultSecurityManager and create, say,
> Ejb3SecurityManager, and use annotations where necessary).
> 
> Also, there needs to be an interceptor for every method invocation
> and/or request that binds the securityManager and a Subject instance
> to the currently running thread.  That is essentially what the
> ShiroFilter does in the web environment - it just triggers this logic
> based on a ServletRequest instead of a method invocation.  The code
> that does this creation/binding has been greatly simplified this past
> month, so it should be very easy to enable it in an EJB interceptor -
> just look at the ShiroFilter source code as an example.
> 
>> I see what you're saying and I can imagine that the number of remote
>> invocations would be prohibitively large in most non-trivial cases. As a
>> (hopefully) quick aside, how does Shiro store session values on the
>> EJB-tier?
> 
> When not using the Servlet container for session management (i.e. any
> app that is not web-based or web-based apps where the business tier
> and web tier must access the same session), all Session state is done
> via a SessionDAO, so the implementation of that interface is entirely
> up to you to do persistence however you want.
> 
> By default, Shiro uses a CachingSessionDAO which uses a CacheManager
> to store the sessions in a Cache.  In practice, people in enterprise
> environments are expected to configure a CacheManager that is backed
> by an enterprise caching product like
> TerraCotta/Coherence/GigaSpaces/etc, as this is without question the
> most efficient way to store sessions, especially for larger
> applications.  People sometimes write their own (e.g. JdbcSessionDAO),
> but of course this is much less efficient than the enterprise caching
> approach.
> 
>>> You could always post your needs in a Jira issue if you can't foresee
>>> doing this yourself and we'll see if we can accommodate, but I
>>> personally am hoping the community will step up and contribute to this
>>> cause.
>>>
>>
>> Thanks, but like I mentioned earlier, due to timelines this probably
>> won't
>> work for me (waiting for updates which, given the complexity, might take
>> quite a while). But hey, thanks for the good work done on Shiro thus far.
>> I
>> really like the concept behind it and I feel that there is a definite
>> need
>> for such a solution, as container-managed security just doesn't cut it in
>> some cases.
> 
> Thanks for the encouragement!  We'll be here if you find the time to
> contribute :)
> 
> Best,
> 
> Les
> 
> 

-- 
View this message in context: http://n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-tp3773528p3937327.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Using Shiro in a Web + EJB environment

[Narcom <na...@yahoo.com>]

I think that possible solution would be create singleton in EJB container and
set reference to Shiro security manager. As I understand if web and ejb
container works in the the JVM value will be past by "reference" 
but.. I had no time to check it...
-- 
View this message in context: http://n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-tp3773528p4063075.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Using Shiro in a Web + EJB environment

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

Hi there,

Web applications that are colocated (in process) with an EJB
application will already function out-of-the-box if all requests go
through the ShiroFilter.  We don't have support beyond this scenario
(e.g. RMI to an EJB directly) yet.

Shiro definitely can be used for all scenarios an EJB/JEE environment,
but no-one on the team has spent the time to make this officially
supported.  I think most of us spend time working on web and
IoC-container--based applications, so naturally there is first-rate
support for those environments.

That being said, I for one would _love_ it if someone would be willing
to work on and contribute to the project to ensure that JEE is nicely
supported as well.  It would not be hard at all.

If anyone is interested in this, please post to the list and I'll help
along the way.

The key thing to getting this to work is to have an AOP mechanism that
can be used effectively.  You could use container-specific AOP APIs,
but that's not an ideal approach in my opinion since you would be
duplicating effort for every JEE container.  I haven't looked at the
latest JEE/EJB specs lately to know if there are common ways to define
EJB method interceptors and do other similar AOP functions.

- Les

On Wed, Nov 11, 2009 at 9:45 PM, javamallu <bi...@gmail.com> wrote:
>
> Hi,
>
> Just want to check whether there will be any implication if I use Shiro in
> EJB3.1 environment. We are planning to migrate our EJB3 application to
> 3.1(JEE6). Will you be releasing a new version for JEE6?
>
> Thanks
>
> Narcom wrote:
>>
>> I also need Web + EJB + Standalone client integration. is there any
>> example available how to use CacheManager?
>>
>>
>> Les Hazlewood-2 wrote:
>>>
>>> On Tue, Oct 6, 2009 at 2:07 PM, Jaco <ja...@gmail.com> wrote:
>>>> Not having access to the annotations isn't a train wreck (I guess I
>>>> could
>>>> always write my own Interceptor), as long as I can still do everything
>>>> programmatically. The part that I'm missing is how to configure Shiro in
>>>> my
>>>> EJB project (specifically the realm). For comparison in order to
>>>> configure
>>>> Shiro in my Web application I'd register the ShiroFilter and set the
>>>> config
>>>> param.
>>>
>>> That hasn't been worked out to a 'standard way', so to speak.
>>>
>>> The absolutely minimal thing required to work is that a
>>> SecurityManager instance has been created and that it has been
>>> configured with 1 or more realms.  In simple Java code (non-web
>>> environment):
>>>
>>> DefaultSecurityManager securityManager = new
>>> org.apache.shiro.mgt.DefaultSecurityManager();
>>> Collection<Realm> myRealms = acquireOrInitOneOrMoreRealms();
>>> securityManager.setRealms(myRealms);
>>>
>>> Then this securityManager instance must be made available to the
>>> application, both to any components that need to access it directly as
>>> well as to SecurityUtils so the methods on that class function
>>> properly.
>>>
>>> So, I guess that could mean wrapping up the securityManager instance
>>> in an SLSB (or subclass DefaultSecurityManager and create, say,
>>> Ejb3SecurityManager, and use annotations where necessary).
>>>
>>> Also, there needs to be an interceptor for every method invocation
>>> and/or request that binds the securityManager and a Subject instance
>>> to the currently running thread.  That is essentially what the
>>> ShiroFilter does in the web environment - it just triggers this logic
>>> based on a ServletRequest instead of a method invocation.  The code
>>> that does this creation/binding has been greatly simplified this past
>>> month, so it should be very easy to enable it in an EJB interceptor -
>>> just look at the ShiroFilter source code as an example.
>>>
>>>> I see what you're saying and I can imagine that the number of remote
>>>> invocations would be prohibitively large in most non-trivial cases. As a
>>>> (hopefully) quick aside, how does Shiro store session values on the
>>>> EJB-tier?
>>>
>>> When not using the Servlet container for session management (i.e. any
>>> app that is not web-based or web-based apps where the business tier
>>> and web tier must access the same session), all Session state is done
>>> via a SessionDAO, so the implementation of that interface is entirely
>>> up to you to do persistence however you want.
>>>
>>> By default, Shiro uses a CachingSessionDAO which uses a CacheManager
>>> to store the sessions in a Cache.  In practice, people in enterprise
>>> environments are expected to configure a CacheManager that is backed
>>> by an enterprise caching product like
>>> TerraCotta/Coherence/GigaSpaces/etc, as this is without question the
>>> most efficient way to store sessions, especially for larger
>>> applications.  People sometimes write their own (e.g. JdbcSessionDAO),
>>> but of course this is much less efficient than the enterprise caching
>>> approach.
>>>
>>>>> You could always post your needs in a Jira issue if you can't foresee
>>>>> doing this yourself and we'll see if we can accommodate, but I
>>>>> personally am hoping the community will step up and contribute to this
>>>>> cause.
>>>>>
>>>>
>>>> Thanks, but like I mentioned earlier, due to timelines this probably
>>>> won't
>>>> work for me (waiting for updates which, given the complexity, might take
>>>> quite a while). But hey, thanks for the good work done on Shiro thus
>>>> far. I
>>>> really like the concept behind it and I feel that there is a definite
>>>> need
>>>> for such a solution, as container-managed security just doesn't cut it
>>>> in
>>>> some cases.
>>>
>>> Thanks for the encouragement!  We'll be here if you find the time to
>>> contribute :)
>>>
>>> Best,
>>>
>>> Les
>>>
>>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-tp3773528p3990469.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Using Shiro in a Web + EJB environment

[javamallu <bi...@gmail.com>]

Hi,

Just want to check whether there will be any implication if I use Shiro in
EJB3.1 environment. We are planning to migrate our EJB3 application to
3.1(JEE6). Will you be releasing a new version for JEE6?

Thanks 

Narcom wrote:
> 
> I also need Web + EJB + Standalone client integration. is there any
> example available how to use CacheManager?
> 
> 
> Les Hazlewood-2 wrote:
>> 
>> On Tue, Oct 6, 2009 at 2:07 PM, Jaco <ja...@gmail.com> wrote:
>>> Not having access to the annotations isn't a train wreck (I guess I
>>> could
>>> always write my own Interceptor), as long as I can still do everything
>>> programmatically. The part that I'm missing is how to configure Shiro in
>>> my
>>> EJB project (specifically the realm). For comparison in order to
>>> configure
>>> Shiro in my Web application I'd register the ShiroFilter and set the
>>> config
>>> param.
>> 
>> That hasn't been worked out to a 'standard way', so to speak.
>> 
>> The absolutely minimal thing required to work is that a
>> SecurityManager instance has been created and that it has been
>> configured with 1 or more realms.  In simple Java code (non-web
>> environment):
>> 
>> DefaultSecurityManager securityManager = new
>> org.apache.shiro.mgt.DefaultSecurityManager();
>> Collection<Realm> myRealms = acquireOrInitOneOrMoreRealms();
>> securityManager.setRealms(myRealms);
>> 
>> Then this securityManager instance must be made available to the
>> application, both to any components that need to access it directly as
>> well as to SecurityUtils so the methods on that class function
>> properly.
>> 
>> So, I guess that could mean wrapping up the securityManager instance
>> in an SLSB (or subclass DefaultSecurityManager and create, say,
>> Ejb3SecurityManager, and use annotations where necessary).
>> 
>> Also, there needs to be an interceptor for every method invocation
>> and/or request that binds the securityManager and a Subject instance
>> to the currently running thread.  That is essentially what the
>> ShiroFilter does in the web environment - it just triggers this logic
>> based on a ServletRequest instead of a method invocation.  The code
>> that does this creation/binding has been greatly simplified this past
>> month, so it should be very easy to enable it in an EJB interceptor -
>> just look at the ShiroFilter source code as an example.
>> 
>>> I see what you're saying and I can imagine that the number of remote
>>> invocations would be prohibitively large in most non-trivial cases. As a
>>> (hopefully) quick aside, how does Shiro store session values on the
>>> EJB-tier?
>> 
>> When not using the Servlet container for session management (i.e. any
>> app that is not web-based or web-based apps where the business tier
>> and web tier must access the same session), all Session state is done
>> via a SessionDAO, so the implementation of that interface is entirely
>> up to you to do persistence however you want.
>> 
>> By default, Shiro uses a CachingSessionDAO which uses a CacheManager
>> to store the sessions in a Cache.  In practice, people in enterprise
>> environments are expected to configure a CacheManager that is backed
>> by an enterprise caching product like
>> TerraCotta/Coherence/GigaSpaces/etc, as this is without question the
>> most efficient way to store sessions, especially for larger
>> applications.  People sometimes write their own (e.g. JdbcSessionDAO),
>> but of course this is much less efficient than the enterprise caching
>> approach.
>> 
>>>> You could always post your needs in a Jira issue if you can't foresee
>>>> doing this yourself and we'll see if we can accommodate, but I
>>>> personally am hoping the community will step up and contribute to this
>>>> cause.
>>>>
>>>
>>> Thanks, but like I mentioned earlier, due to timelines this probably
>>> won't
>>> work for me (waiting for updates which, given the complexity, might take
>>> quite a while). But hey, thanks for the good work done on Shiro thus
>>> far. I
>>> really like the concept behind it and I feel that there is a definite
>>> need
>>> for such a solution, as container-managed security just doesn't cut it
>>> in
>>> some cases.
>> 
>> Thanks for the encouragement!  We'll be here if you find the time to
>> contribute :)
>> 
>> Best,
>> 
>> Les
>> 
>> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-tp3773528p3990469.html
Sent from the Shiro User mailing list archive at Nabble.com.