[OWASP-ESAPI] AccessController context

Tue Jul 29 16:51:40 EDT 2008

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> 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
https://lists.owasp.org/mailman/listinfo/owasp-esapi

-- 
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect SecurityT
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
https://lists.owasp.org/mailman/listinfo/owasp-esapi

-- 
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect SecurityT
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/c280abab/attachment.html 