http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Stephen, Usually, an Authenticate response result in a AuthenticationResult response, often that is an enum. http://ayende.com/4094/macto-authorization-decisions#comment34http://ayende.com/4094/macto-authorization-decisions#comment34Thu, 20 Aug 2009 14:22:13 GMTSomewhat of an old post but I was wondering how you convey reasons for authorization failure, currently you say.. can I do 'this', but all you get back is a yes or not.. how would you tell the user why they were not authorized for the action, and how would you handle localization? The system we have returns so called 'authorization reports', which state are you authorized, and if you aren't they can include a list of 'problem' instances, we send the instances to a localized service which generates the error strings - the strings may often need to bind in information like.. if the erorr is 'suspended' you may want to include the date of suspension, and the date when suspension will end, so each problem type will also have instance properties that hold such information. How would you handle this? http://ayende.com/4094/macto-authorization-decisions#comment33http://ayende.com/4094/macto-authorization-decisions#comment33Thu, 20 Aug 2009 14:00:40 GMTAre you going to use Rhino Security as base for your app? Or build authorization totally from scratch? http://ayende.com/4094/macto-authorization-decisions#comment32http://ayende.com/4094/macto-authorization-decisions#comment32Mon, 03 Aug 2009 12:46:15 GMTJames, Yes. http://ayende.com/4094/macto-authorization-decisions#comment31http://ayende.com/4094/macto-authorization-decisions#comment31Sat, 01 Aug 2009 14:18:39 GMTHi Ayende, this is a really great insight into the full development process, thanks! Are you planning on making the source code available too? http://ayende.com/4094/macto-authorization-decisions#comment30http://ayende.com/4094/macto-authorization-decisions#comment30Sat, 01 Aug 2009 14:14:43 GMTI agree with Mark Seemann, this seems to be what its called "Claims-based security/authorization" The user supplies his claims and the system looks what it can do for the user for that operation request with those claims. Did you have chance to look at recently named Windows Identity Foundation formerly was Geneva something. http://ayende.com/4094/macto-authorization-decisions#comment29http://ayende.com/4094/macto-authorization-decisions#comment29Sat, 01 Aug 2009 07:58:37 GMTJan, a) in real world situation, you would tend to get the values from a variety of places, not just this two b) I am writing code that protect against Murphy, not Micheveli c) see my comment to David http://ayende.com/4094/macto-authorization-decisions#comment28http://ayende.com/4094/macto-authorization-decisions#comment28Fri, 31 Jul 2009 21:49:31 GMTIsn't this open for all kinds of bugs? It's easy to send something like that... new SignOutAuthorization { OfficerRank = MyAunts.Rank, OfficerRoles = MyBoss.GetAllCurrentRoles(), OfficerEnclosures = Harry.GetEnclosuresUserIsResponibleFor(), InmateEnclosure = new Enclusure(123), InmateStatus = Status.Released, } would not new SignOutAuthorization(officer, inmate); allow for a much saver operation? http://ayende.com/4094/macto-authorization-decisions#comment27http://ayende.com/4094/macto-authorization-decisions#comment27Fri, 31 Jul 2009 21:45:02 GMTI'm not sure if I'm twisting Peter's example, but his statement was "if the On Duty staff includes an officer of rank "Captain" or higher". I read that as the authorization could succeed if any officer on duty was a "Captain" or higher, not necessarily the current user. http://ayende.com/4094/macto-authorization-decisions#comment26http://ayende.com/4094/macto-authorization-decisions#comment26Fri, 31 Jul 2009 20:14:01 GMTWell, you only need to abstract the data retrieval a bit more, and you basically have Claims-based security. That's generally the direction Identity and Authorization are moving these days, so it makes sense, but you might want to take a look at Windows Identity Foundation and its IClaimsPrincipal interface instead of reinventing the wheel ;) http://ayende.com/4094/macto-authorization-decisions#comment25http://ayende.com/4094/macto-authorization-decisions#comment25Fri, 31 Jul 2009 18:40:57 GMTMost non-trivial applications tend to need something like this. You need to give context to the authentication system to determine the applicable roles. Representing that context, and making the rules become the challenges. I'm looking forward to see how you use a DSL to do this. DoniG http://ayende.com/4094/macto-authorization-decisions#comment24http://ayende.com/4094/macto-authorization-decisions#comment24Fri, 31 Jul 2009 18:34:04 GMTDavid, For real code, I would probably use a ctor, I used props here because it allows me to name the stuff so you can more easily see them. http://ayende.com/4094/macto-authorization-decisions#comment23http://ayende.com/4094/macto-authorization-decisions#comment23Fri, 31 Jul 2009 15:06:50 GMTFrank, The problem is that now the auth class needs to figure out where to get the info from. It is much better to let the calling code make this decision, since it can add any required info to the eager loaded parts. http://ayende.com/4094/macto-authorization-decisions#comment22http://ayende.com/4094/macto-authorization-decisions#comment22Fri, 31 Jul 2009 15:06:13 GMTPeter, I have a good example of a similar auth service in my book, you might want to check that out. Auth Rules are composed of a set of scripts that are combined together. In this case, I would say something like: allow if Status is OnDutyStuff and Rank >= Captain allow if CurrentTimeIsBusinessHours Date stuff is handled internally, not externally. http://ayende.com/4094/macto-authorization-decisions#comment21http://ayende.com/4094/macto-authorization-decisions#comment21Fri, 31 Jul 2009 15:05:06 GMTWhy do you create the SignOutAuthorization with properties instead of constructor arguments? With a constructor, when the SignOutAuthorization has new requirements, at least you break the build if you forget to update all your usages. I also find it weird that the caller has to know every needed info to authorize an action... http://ayende.com/4094/macto-authorization-decisions#comment20http://ayende.com/4094/macto-authorization-decisions#comment20Fri, 31 Jul 2009 14:51:37 GMTI like the class instantiation as in SignOutAuthorization for an authorization request. I am uncertain about the API consumer having to figure out how to fill the parameters. What would be the problem with auth.IsAllowed(new SignOutAuthorization { User = CurrentUser, Inmate = inmate }); ? http://ayende.com/4094/macto-authorization-decisions#comment19http://ayende.com/4094/macto-authorization-decisions#comment19Fri, 31 Jul 2009 14:41:08 GMTTo illustrate Thomas' objection, how would the authorization task be instantiated to handle the following rule: The officer can release the inmate M-F 8am - 5pm OR anytime if the On Duty staff includes an officer of rank "Captain" or higher. To my thinking, this is a lot for the calling client to know about, whereas, if you place an authorization service between the calling client and the evaluation, you could check the staff schedule to see if a Captain is present. Maybe this is solved by placing the configuration of the SignOutAuthorization behind a creation method, something that is isolates the specialized knowledge needed. But then, is that an Authorization Service by another name? Are you suggesting that a rule is fully encapsulated by a single authorization task or do you envision tasks as composable (a tree) to support AND/OR logic? http://ayende.com/4094/macto-authorization-decisions#comment18http://ayende.com/4094/macto-authorization-decisions#comment18Fri, 31 Jul 2009 14:27:02 GMTI can't tell if you are sarcastic or not. http://ayende.com/4094/macto-authorization-decisions#comment17http://ayende.com/4094/macto-authorization-decisions#comment17Fri, 31 Jul 2009 14:11:08 GMTauth.IsAllowed( new SignOutAuthorization { OfficerRank = CurrentUser.Rank, OfficerRoles = CurrenUser.GetAllCurrentRoles(), OfficerEnclosures = CurrentUser.GetEnclosuresUserIsResponibleFor(), InmateEnclosure = inmate.Enclosure, InmateStatus = inmate.Status, } ); That's the type of code I like to see in an application!! http://ayende.com/4094/macto-authorization-decisions#comment16http://ayende.com/4094/macto-authorization-decisions#comment16Fri, 31 Jul 2009 14:04:49 GMTEyston, I am not sure what you mean by implementation. For a single operation, the set of data that gets passed in is well known. There may be multiple rules operation on that, though. http://ayende.com/4094/macto-authorization-decisions#comment15http://ayende.com/4094/macto-authorization-decisions#comment15Fri, 31 Jul 2009 12:55:19 GMTauthenticated = authorized, typo http://ayende.com/4094/macto-authorization-decisions#comment14http://ayende.com/4094/macto-authorization-decisions#comment14Fri, 31 Jul 2009 12:51:29 GMTI mean if there are multiple ways to be authenticated for SignOutAuthorization that are kind of orthogonal. Like criteria A or criteria B. http://ayende.com/4094/macto-authorization-decisions#comment13http://ayende.com/4094/macto-authorization-decisions#comment13Fri, 31 Jul 2009 12:45:17 GMTEyston, There _are_ multiple ways that the user get authorized. For example, the logic for signing out an inmate and the logic for changing legal info is completely different and require different data. http://ayende.com/4094/macto-authorization-decisions#comment12http://ayende.com/4094/macto-authorization-decisions#comment12Fri, 31 Jul 2009 12:44:23 GMTThomas, I agree that this is a problem. That is why we have strongly typed it. Notice SignOutAuthorization ? We would have similar stuff to that on each possible operation. And that explicitly specify what we need to pass. And each operation can only use the stuff that is passed to it. Things like current date time are something that is globally and cheaply accessible, so I wouldn't worry about that. http://ayende.com/4094/macto-authorization-decisions#comment11http://ayende.com/4094/macto-authorization-decisions#comment11Fri, 31 Jul 2009 12:37:38 GMTSo if you had multiple different ways a user could be authorized, do each of them get their own implementation? I'm not sure if I follow yet (maybe should just shuttup and wait for code). http://ayende.com/4094/macto-authorization-decisions#comment10http://ayende.com/4094/macto-authorization-decisions#comment10Fri, 31 Jul 2009 12:37:33 GMTI think the problem with your approach is that the calling code has to know exactly which facts the authorization system is basing its decision on. What if your authorization system now also needs to look at the day of week to decide (like in the requirements at the top of your post). Do you explicitly pass in the current day of week and change every call-site? Also that puts alot of responisbility on the caller site for a security critical component. What I do like about the approach is that state is explicit and the authorization component does not have to know how to retrieve additional data from your application. That also makes it very easy to unit test. http://ayende.com/4094/macto-authorization-decisions#comment9http://ayende.com/4094/macto-authorization-decisions#comment9Fri, 31 Jul 2009 12:32:16 GMT"Validation and Personalization" are the basic infra building blocks you use for the security module. Client and server side operations, which use personalization data for the current user, may just as well be used for security decisions. Client and server side operations, which perform data validations on operations, may just as well be used for security validations. It's the safe exact infra; different flavors. http://ayende.com/4094/macto-authorization-decisions#comment8http://ayende.com/4094/macto-authorization-decisions#comment8Fri, 31 Jul 2009 12:26:49 GMTcowgaR, Try to write it down in pseudo code. The first sample should fail, the second should pass. I think it will make it easier to understand the issue http://ayende.com/4094/macto-authorization-decisions#comment7http://ayende.com/4094/macto-authorization-decisions#comment7Fri, 31 Jul 2009 12:00:24 GMTit's lame (must be ;-) but this would be: 1. sign in for today - assigned roles (3 or 4) 2. ..../Legal/ReleaseDateChange 3. check wheter current staff (me logged in) belongs to _all_ required roles but now that I'm thinking I see that the action (and thus required roles) is dependant on _inmate_ in a question, so it is becomming complex... but I _know_ you are trying to show me some other thing I am not getting here ;) http://ayende.com/4094/macto-authorization-decisions#comment6http://ayende.com/4094/macto-authorization-decisions#comment6Fri, 31 Jul 2009 11:54:49 GMTcowgaR, Roles would work, yes. You would need to dynamically assign people to and from roles. And you will have a _lot_ of roles. Moreover, given the following piece of data, what should the auth sys do? user: Operations, Captain, Enclosure 1 & 2 op: /Inmate/SignOut inmate: Enclosure 3, Administrative And: user: Operations, Captain, Enclosure 1 & 2, On Duty op: /Legal/ReleaseDateChange inmate: Enclosure 3, Administrative That is, what is the code that would satisfy both questions? Since we have different logic chains around, we can end up with a very complex system, and that would be... bad. http://ayende.com/4094/macto-authorization-decisions#comment5http://ayende.com/4094/macto-authorization-decisions#comment5Fri, 31 Jul 2009 11:25:41 GMT