[OWASP-ESAPI] AccessController context
Jim Manico
jim at manico.net
Tue Jul 29 17:03:25 EDT 2008
Ah sorry, we crossed email paths.
I think the overhead of a map is to significant to make it the forced
implementation. It implies caching of all or many data objects. And we
will only have a limited (bare minimal) number of those objects in ram
(referenced) at any one time. If the system was small, a map of all
data is easy. But most enterprise applications have a very large number
of objects. I think we want to deal with this one data object at a time.
Perhaps an implementation where we could "register" different data
objects to the AccessController contextual checks. Otherwise, the
implementation will look like:
*isAuthorized(String function, Object data) {
if (object isoftype SavingsTransaction) {
//check for these functions
}
** if (object isoftype SavingAccount) {
//check for these functions
}*
*
return false;
}
*
Another note, not all systems need this level of ACL, but many do. For
many the current ESAPI ACL functions will suffice. WE need to get away
from the horror of referencing roles directly in code.
Either way, I long for the day when ESAPI supports *isAuthorized(String
function, Object data) ***at least at least at the interface level.
**
- Jim
>
> I’d really like to see a full design here before we implement
> something that doesn’t fully work. Would anyone be willing to draft a
> strawman for this?
>
>
>
> I’m thinking that an AccessControlContext interface that works
> basically like a Map might make sense here. In the default case, you
> **could** just use a name from the namespace for targets.
>
>
>
> But in more complex examples, where you want to specify things like
> the “verb” to perform or the target object, you could pass that
> information in too.
>
>
>
> Volunteers?
>
>
>
> --Jeff
>
>
>
> *From:* owasp-esapi-bounces at lists.owasp.org
> [mailto:owasp-esapi-bounces at lists.owasp.org] *On Behalf Of *Jim Manico
> *Sent:* Tuesday, July 29, 2008 3:38 PM
> *To:* Kevin Kalmbach
> *Cc:* owasp-esapi at lists.owasp.org
> *Subject:* Re: [OWASP-ESAPI] AccessController context
>
>
>
> I vote for the Object since it's clean, simple, and anyone can
> implement their own "guts".
>
> So, with the
>
> *isAuthorized(String function, Object data);**
> assertAuthorized(String function, Object data) throws
> AccessControlException;
>
> *route, your could write your own layer with a map (fairly easy) but
> I would have to add extra FM to make it work for my personal
> implementation.
>
> My vote is for the object, adamantly. :)
>
> - Jim
>
>
> This would work for me (Being able to pass in anything I want since
> the argument is an Object, I could pass in a Map).
>
> My only question would be: is something like a Map more intuitive?
> To me an Object seems too wide open, not real obvious to know what to
> pass in.
> A map at least makes it clear that multiple values are accepted
> and each value in the context must be tagged with a String
> representation of what it is.
>
> A map might also be easier for the implementation to retrieve values
> (try getting the value based upon a known key),
> not as much reflection.
>
> On the downside, if the context is a single value, there is the
> overhead to create a map, put the value in, then pass it around.
>
> Just my 2 cents worth.
>
> I completely agree that getting it right is difficult to get right.
> My preference would be to take a quick poll of interested parties and
> see if there is a consensus.
> My vote would be for the map, but not real adamantly.
>
> -Kevin
>
> On Tue, Jul 29, 2008 at 12:57 PM, Jim Manico <jim at manico.net
> <mailto:jim at manico.net>> wrote:
>
> Kevin,
>
> I'm proposing that we add these functions to the access control interface:
>
> *isAuthorized(String function, Object data);**
> assertAuthorized(String function, Object data) throws
> AccessControlException;*
>
> So we can ask a functional access control question in the context of a
> data element.
>
> So you would ask:
>
> *isAuthorized("transfer", CurrentTransaction());*
>
> Does this work for you? Any thoughts?
>
> I think data-contextual access control is needed but difficult to get
> right.
>
> - Jim
>
>
> Hi,
> I am new to ESAPI and am looking over all the docs and have a question
> the the AccessController.
>
>
> Currently in AccessController, the methods take a single string
> argument (the name of the service/function/data key/etc) and make a
> determination from there.
>
> We have several cases where the authorization depends upon more that
> just the name of the function.
>
> Take the classic example of the bank app. A "Teller" can transfer up
> to $5,000.
> Above that amount, a "manager" must make the transfer. (Simple
> contrived example, but...)
> Is it possible for these methods to also get some contextual
> information (possibly a Map) that an implementation of AcessController
> can use?
>
> If not, is there a way to achieve these scenarios.
>
> This might have already been gone over, but I didn't find any
> discussion in the mailing list archive.
>
> -Kevin
>
> ------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
>
>
>
> --
> Jim Manico, Senior Application Security Engineer
> jim.manico at aspectsecurity.com <mailto:jim.manico at aspectsecurity.com> | jim at manico.net <mailto:jim at manico.net>
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
>
> Aspect Security™
> Securing your applications at the source
> http://www.aspectsecurity.com
>
> ---------------------------------------------------------------
> Management, Developers, Security Professionals ...
> ... can only result in one thing. BETTER SECURITY.
> http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference
> Sept 22nd-25th 2008
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
>
>
>
> --
> Jim Manico, Senior Application Security Engineer
> jim.manico at aspectsecurity.com <mailto:jim.manico at aspectsecurity.com> | jim at manico.net <mailto:jim at manico.net>
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
>
> Aspect Security™
> Securing your applications at the source
> http://www.aspectsecurity.com
>
> ---------------------------------------------------------------
> Management, Developers, Security Professionals ...
> ... can only result in one thing. BETTER SECURITY.
> http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference
> Sept 22nd-25th 2008
>
--
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)
Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com
---------------------------------------------------------------
Management, Developers, Security Professionals ...
... can only result in one thing. BETTER SECURITY.
http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference
Sept 22nd-25th 2008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080729/f8fb381e/attachment.html
More information about the OWASP-ESAPI
mailing list