shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: [grails-user] Re: Securing instances with Shiro but without ACLs
Date Wed, 24 Mar 2010 19:35:59 GMT
Hi there,

What are you trying to restrict exactly?  Does your current
implementation retrieve a bunch of log entries first and then tries to
filter out the ones that can be seen by the current user?

WildcardPermissions work very well when you want to restrict things
like performing an action with "all log entries" or "this exact log
entry".  They don't work so well if you need to apply restriction
criteria, e.g."all log entries matching X criteria".  That restriction
criteria is _very_ domain/implementation specific.

However, a custom implementation of the Permission interface could
very well encapsulate the implication logic based on user id, report
id and account id instead of using a WildcardPermission string.
Implementing the interface is better suited for these more complex
checks.  You typically don't have to override the Realm methods since
they depend on Permission.implies working correctly.

But there is another way that kind of blurs the lines as to what
should be delegated to the security subsystem and what should be
handled by custom business logic.  A security check for each
individual log entry would obviously not scale well, so instead I
would probably use the user's identity to proactively filter what they
can see.

For example, if using a relational database, instead of all log
entries, get the ones for the accounts to which the user belongs:

In SQL (psuedo code) "select all log entries where the log entry
report's account id equals the current user's account id".

Is this possible in your situation?  Because of your intimate
knowledge of the business requirements and the domain model, you can
have a view that shows only what they're allowed to see in a very
efficient manner.  You can still have a security check before
executing the query, but it would be more akin to "can they see log
entries for account 12345", and then if they can, execute that query.

I tend to think of the security checkpoints in code as doorways to
business logic:  can you enter the door or not to get to some
functionality?  Filtering lists of individual items by a security
check doesn't make as much sense to me personally - it feels more like
a door to each line item for display which seems very heavyweight.
Proactive filtering (sql, preemptive caching, NoSQL, whatever) are
often much better suited for filtering logic.

Does this make sense?

HTH,

Les

P.S.  cc'ing to the Shiro user list as this is not grails-specific and
can help others there too.

On Sun, Mar 21, 2010 at 6:34 AM, fatzopilot <fatzopilot@gmx.net> wrote:
>
> Looks promising, thanks.
> There is one thing I am unsure how to proceed best.
> I have the following set-up
>
> Account
>  |__User
>  |__Report
>         |__LogEntry
>
> So everything is somehow related to Account. In case of the LogEntry, this
> is a transitive relation via Report. Now it should be ensured that a user
> can only see the LogEntries that belong to the Account that he also belongs
> to.
> The idea was to implement a new Realm with customized isPermitted(principal,
> requiredPermission) and to see whether User (principal) and LogEntry
> (encoded in requiredPermission) coalesce in Account.
> AFAICS this would need to restore the LogEntry from the requiredPermission,
> which is a WildCardPermission. However, I do not see how this can be done
> other than reparsing the toString method return value of the
> WildCardPermission.
>
> Is that what you would do in this case?
> Thanks
> fatzopilot
> --
> View this message in context: http://n4.nabble.com/Securing-instances-with-Shiro-but-without-ACLs-tp1589767p1676663.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

Mime
View raw message