> On Oct 22, 2016, at 9:32 AM, Steve Moyer <[email protected]> wrote: > > > I certainly understand the desire to support different back-ends, and so it's > probably also not wise to "pollute" the various Mgr classes with Entry > objects (via the callbacks). I didn't realize that you weren't pulling all > the attributes, so both the getEntry() method and the callbacks on create, > update and delete aren't really useful.
Not necessarily, we’d add another (callback) for the first phase, to give caller chance to populate additional attributes, or I suppose it could be a property. a. String[] getAdditonalAttrs(); or b. myuserattrs = aaa,aab,abb,bbb,bbc,... > > On Oct 22, 2016, at 9:32 AM, Steve Moyer <[email protected]> wrote: > > At one point we'd also talked about giving Fortress a SCIM interface. I > think we should talk through this a bit more but my initial thought is that > the Fortress related Entry objects (in LDAP-speak) could be exposed as SCIM > extensions, but the implementor might want to implement their own SCIM > extensions, so the back-end would have to have a mechanism to allow CRUD on > those objects. And so we're right back to the original topic of custom > object classes and attributes. Yes this is where I want the discussion to go, i.e. there’s a larger concern here (IdM), w/ its applicable standards, that may provide guidance for us to follow. Which brings up one of my favorite soapboxes… with security, standards are everything and it’s a disservice to our community when we invent new ways of doing the same old things. Shawn
