[OWASP-ESAPI] AccessController context
Kevin Kalmbach
kevin.kalmbach at gmail.com
Wed Jul 30 16:15:54 EDT 2008
No problem.
I totally agree with Jeff that these things are difficult to get right and
once out there, you can never take them back.
Jeff,
If there is any (small fairly encapsulated) work that needs done around this
area (or anything else in ESAPI). Please let me know.
I'll be glad to help as my schedule allows.
-Kevin
On Wed, Jul 30, 2008 at 1:48 PM, Jim Manico <jim at manico.net> wrote:
> I'm sorry it took me a few iterations to see the light.
>
> Glad we are all in sync now.
>
> And thank you for even participating in this conversation.
>
> - Jim
>
> The map is what I voted for to begin with, so I'm on board..
> -Kevin
>
> On Wed, Jul 30, 2008 at 1:31 PM, Jim Manico <jim at manico.net> wrote:
>
>> Ah, I'm liking the map a lot. After talking to Jeff:
>>
>> I back
>>
>> *Map map = new Map();
>> map.put( "target", targetAcct );
>> map.put( "source", sourceAcct );
>> map.put( "amount", amount );
>> ESAPI.accessController().isAuthorized( "transfer", map);*
>>
>> 100%
>>
>> As a step in the right direction. One object will not always be enough.
>>
>> - Jim
>>
>> Jim,
>> Thanks for the info. Just a quick brain dump...
>>
>> I think a class and a Long won't be sufficient for all cases to identify
>> the entire context. (this also assumes all keys are Longs which may not
>> always be true)
>>
>> I agree that my example might look too long, but it's as long as it needs
>> to be to get all the information into the isAuthorized (if you need no
>> additional information, then it is exactly like it was before).
>>
>> As far as why not call:
>> ESAPI.getAccessController(). isAuthorized(thisAccount, "delete"),
>> I probably did not give a very good example.
>> Let me try again with our wonderful bank app and transfering.
>> The operation/function is transfer, but we will also need the amount to
>> transfer (not stored in the account yet, so we can not get it from the
>> account) as well as the account (for more complicated scenarios, we might
>> need more information than just one extra object).
>> so isAuthorized("transfer", thisAccount), is not sufficient (missing the
>> amount that the user is attempting to transfer. The limit on who can
>> transfer how much is in the implementation, but the amount attempting to be
>> transfered must be passed into the Authenticator),
>>
>> So I see several options here (there are probably more, but this is what I
>> saw right off):
>>
>> 1) Chaining
>> setTarget(thisAccount).setContext("amount",
>> theAmountToTransfer).isAuthorized("transfer") (adding as many set's as
>> needed)
>>
>> 2) A Map-like object (Similar to what Jeff was suggesting):
>> MapLikeThing context;
>> context.set("account",thisAccount)
>> context.set("amount", amountToTransfer);
>> isAuthorized("transfer",context); // the isAuthorized could also take an
>> arbitrary object here as well as the map
>>
>>
>> 3) A callback object (can be null);
>> So we might have an interface which is as compilcated as needed called
>> AuthorizationCallbacks with methods like getContext, getTarget, getXXX.
>> This most likely will be anonymous inline instances...
>> so the isAuthorized method can be overloaded to take either nothing or a
>> Callback object;
>>
>> So my isAuthorized implementation might look like this:
>> isAuthorized(String function, Callbacks callbacks) {
>> Long amount = callbacks.getContext("amount");
>> Object target = callbacks.getTarget();
>> // do some really complex logic here.
>> }
>>
>>
>> And the client might look like this... (this is ugly and complex)
>> public void transfer(final Long amount) {
>> if (isAuthorized("transfer",
>> new CallbackInterface() {
>> public Object getContext(String key) {
>> if ("amount".equals(key)) {
>> return amount;
>> }
>> return null;
>> }
>> public Object getTarget() {
>> return this;
>> }
>> })
>> ) {
>> return AUTHORIZTION_ERROR;
>> }
>> // do the transfer
>> }
>>
>> Each of these 3 ways has it's advantages and disadvantages, but they all
>> allow for arbitray information to be sent into the authorization engine
>> without any preconcieved notions about how many pieces of information or
>> what type the information will be needed.
>>
>> -Kevin
>>
>>
>> On Wed, Jul 30, 2008 at 12:09 PM, Jim Manico <jim at manico.net> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Nice Kevin, good stuff.
>>>
>>> | I'm not really sure exactly what you meant by the method
>>> | isAuthorized(String function, Class entityType, Long identifier)
>>> *
>>> **I'm splitting out "Object" into "Class" and "Identity" - So in your
>>> world, we would call:*
>>>
>>> isAuthorized("execute", SavingsTransaction.class, 3321l)
>>>
>>> *But I don't like this class method - we would have to re-load the
>>> object. I'd rather see*
>>>
>>> | isAuthorized(String function, Object entityType)
>>> or
>>> | isAuthorized(String function)
>>> *at the object level (see the interface example below, which is
>>> essentially the same thing as isAuthorized(String function, Object
>>> entityType)**
>>> *
>>> *Looking at:*
>>>
>>>
>>> ESAPI.getAccessController().setContext("amount",someValue).setOperation("delete").setTarget(thisAccount).isAuthorized("someFunction");
>>>
>>> *It looks a little complex... why not call:*
>>>
>>> ESAPI.getAccessController().isAuthorized(thisAccount, "delete")
>>>
>>> *and push the rule with amount into the function?*
>>>
>>> *- Jim***
>>> | 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
>>> |
>>> |
>>> |
>>> |
>>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> OWASP-ESAPI mailing listOWASP-ESAPI at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-esapi
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
> ------------------------------
>
> _______________________________________________
> OWASP-ESAPI mailing listOWASP-ESAPI at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
>
> --
> 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/0a2db87d/attachment.html
More information about the OWASP-ESAPI
mailing list