Email of 17 June 2015
This isn’t the entirety of what I was hoping to find, and it’s actually somewhat earlier in the overall discussion we had locally about this stuff, but it gets some of the basic ideas out on the table, at least, and comes with the obligatory boxes-and-arrows diagram. A couple additional background notes to frame up what’s below:
(1) In service of trying to prove that all problems (save one :-) can be solved by the imposition of an additional layer of indirection, we came up with the idea of interposing “reflection APIs” between common systems of record and common data provisioning targets that would serve to encapsulate the source/target specific APIs and fold them into a somewhat standard API framework that we could easily code against. The idea was that then if we ran into something like a change in the API from, say, Grouper, or when we finally succeed in replacing OIM with something else (a TIER registry, perhaps) we’d only have to adjust the RAPI code — everything that talks to Grouper (or OIM, etc.) would be rewritten once (to talk to the RAPI) and then the RAPI would be the sole point of change to adjust to changes at the endpoints.
(2) We realized along the way that, at least in our environment, there are really *4* relevant elements in the tuple that describes an attribute permission — rather than the typical (subject,action,resource), we really care about (subject,action,resource,context) where the “context” is usually the referent of the resource. So, for example, it’s not enough to say that “doctors in Pulmonology can read tidal volume test results in the EHR” — we want to instead be able to say that “doctors in Pulmonology can read tidal volume test results in the EHR for current patients in Pulmonology”, or in an academic sense, we want to be able to say that “department chairs can read salary information out of the faculty management system for faculty in their departments” rather than simply “chairs can read faculty salary information”. A lot of back-and-forth went on about modeling that 4-tuple in the Grouper 3-tuple environment — whether it was more efficient/effective/“correct” to merge the action and resource into a new action and store the context in the resource slot (e.g., User can Read-Sensitive-Data on Students) or whether it would work better to merge the resource and context (User can Read Student-Sensitive-Data). I think we eventually determined that the former was more tractable, mostly because we have a fixed (albeit large) number of attributes in play (around 400-450) and a much larger and growing number of contexts (possibly one for each of 800,000 potential users and each of roughly the same number of groups). It makes the logic somewhat harder to grasp, I think, but just in terms of scaling, it’s easier to scale to a fixed 400-500 items than an increasing 1.6 million :-)
(3) At the time we were talking about this, informed consent began and ended with uApprove extensions in the IDP, so our ideas about user consent were all focused on the Oauth service we were working on bringing up for use with some student information for student-driven mobile app development. The Oauth bit at the end of the notes below is the late 2013 version, in a way, of the idea of an UMA implementation and some form of pass-thru via the authorization API to the consent store.
If I can get over to the whiteboard later, I’ll try and send you some additional bits from that, but I think at a mid-level approximation, this kinda frames what it is we’ve been discussing off and on for a couple years in this space. Some of the implementation details continue to drift in response to things like TIER and the PrivacyLens work, but all in all, the grand scheme seems to survive the discussions. Whether it can survive any sort of implementation is a different (and as yet unanswered) question :-).
—Take care!—
—Rob—