Hello,

I have a question about the configuration of tasks and operations, and
how they are interpreted by the "Authorize" method of the security
application block.

I have created an operation called "Print" and two tasks called "Access
Financial Information" and "Print Check".

The definition of "Print Check" includes both the "Access Financial
Information" task and the "Print" operation.

When a role is defined as having permission to only the operation
"Print" and I attempt to authorize "Print Check", it succeeds. I don't
understand why this would be considering the role has not been granted
rights to the "Access Financial Information" task.

Could someone enlighten me to why access to lower level tasks are not
required in order for authorization of the higher level task to occur?
Is this a desired behavior of Authorization Manager, or has something
gone awry?

Secondly to this.. why is it that a task that has only a lower level
task as its definition considered invalid? (throws an exception) It
seems to me that the operations as defined are supposed to be low level
operations, I should be capable of creating a single task from the
definition of two or more tasks that have their own operations. Yet this
as well throws an exception.

None of this makes sense considering the documentation within
Authorization Manager. I am getting very frustrated. =\

John wrote:
Ok.. sorry to keep replying to myself.. but I discovered why the above
is happening. This doesn't explain my original question because that
behavior I believe is within AzMan itself.

I located the code that is generating an error based on a Task that is
only comprised of lower level tasks. It is within Security Application
Block file AzManAuthorizationProvider.cs line 166-169

if (operations.Count == 0)
{
    throw new ConfigurationException(SR.NoOperations);
}

If you were working more closely against the AzMan API (as opposed to via a
wrapper like the security app block), you would realize that there is only
one way of querying a user's rights to perform an action, and that is at the
_operation_ level (via the IAzClientContext:AccessCheck method).  Tasks and
roles are essentially just convenience "buckets" meant to help when
assigning permissions to users.  However, an application should be
interested only in operations.  Since you have only one operation, at the
underlying AzMan level, its the only securable for which your application
can request access permissions.


This seems rather unlikely to be causing your problem, which is presumably
occuring because an access check that you believe should fail is actually
passing.  This wouldn't be happening if an exception were thrown from the
access check method.  Instead of trying to troubleshoot this blindly, could
you perhaps post the code you are using to attempt your access check?

Nicole Calinoiu wrote:
Even with access checks being done only at the operation level, if I
check access on a task which is comprised only of 2 tasks, each of which
have operations, the security access application block WILL throw an
exception.. that is related to the code I had posted.

I am going to trace the block more, to see if it is simply a failure to
crawl the task->operation associations before throwing the error.

I will post back on this, the issue I first posted was a completely
different problem. I tried to provide a breakdown of the task /
operation structure, the point is that by being granted rights to 1
operation which is essentially 1 of 2 that define a task, and not being
granted rights to the other operation which is wrapped by the associated
task, the call the check access still returns true.

Thanks for the answer, I will provide more concrete information. I had
hoped not to have to use the AzMan COM API directly but I may have to in
order to decide if/where the security block is not correct.

At the AzMan level, checking access on a task is simply not possible.  It is
only possible to check access to one or more operations.


Could you please post the code that you are using to make this access check?
Also, could you please specify which release of the Enterprise Library you
are using?


Again, please post the code that you have written to implement this access
check.


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

Nicole Calinoiu wrote:
reference
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/operations_and_tasks.asp

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). 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.

I am using the January 2005 release of the EAB. The code is fairly
simple so I'm not sure you will get much value out of it, but in a
nutshell here you go:

// get the identity of the current threads user
this.mUserPrincipal = new
GenericPrincipal(WindowsIdentity.GetCurrent(),null);
this.mSecurityProvider =
AuthorizationFactory.GetAuthorizationProvider("MySecProvider");

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

If you would like me to be completely thorough I could post an LDIF of
the authorization store along with a full project demonstrating where I
see an issue, but that would seem to require alot of work on the part of
anyone assisting me. I am looking mostly for information regarding
AzMan. I now have the API reference so I may just refer to it.

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.


Thanks

JP

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.


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...)



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.


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.


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...

Nicole Calinoiu wrote:
I think you may have mis-read my earlier posting. The task "Print Check"
was defined as 2 operations, 1 of which was the definition of a nested
task. There was no empty task. I never made mention of an empty task.

Umm...  You might want to go back and re-read the original post.  It makes
absolutely no mention of an operation within the "Access Financial
Information" task.

I made an image to try and illustrate the "Print Check" task definition
for you. You can see that two operations are involved in the task that
access is being checked for through the security block.

http://www.newriverbluegrass.com/jpimg/azmanimg.gif

Let me know if you see what I am describing. Thanks

Hi,

in short: You can only do access checks against operations - not tasks (as
nicole pointed out earlier)

all other strange behaviour you see comes from using EntLib i guess - to
be honest - you will understand AzMan best by writing your own wrapper

here is some more info:

http://www.leastprivilege.com/AuthorizationManagerTableOfContents.aspx

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

Show quoteHide quote

Ah...  That helps quite a bit.  If you had mentioned from the start that the
"Access Financial
Information" contains an operation, I wouldn't have gone down the empty task
road...

<snip> (Personally, I probably would have either thrown an
They do throw an exception if an empty task is passed for a check.
Reference the code I posted earlier from the AzManProvider.cs file.

The code is identical, the definition of the task is different. I could
only post an LDIF of the task definition if you wanted. But I understand
that you believe what I was describing was referring to an empty task,
i.e. one not containing any operations or nested tasks that contain
operations, and this is where we are not in sync with one another.

I apologize that I had jumped around within two different problems but
they are related. Hopefully you can see in the diagram I posted above
that the definition does indeed include two operations.

I have contacted MS regarding the issue and will be following it up with
one of the block leads. I will post back to the thread any findings.

I agree with you on not altering a usage pattern, but I think we need to
understand what each of us are describing before jumping to that conclusion.

Not quite the same thing as I was discussing here.  Throwing an exception
when the task specified for the Authorize method is empty is different from
throwing an exception when the specified task contains an empty nested task
(as I thought yours did).


Yup, and this helps narrow down the problem considerably. ;)  Does your
version of AzManAuthorizationProvider.cs contain a method named
GetTaskOperations?  If so, you'll probably find that it only returns
operations that are direct children of the specified task.  What you'll need
to do is change the method to operate recursively on the specified task so
that operations are returned from any number of levels of nested tasks.  If
you need help with the implementation details, please post a copy of your
version of the method since it may differ from those in later EntLib
releases.

Exactly. I am already modifying the block code to operate on tasks
recursively, essentially the GetTaskOperations method as you mentioned.
In a nutshell this entire thread was a result of the Ent Lib block not
treating tasks as having the ability to be hierarchical.

Take Care


John Parrish

.net 2.0: exception getting DirectorySecurity on a particular directory
Creating code groups | Setup project
fxcop and link demands
How to encrypt/decrypt a file
System.Security.SecurityException was unhandled
after changed the permisssion set to "nothing", I can't set the .net configuration anymore?
ReflectionPermission weird behavior?
Request for Permission failed
moving .net containers
PFX Import - Can Import but can't read back PrivateKey