...
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—
Email of 30 September 2013
Here are the stipulations I had jotted down (rewritten somewhat in light of our later conversations) regarding the APIs we've been discussing. Attached below that is a Graffle version of the diagram we built last week... I'm passing it along in PDF for those of you who can't handle Graffle docs, and Graffle for those who might want to make edits directly.
--Rob--
=========
Assumptions:
* The reflection APIs (or RAPIs) are designed as web service exposures of the native APIs associated with the back-end systems they're attached to. They are not caller-specific (that is, reflection APIs are "in the context" of the back-end systems they wrap).
* The RAPIs are a virtual representation of the back-ends, not a direct one-to-one mapping. They reflect the way we'd *like* the back-end APIs to be.
* There will be no (or nearly no) attribute-specific methods in the RAPIs -- methods may take attribute names as arguments, but are not themselves attribute-specific.
* All access to the Reflection APIs is authenticated -- there will be no anonymous access allowed.
* All calls in the RAPIs will make calls to the AuthZ api before returning results. No results will be returned without authorization validation.
* All calls in the attribute/object web service will likewise perform authorization before returning results or performing actions.
* Authorization calls will typically be 4-tuples of the form "Can <authn'd user> perform <requested operation> on <data element type> about <target entity>. Data element type and operation may be merged into a single 2-tuple for the sake of processing (eg., "can rob perform update-sensitive-data on rb186?").
* Model applications in two ways -- if the application is a transparent proxy for the RAPI or the attribute/object API, it should proxyAuth via a token as the calling user; If the app is performing complicated operations and high-level authorization in its own code, it should authenticate as a service account (possibly with admin rights). In the former case, the PEP is in the API -- in the latter case, the PEP is split between the API and the caller or higher-level WS).
* Some logic may be shared or repeated between callers of the APIs, or within the APIs themselves. When this is determined to be the case, the relevant logic should be externalized in a common routines WS.
* Caller-specific APIs wrap the attribute/object web service in order to present higher-level methods in the context of specific callers (PS, SAP). Caller-specific APIs are created as needed either to simplify the use of the attribute/object API by non-IDM groups (where appropriate) or to enforce internal workflow for operations instigated by those callers (eg., instead of SAP calling the "create user" object API method, it might call an "sapNewEmployee" routine that wraps the "create user" method with various authorization, validation, etc. checks and that performs specific business logic limiting the ability of the SAP caller to, eg., set eduPersonAffiliation=student).
* The Authorization WS acts as a generic PDP wrapper API. We anticipate that the majority of the heavy lifting associated with the PDP function can be performed within Grouper, itself, with the AuthZ WS acting as a marshaling and refactoring wrapper around Grouper's authorization mechanism.
* If necessary, integration with an OAuth Token Broker could be done through the authorization API -- the AuthZ api could, eg., perform a Grouper check to determine if a particular operation should be allowed, returning acceptance if Grouper returns acceptance, but performing a secondary check with the Token Broker for a user-to-user explicit access grant if a token is presented and Grouper denies the operation.