shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: Single Sign On (SSO), Spring, Hibernate Help.
Date Fri, 04 Mar 2011 20:12:07 GMT
On Fri, Mar 4, 2011 at 11:50 AM, Michael Angelo <mikeangelo@usa.net> wrote:
> Hey Les. Thanks for the thorough response. Yes. It is very confusing, but I am
> going to take the time to go thru this step by step. Even though I don't have
> any other choice, I am confident that Shiro can do this. I just have to shake
> out the cob webs from trying to 'force' Spring Security to do it since last
> weekend!
>
> Let's say that I do get all of your steps in place. Would I use Shrio API
> calls (mainly Session, Subject, etc) to then get the new 'region' info when my
> users change regions in my main code (ie. not filters)?

Yep, that would be the most likely.

> critical part. Without knowing what 'region' info is, basically I just need to
> load new permissions based on a 'region' which can be changed during the
> application.

How is the region change reflected in the app?  If a user's
permissions and roles change (authorization info), you can evict any
cached authz data via an AuthorizingRealm's
'clearCachedAuthorizationInfo' method (assuming you're using caching).
 Then, the next time an authorization check occurs, you will obtain
the 'fresh' authz data and that will be used moving forward.

I say this because a ThreadLocal could be used here.  If you store the
region in a ThreadLocal, then your implementation can work like this:

1.  When a user's region changes, call 'clearCachedAuthorizationInfo'
to evict any stored authz data for that Subject.  People often do this
by implementing a Listener interface to listen for region changes, and
the listener method in turn calls clearCachedAuthorizationInfo.

2.  In your doGetAuthorizationInfo implementation, you can look at the
Oracle SSO id and the ThreadLocal region.  From both of those you
would obtain the corresponding AuthorizationInfo.

> Am I understanding the DelegatingFilterProxy correctly? After setting up the
> first one that points to ShiroFilterFactoryBean, then I don't have to register
> any of my others in web.xml as long as they implment Filter and are registered
> beans? Any hints on how to set the init-params once the Filters become Spring
> beans?

So in Spring apps, Shiro will 'pick up' any defined
javax.servlet.Filter instance and make it available in chain
definitions by its bean name.  When  you define the Filter instances
in Spring, you don't need init params anymore - Spring typically
expects that you will configure whatever properties you need directly
on the Filter instance via JavaBeans setters, e.g.

<bean id="myFilter" class="...">
    <property name="prop1" value="value1"/>
    ...
</bean>

since this is more elegant and powerful than standard init-param behavior.

But just defining the filters in Spring will not automatically add
them to Shiro's filter chains.  You need to do that in the
ShiroFilterFactoryBean's 'filterChainDefinitions' property:

<property name="filterChainDefinitions">
    <value>
        /some/path = myFilter
        /another/path/** = anotherFilter, authc, ...
    </value>
</property>

> I will GLADY donate my OracleSSO realm or anyting else that I can if I can
> just figure this out.

Thanks!  Please do this as a patch to the project and open a Jira issue.

Best,

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

Mime
View raw message