Re: Question about Authorization Manager

"John" <ask@xxxxxx> wrote in message
news:eomXzNjNGHA.3936@xxxxxxxxxxxxxxxxxxxxxxx
I realize that tasks are simply "buckets" for operations but as noted in
that article the buckets may contain additional buckets. My original post
had to do with a task comprised of 2 operations (1 of which was included
as a nested task).

There was only 1 operation (Print) mentioned in your original post. A
nested task is not an operation, it's a task. It's meaningless to perform
an access check against an empty task since access checks can only be
performed against operations.


Taking the union of all operations in a task, and checking access on each
of the operations, if any one of these operation access checks should
fail, the entire request should fail. This was the behavior I was not
seeing, it was allowing access on 1 operation succeeding.

Umm... There _is_ only one operation in the task you were verifying (the
Print operation). The empty nested task (Access Financial
Information) has no operations against which an access check can be
performed, and the designers of the security application block presumably
decided that an empty nested task would always pass rather than always fail
an access check. (Personally, I probably would have either thrown an
exception or forced it to always fail, but then I tend to be much less
forgiving in my design decisions than the nice folks at Microsoft...)



I am using the January 2005 release of the EAB.

Unfortunately, it's no longer available, so I cannot examine the contents of
the AzManAuthorizationProvider.cs for that release. However, the behaviour
you are describing is consistent with the code I see for later releases, so
it seems safe to assume that your perceived issue is not a bug that was
fixed in a later release.


//check access
bool result = mSecurityProvider.Authorize(mUserPrincipal,"Print Check");

That's pretty much what I expected, but I just wanted to make sure. As
mentioned above, it really shouldn't be surprising that this authorization
passes since Print is the only operation (nested or not) under the Print
Check task.

You didn't include the code that causes the exception you mentioned in your
second message to be thrown, but I'm guessing that it's a similar
authorization attempt for a task that contains no direct or nested
operations. If so, the exception is to be expected and is not a flaw in the
security block code. If operations are the only object against which an
access check can be performed, and the task hierarchy you are attempting to
verify contains no operations, what exactly should the security block be
authorizing? It seems quite normal to me that it throws a configuration
exception since the most sensible interpretation of the scenario is that
you've probably forgotten to add operation(s) to your task(s).

Have you considered that perhaps your empty tasks would be better
represented as operations rather than tasks? If you have reasons for not
wanting to switch them to operations, then you should add at least one
operation to each of the currently empty tasks.


Or you could just fix the security block implementation if it has a
problem...

I plan to do that if it is appropriate, I have posted over on the
workspace for the block but so far have not received a reply.

Personally, I really don't think there's anything to be fixed here. The
behaviour that you are observing is entirely consistent with the appropriate
use of AzMan, and I would strongly recommed that you not fight the intended
usage pattern. However, if you decide that your desired behaviour is
important enough to you that it's worth creating a non-standard
implementation, I suppose that there's nothing preventing you from making
whatever changes you like to the security block code. Then again, you might
want to consider the problems such an implementation may cause to later
maintenance programmers who will expect your AzMan fit the usual pattern...



.