Hi there,
Please see inline:
> I use Spring but I do not use Spring Web MVC or any jsp or web based
> technologies.
The current IniShiroFilter (and all ShiroFilter implementations
actually) don't care about the underlying mvc technology - it works
purely as a standard ServletFilter, so it works in any Servlet
environment. It is responsible for four primary things:
1. Find out which user is making the request by looking at the
JSESSIONID and construct a Subject instance based on that id.
2. If using Shiro's native sessions, and the current request has a
session, update it's lastAccessTimestamp to ensure session timeout
calculations can work properly
3. Bind the Subject to the thread and let the request continue through
4. Finally clean up the thread (remove the Subject) even if there is
an error to ensure the thread remains 'clean' in a thread-pooled
environment.
> I currently expose my services using HttpInvokerServiceExporter but may make
> them web service endpoints and if I do I don't want to have to revisit the
> security at all.
>
> I really would prefer not to secure anything by url
You don't need to secure anything based on URL - that's purely a
preference. If you don't prefer it, that's totally ok - you'll then
need to choose one of the following two approaches:
1. Enable Shiro AOP and annotate methods with security restrictions
(e.g. @RequiresAuthentication, @RequiresPermission, etc) to act as
your enforcement mechanism. Currently the annotations can be enabled
by AspectJ or Spring AOP Alliance mechanisms.
2. Use the Subject.hasRole/isPermitted/isAuthenticated/etc methods directly.
The key to both of these mechanisms for any ServletRequest is to make
sure the ShiroFilter sits somewhere in the front of your FilterChain
for your application's URLs. Even if you don't use Shiro's
filter-based security, you'll still need it for Subject thread
assocation/cleanup. Also, there is some AspectJ sample code worth
looking at in the <project root>/samples/aspectj directory if you're
not going to use Spring AOP.
> I need to be able to show/hide different menu's/actions/commands in the
> client based on their permissions
I do this via a call to the Subject API:
if ( subject.isPermitted("email:send") ) {
//show the 'Send Email' button
}
The WicketStuff project [1] is has some even better Shiro-specific
integration that can give you an example of how to enable/disable UI
widgets based on Shiro roles and/or permissions (even if you don't use
Wicket - it has some good ideas).
For example:
Button button = new Button("send email) {
@Override
public boolean isVisible() {
return SecurityUtils.getSubject().isPermitted("email:send");
}
}
This code is loosely based on memory only - but at least it shows some
neat UI-specific functions Shiro can help you perform.
>
> I also need to filter data based on permissions/roles (I am thinking I will
> need to extend the permissions to be a rich object rather than just strings)
The org.apache.shiro.authz.Permission interface is the thing that
really matters - feel free to implement it however you like to support
any custom use cases. The WildcardPermission implementation is just
Shiro's default implementation to support the convenient string-based
permissions you see referenced regularly. If this isn't sufficient
for you, the right thing to do is to write your own implementation of
that interface. In all cases, Permission instances are what are
evaluated at runtime - not the strings.
> I will need to dynamically add roles and assign permissions to those roles.
> We service many clients and they can set up their security hierarchy in any
> way they choose
Yep, dynamic changing of authorization data is supported in Shiro - it
was a feature supported in our very first 0.1 release a long time ago.
The easiest way to support this is to use, say, an AuthorizingRealm
subclass that accesses your security data store, and any time a
user/group/role's authorization assignments change, you'll want to
invalidate any cached authorization data for that user via the
AuthorizingRealm#clearCachedAuthorizationInfo method. The next time
Shiro calls your realm to do a role or permission check for that user,
it will acquire the new authorization info - and then cached again for
performance.
> It obviously needs to be thread safe but I am not convinced I want to use
> the JSESSION/cookie protocol but maybe I do.
It's ok if you don't, but _something_ will need to build a Subject
instance based on data in the incoming request, bind it and then
unbind it after the thread's execution is finished. You can use
Shiro's spring-specific SecureRemoteInvocationExecutor's code [2] as
an example. It builds a subject based on request-specific data and
then uses the subject.execute method to guarantee thread-binding and
cleanup occur automatically. I highly recommend using the execute
method to do the thread work for you - it's elegant and it guarantees
cleanup
> What is the best configuration to use?
> Is there a way to simulate or utilize the way SpringSecurityContext holds
> onto its information in a ThreadLocal?
I'm sorry, I'm not familiar with the 'SpringSecurityContext'
mechanism, but Shiro's own mechanism is quite robust. Subject
construction for things like this as well as test cases or daemon work
is covered extensively in Shiro's Subject documentation [3]. And
again, you can use the SecureRemoteInvocationExecutor code as a
concrete example of how you might do this in your own environment if
you don't want to use the ShiroFilter's JSESSIONID cookie approach.
Anyway, I hope that helps!
Regards,
Les
[1] http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-shiro
[2]
http://svn.apache.org/repos/asf/incubator/shiro/trunk/support/spring/src/main/java/org/apache/shiro/spring/remoting/SecureRemoteInvocationExecutor.java
[3] http://incubator.apache.org/shiro/subject.html
