[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-users] Access time constraints implementation
Hi Argyn. On Apr 12, 2005, at 8:16 AM, Kuketayev, Argyn (Contractor) wrote: > I need to implement the following feature: deny access to certain > feautures of the system to users (based on their RBAC role) at certain > times. > > For example, the system should not allow updated of objects of type A > to > users with a role ADMIN from July 1 to July 15. There could be several > rules like that for different roles, objects and times. Yeah. So, a general comment: what you're describing sounds a lot like negative permissions. Generally, "we" like to avoid these. It's generally pretty hard to verify all roles that a user has except in carefully closed/restriced systems. This is my obligitory comment, which some XACML TC person had to say :) Now, to the rest of your mail... > I have implemented RBAC profile, so theoretically I can add these rules > into my PPS (permission policy set). I'd prefer not to do it, because > RBAC policy sets are very important and require thorough tests. If I > change something there, then the testing is time consuming. Also, these > policies are pretty static, there were no changes for several months. > In > contrast, time constraints are dynamic. They can change several times > during one quarter. Therefore, I don't want to mix in "dynamic" rules > and "static" ones. > > I was thinking about the following solution, and need an > advice/critique. My current RBAC PDP brings in the policy set with all > applicable policies, then evaluates it against the request. I'll add a > special policy with "dynamic" time constraints. It will contain a set > of > "deny" rules to block access to certain features of the system. My new > PDP will create a "wrapper" policy set, which will contain this special > policy and the "old" policy set with "deny-overrides" policy combying > algorithm. I don't know how your whole system works, but your approach seems reasonable to me. Basically, it sounds like you want to isolate the time-based rules so it's easier to understand how they effect the rest of the system, and I think that's what you've done. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]