I believe that he is interesting in securing the data not the methods (certain rows of data to certain user)
Natty Gur, CTO Dao2Com Ltd. 28th Baruch Hirsch st. Bnei-Brak Israel , 51114 Phone Numbers: Office: +972-(0)3-5786668 Fax: +972-(0)3-5703475 Mobile: +972-(0)58-888377 Know the overall picture -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of David Rohacek Sent: Monday, November 25, 2002 4:41 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Authorization - more than just role based Let me preface my answer by stating that I am much more familiar with code- access security than I am with role-based security. Why exectly do you believe that role-based security is not an appropriate solution for your problem? Role-based security allows you to demand that a user be a member of a particular role or have a particular identity. Is it possible that in your research you missed the point that a user can be a member of any number of roles and you can make security demands based on membership in groups of roles? In the example you give, you could create roles based on employment in a particular office. You could also create roles based on the type of account that the user is permitted to access. In your example, it would be a role that means the user is permitted to access accounts 1-50. You mentioned also that you need to make demands based on the data being accessed. Let's say that the amount of money that a teller is able to withdraw is determined by the teller's job title. In this case, you could define a role for each job title and in your imperative demand code you would demand a particular role based on the amount of money in the withdrawl call. Alternatively, based on the user's particular identity, you could probably programmatically look up their title in your HR database to determine their title. This would ease the burden on your system adminstrators. David Rohacek National Instruments On Sun, 24 Nov 2002 08:37:25 -0800, Yosi Taguri <[EMAIL PROTECTED]> wrote: >hi there >I've been given a job to handle the security aspects of big banking >application. > >the Application consists of a 3 logical tiers, >1. presentation: asp.net >2. logical: com+ application called thru remoting. >3. data: sql server. > >Sometimes the last 2 tiers are on the same computer, but it is designed to >scale. > >The requirements demand that the security (or better said: the >authorization) will be on the values of the data itself. > >If one person can withdraw an amount of money from one bank account it >doesn't mean he >Can do it to anther account, But still it should use the >Same Business logic for both of the operation. > >Role based security is not enough, more over using Imperative decleration >is not sufficient, > Since the role itself doesn't identify the user, >Both users are tellers in 2 different bank offices. > >We came into conclusion of the following things: >1. We define roles of users (profiles). >2. Each user has specific data that distinguish it from other users. >3. For every profile/Role we define a set of permissions on > Operations of specific objects. >4. Each permission consists of parameters on specific objects. >5. We have 2 kinds of permissions: Allow Access/ Deny Access. >6. Everything that is not defined as Allow Access is denied. >7. If something is defined as allowed and as denied, it is denied. >8. The deny mechanism is merely to deny access of specific things in >A case where we allowed access to a wide range of data. > >For example: >Let's say we have two bank offices: >1 and 2 > >Each of them has 100 banking accounts. > >2 tellers, 1 from each bank office. >Every teller can update accounts only from the office he belongs to. >Teller number 1 can update accounts 1 thru 50 in office no.2 > > >As I mentioned earlier, each teller comes with info about his default >Office, the permissions describe the security on objects beside his >office... >I've searched MS docs for a proposed solution for data security besides >Role based, but to no avail. It seems that every big application >Needs that kind of security but no one has posted a solution, > >The problem is "merely" MATCHING the permission to the data has submitted. > >Does u have any recommendations?? > >I'll be glad to add more info on request, > >Thnx, > > >yosi > >You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
