[OWASP-ESAPI] AccessController context
Kevin Kalmbach
kevin.kalmbach at gmail.com
Wed Jul 30 09:06:57 EDT 2008
Jeff,
Very nice write-up of general requirements. I think you nailed it.
Jim,
I'm not really sure exactly what you meant by the method
*isAuthorized(String function, Class entityType, Long identifier)
*Can you please elaborate.
If I am following you, the AccessController interface could have several
methods added to take care of the issues Jeff listed above.
Let's pretend setTarget, setOperation and setContext are added to the
interface (to take care of a few things that Jeff listed). (PS, I'm a big
fan of these methods returning "this", to make chaining possible.)
So my code could look like it does now, if I don't want any added
functionality.
ESAPI.getAccessController().isAuthorized("someFunction");
But If I need the functionality, my code could look like this:
ESAPI.getAccessController().setContext("amount",
someValue).setOperation("delete").setTarget(thisAccount).isAuthorized("someFunction");
Does that make sense? Access implementations that do not care about context
or other things could write do nothing methods (or inherit from a skeleton
class).
At least, this is how I see still getting down to the single isAuthorized
call the Jim is suggesting.
Some down sides of this that I see are:
1) Probably not thread safe if the ESAPI.getAccessController is done as a
singleton as it currently is.
2) The access controller could now be holding onto a large amount of data
(Unintended object referenes)
-Kevin
On Tue, Jul 29, 2008 at 9:05 PM, Jim Manico <jim at manico.net> wrote:
> Nice, Jeff.
>
> The key is, I think the only thing ESAPI is lacking now is the ability ask
> about (3) but only in the context of a specific (2).
>
> "Can a user read transaction # 11315"?
>
> And if we provide a entity-specific API, maybe
>
> *isAuthorized(String function, Class entityType, Long identifier)*
>
> It would solve that need.
>
> And I'm starting to like the possibility that for every object that needs
> entity-specific access control - it should implement a isAuth interface -
> then we could get the call down to only one argument:
>
> *public class SavingsTransaction implements ESAPIEntityAccessControl {
>
> public boolean isAuthorizedForFunction(String functionName) {
>
> //first check the environment
> if (specific time is bad) return false;
> if (its sunday) return false;
> if (its snowing in atlanta) return false;
> ** if (defcon on red alert) return false;*
> *
> //now check for specific entity / user / function authorization
> **//pusdocode, and not exactly correct - but the general concept is
> :*
> * int userId = getUserIdFromESAPI();
>
> //here is a data driven query to check has access to execute a
> function on a specific entity
> //but this could also be a property file lookup, or a different
> schema
> "select count(sx.id) from savings_transaction t, functions f,
> savings_transaction_function_xref sfx" +
> "where " +
> "sfx.transaction_id = t.transacton_id AND " +
> "sfx.function = f.fid AND " +
> "sfx.userId = " + userId + " AND " +
> "f.name=" + **functionName*;*
>
> if (count == 1) return true;
> return false;
> **** }
> }*
>
> PS: Sorry to use the term "ACL" incorrectly - I'll say "Access Control" or
> "Authorization" from now on.
>
>
>
> The map doesn't imply caching of anything, it's just a way to wrap up all
> the context that might be needed to make an access control decisions. Here
> are some of the things that an access control decision might involve:
>
>
>
> 1) *Requesting user* – clearly critical. ESAPI currently provides
> access to this under the hood with Authenticator.getCurrentUser(). You can
> test the user's roles easily. And you can access anything in session this
> way.
>
>
>
> 2) *Name of target thing being accessed* – also critical. ESAPI
> currently supports only this. If you make the name descriptive enough, this
> can meet quite a lot of needs. You pass in myTransaction.getName(), for
> example, and you get "transaction/buy/property/11315" You can specify a
> sophisticate policy in ESAPI that governs which part of this namespace the
> current user is allowed to access.
>
>
>
> 3) *Operation to be performed* – read, write, execute, delete,
> transfer, etc… This is one aspect of what Jim is requesting and should
> probably be added to the interface
>
>
>
> 4) *Target details* – Such as amount to transfer, account to access,
> and other details of the request. This is the other part of what Jim and
> Kevin are asking for, and it's important. The trick is how to make the
> information about the target available to the AccessController in a way
> that's natural and intuitive for the developer.
>
>
>
> 5) *Environment details* – what time is it, what day is it, what is
> the current weather or DEFCON level - I recommend making these available in
> your application somehow, perhaps a singleton.
>
>
>
> I think of the developer wanting to ask a question like, "Is the current
> user authorized to do X" or "Is the current user authorized to do X to Y's"
> or "Is the current user authorized to do X to *this* Y" – and the decision
> might involve the environment as well.
>
>
>
> I'm looking for a clean API that will allow the developer to easily ask the
> relevant access control question. I don't think we're quite there yet, but
> I see progress here.
>
>
>
> Thanks,
>
>
>
> --Jeff
>
>
>
> PS – none of this has much to do with ACL's – an ACL is a list of roles or
> groups that is attached to a resource (columns in an access control matrix).
> ESAPI has something more like a capability scheme where roles are attached
> to users (rows in the ACM).
>
>
>
>
>
>
>
> *From:* Jim Manico [mailto:jim at manico.net <jim at manico.net>]
> *Sent:* Tuesday, July 29, 2008 5:03 PM
> *To:* jeff.williams at owasp.org
> *Cc:* 'Kevin Kalmbach'; owasp-esapi at lists.owasp.org
> *Subject:* Re: [OWASP-ESAPI] AccessController context
>
>
>
> 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<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 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
>
> 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 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
>
>
>
>
>
> --
> Jim Manico, Senior Application Security Engineerjim.manico at aspectsecurity.com | jim at manico.net
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
>
> Aspect Security™
> Securing your applications at the sourcehttp://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/20080730/7ebf690f/attachment-0001.html
More information about the OWASP-ESAPI
mailing list