OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[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]