Hi Darren,
I had a couple of thoughts. I've needed something similar and achieved
it by implementing a custom rest filter and using that.
Instead of logging anonymous users in, I've left them anonymous and in
the custom rest filter checked the HTTP Method they are using and then
as appropriate their role/permission.
For example (in pseudo code):
if(HTTP Method == get)
return okay;
else
if(subject.isAuthenitcated() == false)
return not okay;
if(subject.hasRole(role))
return okay;
return not okay;
That lacks the flexibility of the default rest filter but that
flexibility can be achieved (more or less) by doing something like
Daniel describes in the main part of
https://issues.apache.org/jira/browse/SHIRO-459. You can use the
arguments to a filter to define HTTP Method and required
role/permission. My custom filter recognizes an "anon" that lets anyone
access through that method.
My shiro.ini looks like:
rest = com.hcs.webtl.shiro.filter.RESTAuthorizationFilter
/users/** = noSessionCreation, rest[POST-anon,PUT-anon,DELETE-admin]
Rest is my custom filter (not the default rest filter) and allows
anonymous POST and PUT, but you must have admin role/permission to
execute a DELETE. GET is forbidden for everyone.
Hope that helps!
Sincerely,
Stephen McCants
On 9/25/2013 6:45 PM, davison wrote:
Hi everyone,
I've been struggling with what I think should be a trivial security issue
for
well over a week (which is almost as long as it took me to write this
simple app in its entireity!) Having spent quite a long time now going
through
the source code for Shiro and the docs, I think I've concluded that what I
want to do isn't possible without re-implementing core parts of the
framework.
So I hope someone can prove me wrong :)
My app is basically a simple server-side API for some REST clients,
principally
an HMTL5 front end. I need some of the resources to be accessible to an
anonymous user for reading, but not for create/update/delete.
For example;
GET /api/foo (ok for UNauthenticated/anonymous user)
PUT /api/foo (requires admin role)
There are some secondary requirements which are also problematic, but they
are
moot if this one can't be solved easily.
Should be simple, but here's why I think this looks impossible..
To base my permissions on the HTTP method, I need to use the 'rest' filter
(HttpMethodPermissionFilter). However, this has no way to specify that some
permissions are accessible for the anonymous user - because ANY set of
permissions requires an authenticated subject (see the various
DelegatingSubject.isPermitted() methods that all start with a requirement
that
current principals exist).
I even created my own filter that would programatically "login" a user named
"anonymous" (defined in my realm) that could be given suitable permissions,
and
this works in isolation;
public class AnonymousRoleAuthenticationFilter extends OncePerRequestFilter
{
@Override
public void doFilterInternal(
ServletRequest request,
ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
Subject subject = SecurityUtils.getSubject();
if (subject.getPrincipals() == null ||
subject.getPrincipals().isEmpty())
{
subject.login(new UsernamePasswordToken("anonymous",
"anonymous"));
}
chain.doFilter(request, response);
}
}
// realm config below...
user.admin=s3cr3t,admin
user.anonymous=anonymous,anonymous
role.admin=*
role.anonymous=*:read
But if this filter sits before any other (like authcBasic) that I use to
gather
credentials from an admin user, then the admin credentials will never be
requested because there is already an authenticated subject.. he just
doesn't have permission. If I reverse the order of those filters, then I
will
incorrectly be asked for credentials even for resources that anonymous
should
be able to read - because without the subject, the framework can't decide if
permissions apply or not. It's this that seems like a fundamental use case
is
not being catered for and which would need a lot of core framework
changes/overrides.
Can anyone help me out?
Best wishes,
Darren.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/REST-API-permissions-with-anonymous-usage-tp7579176.html
Sent from the Shiro User mailing list archive at Nabble.com.
--
Stephen McCants
Senior Software Engineer
Healthcare Control Systems
1-877-877-8795 x116
