Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object. Also, couldn't the ftPAs be cached regardless of where they are stored? ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Thursday, January 28, 2016 8:52:22 AM Subject: Re: Fortress Constraints > On Jan 27, 2016, at 3:17 PM, Chris Pike <[email protected]> wrote: > > started implementing this and one of the things I am concerned with is > duplicate ftPA entries. Most of our permissions will likely share the same > attribute(s), so the ftPA entires will be duplicated across several > permissions in what I proposed. I am considering creating an objectclass, > something like ftAttributeSet to store the attribute(s), then have ftPA point > to the attribute set. Then in the ftRC, for the filter type, I can specify > the attribute set instead of trying to infer which one is applicable. Any > thoughts or concerns with that change? > > FYI - My plan is to provide an ldif export with some sample data once I have > it all implemented, but if you are interested in what I've done so far you > can take a look here > (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints). > My first thoughts are storing the ftpa attribute set in a separate node or tree adds at least one read to every operation and should be avoided at all costs. What we’re talking about here are rules. And these rules can be used across many permissions. My question is how many of these rules can we expect to be using? Maybe we store them as properties: ftPa1:xyz ftPa2:abc ftPa3:def ftPa4:ghi Now your ftPa attribute on the permission needs to store the name of specific rule it is using. Those config parameters will eventually be stored in the tree under node, ou=Config. The difference being here, those parameters are all read, and cached by the config subsystem when process fires up.
