Create a feature configuration with a Feature Type of Data Masking.
Add an option for every field that you defined in Identify The Fields To Be Masked.
Each field's option value will have an Option Type of Field Masking and a Value that references the respective algorithm defined above. In addition, the Value will contain mnemonics that differ depending on how the field is retrieved.
For data that is accessed via a schema-based object call and displayed in a UI map, the field to be masked must reference a meta-data field name in its schema definition: field="fld_name", alg="algorithm name"
If the element references an mdField in the schema, that is the field used to identify the masking rule. If there is no mdField reference but only a mapField reference, that is the field used to identify the masking rule. For example, if you want to mask a credit card number, let's assume that field is defined in the schema is the following:
<creditCard mdField="CCNBR" mapField="EXT_ACCT_ID"/>
In this case, the option value should be field="CCNBR", alg="algorithm name". An option value of field="EXT_ACCT_ID", alg="algorithm name" would not result in masking.
A "where" clause may also be specified. This is useful for data that resides in a list where only data of a certain type needs to be masked: field="fld_name", alg="algorithm name", where="fld_name='value'"
For example, person can have a collection of IDs and only IDs of type 'SSN' (social security number) should be masked. If the person data including its collection of person IDs is displayed on a UI map via a business object call, let's assume the collection is defined in the following way:
<personIDs type="list" mapChild=CI_PER_ID"> <isPrimaryId mapField="PRIM_SW"/> <idType mapField="ID_TYPE_CD"/> <personIdNumber mapField="PER_ID_NBR"/> </personIds>
The option value may look like this: field="PER_ID_NBR", alg="algorithm name", where="ID_TYPE_CD='SSN'"
Please note the following important points for schema based masking:
Limitation of 'where' field Although the main use of a 'where' clause for schema oriented elements is to mask certain elements in a list based on a 'type', it is also possible to mask a single field in the schema based on the value of another field. For example, imagine that a customer submits a registration form that defines an ID type and ID value. Although this data is not in a list, the implementation may still want to only mask the ID value if the ID type is "SSN". The framework is only able to mask an element in the schema based on a 'where' clause if the element in the 'where' clause is a "sibling" in the schema.
If the element to be masked is in a list, the element in the 'where' clause must be in the same list.
If an element to be masked maps to a real column in a table, the element in the 'where' clause must also map to a real column in the table.
If an element to be masked maps to the CLOB of a table as a single element, the element in the 'where' clause must map to the same CLOB as a single element.
Multiple feature option entries for the same field. It's possible that different schemas in the system have a similar type of data that may be masked based on different conditions. For example, imagine that an implementation has different schemas that captured or referenced person identifiers in different ways:
One schema captures a single person ID without any corresponding "type" record and it should always be masked using Algorithm CM_SSN_MASK:
<personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
One schema captures a person ID and a corresponding ID Type and it should be masked with Algorithm CM_SSN_MASK if the type is "SSN" and masked with algorithm CM_FEIN_MASK if the type is "FEIN".
<personIdType mapXML=BO_DATA_AREA mdField=ID_TYPE_CD/> <personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
One schema captures a person ID and a corresponding ID Type and it has the same masking rules as the previous schema, but a different field name is used for the ID Type code. (This scenario could happen if for example a different label is desired for ID Type on the user interface for this schema.)
<personIdType mapXML=BO_DATA_AREA mdField=CM_ID_TYPE/> <personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
For this scenario, the feature options may look like this:
field="PER_ID_NBR", alg="CM_SSN_MASK"
field="PER_ID_NBR", alg="CM_SSN_MASK", where="ID_TYPE_CD='SSN'"
field="PER_ID_NBR", alg="CM_FEIN_MASK", where="ID_TYPE_CD='FEIN'"
field="PER_ID_NBR", alg="CM_SSN_MASK", where="CM_ID_TYPE='SSN'"
field="PER_ID_NBR", alg="CM_FEIN_MASK", where="CM_ID_TYPE='FEIN'"
If more than one sibling element matches a 'where' clause, a runtime error is issued. For example if a schema has an element that references "mdField=ID_TYPE_CD" and an element that references "mdField=CM_ID_TYPE", this is an error. Additionally, if multiple elements reference mdField=ID_TYPE_CD", this is an error.
If one and only one sibling element matches a 'where' clause, the value of the element is compared to the values defined in the 'where' clause. If it finds a match on the value, the appropriate masking algorithm is applied. If no match is found (for example, the Person ID Type is "LICENSE") the element is displayed as is.
If no sibling element matches a 'where' clause and a feature option exists with no 'where' clause (option 1 above), then the masking algorithm of the option with no 'where' clause is applied.
Changing the value in the 'where' clause. If your implementation has some users that are allowed to change records where some data is masked based on a condition, it is recommended to design the user interface to reset the masked value when the value in the 'where' clause changes. For example, if a user is prevented from viewing a person's social security number, but the user is allowed to make updates to the person's record, changing the value of the Person ID Type should reset the Person ID Number. This would ensure that the user does not 'unmask' the social security number by simply changing the ID Type.
For data that is accessed via a page maintenance service call, indicate the table name and the field name where the data resides: table="table_name", field="fld_name", alg="algorithm name"
For example if the Person record and its collection of identifiers are displayed and maintained using page maintenance, the option value should be table="CI_PER_ID", field="PER_ID_NBR", alg="algorithm name"
A "where" clause may also be specified: table="table_name", field="fld_name", where="fld_name='value'", alg="algorithm name"
This is useful for data that resides in a child table where only data of a certain type needs to be masked. For the person ID example, table="CI_PER_ID", field="PER_ID_NBR", alg="algorithm name", where="ID_TYPE_CD='SSN'"
For data that is stored as a characteristic, simply indicate the characteristic type: CHAR_TYPE_CD='char type', alg="algorithm name"
This needs to be defined only once regardless of which characteristic entity the char type may reside on. Note that only ad-hoc characteristics are supported.
In explorer zones data is often retrieved using SQL directly from the database. No masking is applied automatically in this case. If there is data in the explorer zone results that should be masked, the masking must be applied by calling a business service.
Similarly, an MO Info algorithm may not use BO interaction to get data. It may access data using SQL for efficiency purposes. No masking in applied when retrieving data via SQL. To apply masking to a string prior to including it in an info string, the masking must be applied by calling a business service.
The system supplies two business services to be called to determine if masking rules apply for a specific field.
F1-TableFieldMask - Mask a Table field. This business service receives a table name, field name and one or more field values. If masking applies it returns the masked value.
F1-SchemaFieldMask - Mask a Schema field. This business service receives a schema name and type, XPath and field value. If masking applies it returns the masked value.
For data that is displayed via a search service call, indicate the search name and the appropriate field to mask along with the masking algorithm. For example: search="SearchServiceName", field="PER_ID_NBR", where="ID_TYPE_CD='SSN'", alg="algorithm name"
To find the name of the search service, launch the search in question, right click in the filter area and choose View Source. Search for ServiceName. The service name is listed there. To find the field name to mask, go back to the search window and right click on the results area and choose View Source. Look for the Widget Info section and find the field name in the SEARCH RESULTS (do not include the $). Note, the "where" statement can only apply to fields that are also part of the search results.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]