web + EJB out-of-the-box support

[security <se...@intrawave.net>]

Hi,

    I am aware of Shiro working for a co-located web + EJB app.  Our 
usage would be for a JEE 5 based web & EJB/middle tier that are NOT 
co-located (different VM's).  Several posts exist asking about the EJB 
and RMI support.  Do these links serve as a good summary of Shiro's 
current state for none co-located EJB's:

http://shiro-user.582556.n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-td3773528.html
http://shiro-user.582556.n2.nabble.com/Questions-after-first-steps-with-Shiro-td5525922.html
http://shiro-user.582556.n2.nabble.com/Shiro-and-JEE-td6306065.html

    Has anyone else used Shiro for a none co-located EJB application?

Thank you, Michael

Re: web + EJB out-of-the-box support

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

Hi Michael,

I have done this once, and it was a PITA - but not so much on Shiro's
end, but due to the distributed architecture.

The best way to do this IMO is to define two Shiro environments:

The first is a 'standard' Shiro environment in your EJB tier - it uses
whatever Realms are necessary to talk to back-end data sources and
SessionDAOs to talk to Session stores.

The second is a 'proxy' Shiro environment in your web tier.  It would
be a standard Shiro web environment configuration, but you would
define only one Realm and one SessionDAO.  The Realm would be a
remoting endpoint that would call into your EJB tier to get the
AuthenticationInfo and AuthorizationInfo as necessary (the EJB tier
would then use its internal Shiro environment do do the 'real' lookup,
no matter how many Realms might be configured).  The SessionDAO would
be a remoting endpoint that calls into the EJB tier to get Session
objects.

You would want to make heavy use of caching in both environments IMO
to avoid constant remoting calls between the two.

The SessionDAO in the web tier makes an assumption - that the web tier
is the one managing session lifecycles (timeout, etc).  It is possible
to manage the sessions in the EJB tier as well, but it requires a more
intricate technique of ensuring a session ID is passed between both
tiers so they can both participate in it.

The latter approach is more 'correct' IMO, but it requires more work.

HTH,

-- 
Les Hazlewood
Founder, Katasoft, Inc.
Application Security Products & Professional Apache Shiro Support and Training:
http://www.katasoft.com

P.S. Note that this reply is meant to help for this particular
(existing) environment.  For others reading this, it is *not*
recommended to do this in any app that can avoid it.  Multiple
physical application tiers is a late 90's/early 2000's 'over
architecting' concept that Sun invented to help sell more hardware.
Locality is king in software performance, so applications should be in
the same JVM whenever possible.

On Mon, May 23, 2011 at 4:25 AM, security <se...@intrawave.net> wrote:
> Hi,
>
>   I am aware of Shiro working for a co-located web + EJB app.  Our usage
> would be for a JEE 5 based web & EJB/middle tier that are NOT co-located
> (different VM's).  Several posts exist asking about the EJB and RMI support.
>  Do these links serve as a good summary of Shiro's current state for none
> co-located EJB's:
>
> http://shiro-user.582556.n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-td3773528.html
> http://shiro-user.582556.n2.nabble.com/Questions-after-first-steps-with-Shiro-td5525922.html
> http://shiro-user.582556.n2.nabble.com/Shiro-and-JEE-td6306065.html
>
>   Has anyone else used Shiro for a none co-located EJB application?
>
> Thank you, Michael