“Contact Tracing makes it possible to combat the spread of the COVID-19 virus by alerting participants of possible exposure to someone who they have recently been in contact with, and who has subsequently been positively diagnosed as having the virus.” – Apple
The conventional deterrent from the adoption of contact tracing is the lack of privacy controls. Apple has to be involved when privacy is vital, and in time we are living today, having a framework that allows for privacy-focused contact tracing to limit the spread of novel viruses is extremely important. Apple and Google collaboratively have put a structure in place for enabling contact tracing while preserving privacy.
Below is a simplified explanation of how contact tracing would work using a mobile device, as described in the specification.
Use of Bluetooth LE (Low energy) for proximity detection (no use of location-based services which would be essential for preserving privacy)
Generation of daily tracing keys using a one-way hash function
Generation of rolling proximity identifiers that change every ~15 minutes and based on daily tracing key.
Advertise self proximity identifiers and discover foreign proximity identifiers.
User decides when to contribute to contact tracing
If diagnosed with COVID-19, the user consents to upload a subset of daily tracing keys.
To detect if one may have come in contact with a COVID-19 positive individual, they would:
Download COVID-19 positive daily tracing keys
Contact tracing app computes time-based proximity identifiers from the downloaded daily tracing keyson the local device
Checks if this local device has previously recorded any of these identifiers
The above mechanism of determining if one has come in contact with a COVID-19 positive person preserves privacy by:
Ensuring that the contact tracing keys cannot be reverse-engineered into computing identifying information of the originating device.
Not associating GPS or other location services with the keys
Performing verification of being in contact with another COVID-19 positive person on a local mobile device.
The specification is preliminary, and there is a strong attempt to ensure privacy of individuals are protected within this framework. COVID-19 positive information uploaded onto central servers also DO NOT contain any personally identifiable information. The detection itself is a decentralized process as it gets computed locally on an individual’s device. Central entities are not in control of either detecting or informing people in this entire process.
All of this works very well if everyone does their civic duty and report when they are positive.
For a broad adoption of contact tracing, there are opportunities for further improvement though. The specification should talk about server(s) responsible for collecting uploaded information. A (mobile) device generates daily tracing keys, and although the keys themselves do not have any mechanism to be associated with that device by an external process, uploading these keys from the same mobile device opens up the possibility of linking information. IP address of a device that uploads anything to a server is always known to it. Applications that are going to use the above privacy framework additionally need to consider connectivity related exposure while uploading information to central servers. The specification should have a section and considerations on protection and controls for exposure of privacy as a result of connectivity.
Another area of improvement could be on controls around potential abuse of this Contact Tracing mechanism. As per the specification, a person who has tested positive for COVID-19 opts-in and uploads their daily tracing key information to central servers. The intent is for others who have been in proximity with them, know, and take actions to self-quarantine to limit the spread. Pranksters or other entities may use it to cause general disruptions by falsely claiming to be COVID-19 positive to unnecessarily or intentionally cause disruption. If such actions happen at a large scale, it will severely impact reliability, credibility, and adoption of contact tracing.
Preserving Privacy is not an easy problem to solve, and larger mindshare is needed to solve these challenges.
Based on recent requests, we wished to revisit this “hidden” gem to expand the CA Identity Suite Provisioning schema to meet unique business requirements. Enable 100’s of SaaS and onPrem applications/endpoints for custom business logic to user’s endpoint accounts’ attributes.
Since early days of the CA Identity Suite solution (eAdmin r8.1sp2), there has been a provisioning SDK that provided an approved process to extend the CA Identity Manager’s IMPD (provisioning directory) schema from the default of 99 user custom fields to 900 additional user custom fields. To compare, typically, the default 99 user custom fields are used with the standard 40-50 default user profile fields, e.g. givenName (First Name), sn (LastName), userID, telephone #, etc. to meet most business use-cases.
Unfortunately, this extended schema process is not well known.
The only known documentation is an embedded readme.txt within a compressed package. Occasionally there will be support tickets or community notes that request this feature as an “enhancement”.
This package is included in the Provisioning SDK download; for IM r14.3, the file name is:
CA Identity Suite (Identity Manager) Provisioning Tier does NOT attempt to be a meta-directory, but act as a virtual directory to the 1000’s of managed endpoints/userstores/applications. As long as the “explore” operation was successful, there will be a “pointer” object that references the correct location of the endpoint accounts. And when a “correlation” operation occurs, this endpoint account “pointer” object is attached (via inclusion referential objects), to the associated global user ID.
By using this “virtual directory” architecture, it is possible for IM business rules or 3rd party tools to directly view the 1000’s of managed endpoints “real data” and not a “stored” representation of this data.
However, some clients do wish to “collect” the native data, and store this within the IMPD provisioning store, as SNAPSHOT data, to monitor for non-approved / OOB (out-of-band) access. If some fields are dedicated to select endpoints, the default of 99 custom fields may quickly run out.
Tackling Case-insensitivity Requirement:
Adjusting the IMPD schema for case-insensitivity; this would allow for case-insensitive correlation rules, and if the new fields are exposed to the IME, case-insensitive comparisions for business rules (PX).
Challenge:
The above Provisioning SDK process will build the extended eTCustomField100-999 and eTCustomFieldName100-999 attributes with case=sensitive. Interestingly, we did not identify a requirement for case sensitivity with the default custom fields, but it does appear this was a decision when the SDK was created. Please note the observation of the OOTB etrust_admin.schema file (for the IMPS data). This OOTB schema for the default custom fields displays a mix of case sensitivity for the eTCustomField00-99 and eTCustomFieldName00-99.
Proposal:
To address this new requirement; and to clarify there are three (3) possible deployments to enable this extended schema. We will review the pro/cons of each possible deployment choice.
Supporting Note 1:
eTCustomFieldXXX is the attribute that will contain a value.
eTCustomFieldNameXXX is the attribute that will contain a business name for this custom field.
Supporting Note 2:
The CA IM Provisioning Tier was/is developed with early x86 MS VC++ code. We attempted to use later release of the MS Visual Studio VC solution for this process but it failed to generate the output files.
Phase 1 Steps: Enhance the IM Provisioning Tier with 900 new custom fields with case = insensitive.
Download & install MS Visual Studio VC 2010 Express, to have access to the ‘nmake’ executable.
Update OS PATH variables to reference this MS VC 2010 bin folder
Execute the nmake binary, to ensure it is working fine
where make & make /?
Download & install CA IM Provisioning SDK on the same server/ workstation as ‘nmake’ binary.
IM r14.3 GEN50000000002780.zip 200 MB
Open a command line window; and then change folder to the Provisioning SDK’s COSX Samples folder
cd “C:\Program Files (x86)\CA\Identity Manager\Provisioning SDK\admin\samples\COSX”
Execute the gencosx.bat batch file to generate the additional schema for N attributes.
gencosx.bat 900 { Max allowed value is 900; which will generate 100-999 attributes}
The output text file: cosxparse.pty
**** The above steps only need to be executed ONCE on a workstation. After the output text file is generated, we should only need & retain this file for future updates. ****
Use Notepad++ to search and replace a string in the following file, cosxparse.pty
“case=sensitive” to “case=insensitive”
{We may be selective and only replace a few attributes instead of all additional 900 attributes.}
Execute the following commands to generate the binary file.
Use batch files to set environmental values for the nmake program. “C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat“
Execute ‘nmake’ nmake
The new output file (binary) will be: C:\Program Files (x86)\CA\Identity Manager\Provisioning SDK\admin\data\ cosxparse.ptt
Before overwriting existing files; backup the three (3) prior files of IMPS/CCS data folder & IMPD schema folder for: etrust_cosx.schema etrust_cosx.dxc cosxparse.ptt
Copy the file, cosxparse.ptt, to the IMPS server data folder
Stop IMPS service: su – imps & imps stop
Execute the follow command: schemagen -n COSX
This process will create two (2) new output files:
etrust_cosx.dxc
etrust_cosx.schema
Validate the two (2) new generated files have case-insensitivity set.
Copy etrust_cosx.dxc to all CA Directory schema folders; including DX routers (on IMPS servers).
Validate this file is reference in the IMPD group knowledge schema file: etrust_admin.dxg
Copy etrust_cosx.schema & cosxparse.ptt to all CA IMPS Servers, the CCS Servers’ data folders, & the CA IMPS GUI data folder.
Validate the file, etrust_cosx.schema, is reference in the IMPS configuration file: etrust_admin.conf
Restart CA Directory and IMPS/CCS Services.
dxserver stop all / dxserver start all
imps stop / imps start
net stop im_jcs / net start im_jcs {this will also restart the im_ccs service}
With the IMPS GUI
Assign a ‘business name’ to the newly created eTCustomField100+ under SYSTEM/GLOBAL PROPERTIES/CUSTOM USER FIELDS {If you do not see these newly created fields, then the IMPS GUI data folder was not updated per step 11.}
Validate that E&C Correlation Rules will now work for these extended fields with case-insensitivity. SYSTEM/DOMAIN CONFIGURATIONS/EXPLORE AND CORRELATE/CORRELATION ATTRIBUTE/
Validate the custom fields are viewable for each Global User.
We may now STOP HERE if we do NOT need to expose these new custom fields to the IME.
Pro: Able to use customfields for account templates and correlations rules.
Con: Not exposed to IME for 1:1 mapping nor exposed for PX Business Rules.
Update the CA IMPS directory.xml as needed for some or all 900 fields.
<ImsManagedObjectAttr physicalname="eTCustomField100" description="Custom Field 100" displayname="Custom Field 100" valuetype="String" multivalued="true" wellknown="%CUSTOM_FIELD_100%" maxlength="0"/>
Update the IME’s IMCD to IMPS 1:1 mappings.
identityEnv_environment_settings.xml
We may now stop here. The next advance configuration is only required if we wish to manage the various Endpoint Mapping Tab with the IM UI; instead of the IMPS GUI. We would consider the next Phase 3 Steps, to be low value for the effort; as this configuration is typically set once and done in the IMPS GUI.
Pro: Able to use customfields for account templates and correlations rules. Also able to map these files 1:1 in the IME for IMCD attributes to be mapped to the IMPS extended custom attributes. These IMPS extended custom attributes will now be exposed for PX Business Rules.
Con: Not exposed to IM UI to update Endpoint’s Mapping TAB for ADS and DYN endpoints.
Phase 3 Steps – IME Advanced
If planning on exposing these new custom fields in both the Endpoint’ Mapping Attribute Screen & Endpoint Account Templates via the IME, follow these additional steps:
Replace commonobjects.xml in ..\Identity Manager\IAM Suite\Identity Manager\tools\RoleDefinitionGenerator\lib\roledefgen.jar by following the steps given below:
rename roledefgen.jar as roledefgen.zip
Open roledefgen.zip
open com\ca\iam\roledefgen\commonobjects.xml and replace the contents with the attached/provided commonobjects.xml file
save the zip
rename the zip to jar
Now roledefgen.jar will contain the commonobjects.xml file with extended custom attributes
execute the below RoleDefGenerator.bat to generate jars for all the required java/Dyn endpoints
open the generated endpoint jars one by one and modify them by following below steps:
rename the original .jar as .zip
open framework.xml and increase the version “version=” (2nd line)
rename the generated .jar as .zip
open and copy the contents of -RoleDef.xml
paste the copied content in step 4 to the file -RoleDef.xml in original .zip (step 1)
save the original .zip and rename it to .jar
replace the save .jar in ..\wildfly-8.2.0.Final\standalone\deployments\iam_im.ear\ user_console.war\WEB-INF\lib
restart IM and test the Custom attributes in IM web-UI
Post Update Note:
Validate if we may need to rebuild the IMPD DSAs (4) for existing users that may have already had these extended attributes but with case=sensitive set previously.
This step is not required if this is the first time the extended attributes have been deployed or if the case=sensitive has not been changed.
Process: Export the IMPD LDIFs, rebuild the IMPD DSA and then re-import LDIFs.
