 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / February 2006Question about Authorization Manager
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. =\ > 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. 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); } >> 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. 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. > 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 [quoted text clipped - 8 lines] > throw new ConfigurationException(SR.NoOperations); > } 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? > 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 [quoted text clipped - 5 lines] > underlying AzMan level, its the only securable for which your application > can request access permissions. 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. > 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? 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. > 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, 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. > each of which have operations, the security access application block WILL > throw an exception.. that is related to the code I had posted. 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? > 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. Again, please post the code that you have written to implement this access check. > 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. Or you could just fix the security block implementation if it has a problem... >> 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, > > 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. reference http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/securi ty/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. >> each of which have operations, the security access application block WILL >> throw an exception.. that is related to the code I had posted. > > 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? 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. > 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. Thanks JP > 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... >> I realize that tasks are simply "buckets" for operations but as noted in >> that article the buckets may contain additional buckets. My original post [quoted text clipped - 5 lines] > an access check against an empty task since access checks can only be > performed against operations. 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. > 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 > I made an image to try and illustrate the "Print Check" task > definition for you. You can see that two operations are involved in [quoted text clipped - 3 lines] > > Let me know if you see what I am describing. Thanks >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 [quoted text clipped - 3 lines] > > Let me know if you see what I am describing. Thanks 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 > 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...) 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. > 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. 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. > <snip> (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...) > > 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. 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). > 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. 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. > Yup, and this helps narrow down the problem considerably. ;) Does your > version of AzManAuthorizationProvider.cs contain a method named [quoted text clipped - 5 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.