Cloaking Device

A Sakai User Cloaking Device

(our internal confluence is down, so I'm taking notes here for a while)

We have a need to engage 3rd parties in QA and development of our Sakai deployment. However we're also concerned with privacy issues for our data.

Our QA team has a practice of using full data sets cloned from Production. This is pretty darn useful, and has saved the Coursework service a number of times. It's probably a violation of Campus policy as well.

Using a full and cloaked user population gets rid of the burden of creating data supporting testing scenarios - also ensures that the scenarios are not some pipe dream about population affiliation ratios. The data will be the real deal.

I have been given a week or so to write a 'cloaking device' for the data. This work is happening in our 2.4.x to satisfy our load testing requirements for the winter rollout.

My goal is to create a body of code which changes displayed user information to persistent false values which can be reversed on demand. This cloaking device will be enabled by a webservice call (an expensive web service call I suspect) and a property setting in our UDP.

The false / obscured values must persist to allow the creation of automated test suites; just using a freshly generated random number/string for a user's name won't help the screen scrapers in automated testing confirm that a given user is appearing w/in 3 seconds on a Section Info page. for example.

Base timing of incurred overhead can be gathered by a limited testing run before enabling the cloaking device, and then a re-run using the false/obscured EID.

Avenues.

I quickly took a look at implementing the DisplayAdvisorUDP interface in our UDP (SKrbLDAP) but I found that the legacy tools don't pay attention to the new values. Or at least in my experimental implementation they didn't.

The next step is to build a side table used by our UDP, and some webservices to push & remove the false EID into the proper locations.

Attributes

Source and Sinks of Users Ids

In our deployment Enterprise Ids (Eid) are stored in:

I'll use the CM data as the source for EIDs, as it is a superset of the sakai_site_user table and will ensure that nobody is uncloaked. (see to do vis Syncing of CM data for caveats.)

Tool/Service modifications

• Become User - add awareness of Cloaking to LDAP peek extensions to control view of obscured data to aid Cloaking Device debugging
• UDP
  • new LDAP service injection for cloaking attributes
  • hack up to recognize
    • new CloakingOn property
    • injection of CloakingDevice
    • pull FFN, FLN from the fake table for a real EID.
• CloakingDevice
  • SQL for table of false values. The table is
    

    rowid

    real EID

    fake EID

    Fake First Name

    Fake Last Name

    which should just be enough

  • SQL for creation of false values; take real Fn Ln data and randomly insert into false value rows. By randomly assigning real names to fake users I'll get all the sorts of charsets used in real life. The result is that a user identified as "lydial" might get a fake first name of "Casey" and a fake last name of "Fleming." another user, eid "caseyd1" may become "Daisy Li" etc.
  • webservice to toggle on and off (push false values into identified sinks)
  • webservice for false value CRUD
  • UDP java for resolving trueEid in false value table, getting false values for cloaking user.

to do's

• Syncronization of CM data while cloaked? needs to insert false values
• ensure use of real IDs when interacting via REMCTL RPC & MySQL/PHPBB
• consider alternate name; this doesn't cloak the database it mutates it. The Mutabator was tossed out over dinner, as was Mutor and Mutator. (Instructors became Mutalisks!)
  on the serious side it may be useful if the QA team had a common set of data to load and weave scenarios around.