Skip to end of metadata
Go to start of metadata

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

Attributes to Cloak

UserEdit Attribute

Cloaked Context

persist?

LName

global

yes

FName

global

yes

EID

global

yes

suDisplayNameLF

BecomeUser

suDisplayNameFirst

BecomeUser

suDisplayNameMiddle

BecomeUser

suDisplayNameLast

BecomeUser

displayName

BecomeUser

mail

global

labeledURI

BecomeUser

suRegid

BecomeUser

UID

BecomeUser

Attributes to leave alone

title

suAffiliation

suDisplayAffiliation

suDisplayNameSuffix

suDisplaynamePrefix

suPrivilegeGroup

ou

objectClass

suService

Attributes to create during cloaking

realEid

realFName

realLName

Source and Sinks of Users Ids

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

CM_OFFICIAL_INSTRUCTORS_T

course instructors

CM_MEMBERSHIP_T

people as members of CM containers; for us the "Local Administrators" / Subject Administrators

CM_ENROLLMENT_T

people in sections

SAKAI_USER_ID_MAP

maps Eids to Sakai Ids (which yes may be the same depending on your configuration)

SAKAI_SITE_PROPERTY

I have found Site Info has persisted some user info for contact. this is stored as raw values - meaning raw names and email addresses. OK not going to deal with this one now; as no sakai_id is stored as the contact, nor EID, there is no way to cleanly obscure this data and restore it. ugh. w/out shuffling it to the side in some un displayed site properties. (requiring edits to SiteAction.java)

OTHERS

TBD

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.
  • No labels