login ID = kerberos id

example issue
https://jira.ucdavis.edu/jira/browse/SAK-3031

The deployment of CAS changed a basic principle by which the eid's are handled in smartsite. With distauth and in the AuthenticationFilter, after the user was authenticated, the mothraid was switched with the authenticated id(kerberos id) so that the REMOTE_USER HTTP header became the mothra id. So calls to getRemoteUser() returned mothraid

With cas the kerberosid is returned from request after the 'getremoteuser' filter creates a request wrapper.

(i)
This has caused a new problem with old data in smartsite. There are old user records in the sakai_user_id_map table in which the internal (opaque) userid is equal to the eid which in turn equals the kerberos id.

During the login process the data (a) found in the sakai_user_id_map table is passed to the UserDirectoryService.getUser... eventually the UserDirectory provider and in our case, the UcdEnterpriseDataService (UCDEntDataService). Since these records have kerberos name as the eid, the UCDEntDataService fails to find the user by eid and does a federated lookup, eventually succeeding in finding the user via kerberos name and retrieving a valid mothra id as eid, setting the eid on the user but keeping the passed-in user id from (a) above initial step.(there where there's little bit of speculation here) The user then gets shown all the data associated with the initial userid (old) and not the data associated with course data.

(ii)
Course data is updated in the sakai_userid_map table whenever a course site membership list is updated... updates occur at the point in time anyone accesses it (refreshAuthzGroupIfNecessary() is called in each retrieval of any realm). The site realm updates place new entries in sakai_user_id_map for roster-referenced eid's if they are not already represented there, and in doing that create a new userid (a GUID) to pair with the motrhaid not already in the table.

So the users with the situation described in (i) above may also have new course data from (ii) which is associated with a new (GUID) userid and an actual eid (mothraid)....since they users get logged in and associated with the different userid (which is the same as their kerberosid) that is associated with a different eid (which is also the same as there kerberosid), they cannot see the coursemanagement-enrolled sites to which they belong.

Steps taken

'update all the users where eid=userid so that the eid does not match the kerberos name and cannot lead to the corresponding userid being used'


update sakai_user_id_map set eid=eid||'/DELETED' where user_id in
  (select mp.kerberos_name from sakai_user_id_map m, mothra_person@sakai_ext mp where m.eid in
   (select mothraid from mothra_person@sakai_ext where kerberos_name in
     (select eid from sakai_user_id_map where eid= user_id)
  ) 
and m.eid = mp.mothraid)

This has the undesirable side effect of preventing instructors from seeing (old) data for these students

and

for each record in

select * from mothra_person@sakai_ext where kerberos_name in
(select eid from sakai_user_id_map where eid= user_id)
and
mothraid not in (

select eid from sakai_user_id_map where eid in
 (select mothraid from mothra_person@sakai_ext where kerberos_name in 
   (select eid from sakai_user_id_map where eid= user_id)
 )
)

... we updated the eid's to be the valid mothraid found for each of those users