Governance and ACLs 2.0 (As of 3-6-2018)

Robbie's Demo 3/6/18

For adaptors talking to each other on the Data Hub (Robbie's demo as of today's date):

All the YOUnite SDK is looking for, really, is the client id/secret. There's also a trick here—we have portal domains(??)—as processing the adaptor definition before passing it off to the SDK.

I also append these supported domains—it’s really the code that supports these domains. If there's code for person one, they can all support it; we may change that or in an additional config file that allows for saying “well these adaptors support these” but really, the fact that we have actual code--that his is part of the code–means it's supported.

(NOTE: configurations and config locations will be important for Experis to know)

In Robbie's demo, he sent Marge Simpson through--

First we received an SQS message and then we dump that out and we have properties and we’re sending JSON to MDM domain for person 1 then after this goes
That’s when it gets sent to MDM--the Data Queue Listener received the message from the source adaptor (from 6971) since the send message is JSON --since it says that the MIS code the college adaptor from MIS code 1, we should expect to see it’s 6971 and in fact it is. Note: I am hiding the JSON data but we could tie it to something. But since the JSON data itself could have PII and we don't want that permanently in our logs as it could violate some FERPA stuff, I just set it to hidden. Nonetheless it gives us a good list of data that we need.
As far as college A is concerned it’s a POST so it doesn’t know what the UUID is. If we did a PUT, and we had that already stored in our map at the adaptor, we could say here’s the UUID and here’s the data and it would handle it differently.

I feel we should have more logging on what gets sent our dump out the routing manifest

What it does then is it does 2 things:

POST: reposts are sent to the adaptor that posted it (the reason for this is to tell the adaptor "I got it, and here’s the UUID for that data record you just posted or linked to"). It's possible YOUnite already knew about that data record, in which case it’s a link when that adaptor posts to it. Otherwise it’s a UUID. The adaptor SDK maintains that map.
All other adaptors are capable of handling those messages, and that are not blocked by ACLs, get notified that that POST happened. See the logs for the data listener record responses from the Data Hub. We also record the POST and two adaptors (College B and College C). This tells us the message contains this data record: "here’s the UUID," and none of those adaptors already had that in their map. It says
"no matching source” but now it should have it in its map. The second time through they all know about it and have it mapped to the local source ID.

ACL Update

When a request comes in, it applies to this inbound destination. It affects a certain data domain/data record, and you do all these comparisons as you go down the chain. When it finds a match, it’s done. There is also a rule at the end so if it gets to the end and there are no matches it knows what default to return.

What we had before was flexible but we want to go with this, which is basically IT rules. It's the same for when data goes out: You work down the chain, when there’s a match, a rule is applied, and there's a default rule at the end of the chain.

It will take me a sprint to apply this change—the governance model going forward has more features in it and it's pretty easy to describe: a series of input filters being applied. The order that you put those filters in matters—if you want something caught right away, you put it at the beginning of the chain. You can put an "*" for “this applies to all zones coming in” situations. Or, if a rule applies to a specific zone, that goes at the beginning of the list. These rules are place in front of the ACLs that get posted. The UI doesn’t change that much--they can just drag rules on top or under each other to bring in their input/output chain for each zone for ACLs.