| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 4.0 E68417-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 4.0 E68417-01 |
|
|
PDF · Mobi · ePub |
This chapter provides guidelines for setting up security for the Master Index Data Manager, including defining MIDM user roles and EJB user roles, and creating MIDM user accounts. It includes the following section:
OHMPI supports security for the Master Index Data Manager at the user and function level, and also supports Secure Sockets Layer (SSL) authentication. Security is defined at the following levels:
EJB level - provides access at the user and function level to the methods of the master controller (com.sun.mdm.index.ejb.master).
Presentation level - provides access at the function and user level for the actions that can be performed from the MIDM.
A secure user name and password must be defined for each master person index application user to connect to the database, and to log on to the MIDM. For each user account you define, specify one or more roles to let that user perform any functions in the MIDM. You must define roles in the midm-security.xml file in the master person index project. This is the presentation layer security.
In addition, each user must also be assigned at least one EJB security role. EJB security roles are defined in the security.xml file. A default role that grants access to all functions of the master controller is predefined, but is not included in the file. The role is named MasterIndex.Admin.
User permissions for master person index applications are granted using the Admin Console. You can also define security using a Lightweight Directory Access Protocol (LDAP) server, using the roles you define in Defining Master Index Data Manager User Roles.
To configure security for the master person index application, perform the following tasks:
These sections provide additional information to perform the above tasks:
OHMPI provides sample user roles for granting multiple permissions to a user. You can define additional user roles and assign combinations of access permissions to each role. By doing this, you can assign a user account to one or two user roles instead of assigning them several access permissions.
In the NetBeans Project window, expand the master person index project, and then expand Configuration.
Open midm-security.xml in an XML editor.
Define user groups and their permissions using the elements described in Master Index Data Manager User Permissions.
The permissions you can assign are listed and described in Master Index Data Manager User Role Properties.
Save and close the file.
Continue to Defining EJB User Roles.
EJB user roles control access at the master controller level. OHMPI provides a sample role for granting multiple permissions at a time without giving access to all functions. An additional role MasterIndex.Admin is predefined that provides access to all functions. You can define additional roles and assign combinations of functional permissions to each role. By doing this, you can assign a user account to one or two roles instead of assigning them several permissions.
Note:
This step is optional. You can use the MasterIndex.Admin role for MIDM users if you only need to restrict access at the presentation level.In the NetBeans Projects window, expand the master person index project, and then expand Configuration.
Open security.xml in an XML editor.
Define user roles and the permissions using the elements described in EJB User Role Properties.
The permissions you can assign are listed and described in EJB Security Functions.
Save and close the file.
You can use these roles when you create the user accounts.
For SSN masking, use the plug-in object-sensitive-plug-in-class in OHMPI.
Perform the following to set the configuration.
Add <is-sensitive>true</is-sensitive> to the SSN field in the midm.xml file.
<field>
<name>SSN</name>
<display-name>SSN</display-name>
<display-order>11</display-order>
<max-length>16</max-length>
<gui-type>TextBox</gui-type>
<value-type>string</value-type>
<input-mask>DDD-DD-DDDD</input-mask>
<value-mask>DDDxDDxDDDD</value-mask>
<is-sensitive>true</is-sensitive>
<key-type>false</key-type>
</field>
Or
Add <is-global-sensitive>true</is-global-sensitive> to the SSN field in the midm.xml file.
<field>
<name>SSN</name>
<display-name>SSN</display-name>
<display-order>11</display-order>
<max-length>16</max-length>
<gui-type>TextBox</gui-type>
<value-type>string</value-type>
<input-mask>DDD-DD-DDDD</input-mask>
<value-mask>DDDxDDxDDDD</value-mask>
<is-global-sensitive>true</is-global-sensitive>
<key-type>false</key-type>
</field>
In the <impl-details> part of midm.xml, specify the <object-sensitive-plug-in-class><impl-details>:
<master-controller-jndi-name>
ejb/PersonMasterController </master-controller-jndi-name> <validation-service-jndi-name>
ejb/PersonCodeLookup </validation-service-jndi-name> <usercode-jndi-name>
ejb/PersonUserCodeLookup
</usercode-jndi-name> <reportgenerator-jndi-name>
ejb/PersonReportGenerator </reportgenerator-jndi-name> <object-sensitive-plug-in-class>
oracle.hsgbu.ohmpi.plugin.SensitiveFieldMaskPlugIn
</object-sensitive-plug-in-class></impl-details>
To implement SensitiveFieldMaskPlugIn, copy the following SensitiveFieldMaskPlugIn.java to the ejb project at oracle.hsgbu.ohmpi.plugin:
public class SensitiveFieldMaskPlugIn implements ObjectSensitivePlugIn
{ public boolean isDataSensitive(ObjectNode objectNode) throws Exception
{ return true;}}
In the midm-security.xml file, there is operation called Field_VIP. If a user role has this operation (for example, Administrator role), the user can view the SSN.
In the web_project\web\WEB-INF\classes\com\sun\mdm\index\edm\, set the SENSITIVE_FIELD_MASKING property (for example, SENSITIVE_FIELD_MASKING=XXXXXXXXX).
presentation\messages\midm.properties
Use the user for MIDM access using the WebLogic Admin Console. In the following steps, you create the MasterIndex.Admin and Administrator groups, and then create a new user within the two groups.
On the left panel, under Domain Structure, expand Services, and then select Security Realms.
In the table on the Summary of Security Realms panel, click myrealm, which is the name of the realm.
The Settings for myrealm panel appears.
Select the Users and Groups tab and then click Groups.
In the Groups table, click New.
In the Name field, enter MasterIndex.Admin, and click OK.
In the Groups table, click New.
In the Name field, enter Administrator, and click OK.
On the Settings for myrealm panel, select Users and Groups, and then Users.
In the Users table, click New.
Type a name and password for the new user you are creating and click OK.
Select User Group.
To add the two groups you created to the user, from the Available list, drag MasterIndex.Admin to the Chosen list, and then drag Administrator to the Chosen list.
For SSN masking, use the object-sensitive-plug-in-class.
Perform the following to make the required changes:
Add <is-sensitive>true</is-sensitive> to the SSN field in the midm.xml file.
<field>
<name>SSN</name>
<display-name>SSN</display-name>
<display-order>11</display-order>
<max-length>16</max-length>
<gui-type>TextBox</gui-type>
<value-type>string</value-type>
<input-mask>DDD-DD-DDDD</input-mask>
<value-mask>DDDxDDxDDDD</value-mask>
<is-sensitive>true</is-sensitive>
<key-type>false</key-type>
</field>
Or
Add <is-global-sensitive>true</is-global-sensitive> to the SSN field in the midm.xml file.
<field>
<name>SSN</name>
<display-name>SSN</display-name>
<display-order>11</display-order>
<max-length>16</max-length>
<gui-type>TextBox</gui-type>
<value-type>string</value-type>
<input-mask>DDD-DD-DDDD</input-mask>
<value-mask>DDDxDDxDDDD</value-mask>
<is-global-sensitive>true</is-global-sensitive>
<key-type>false</key-type>
</field>
In the <impl-details> part of midm.xml, specify the <object-sensitive-plug-in-class>.
<impl-details> <master-controller-jndi-name>
ejb/PersonMasterController </master-controller-jndi-name> <validation-service-jndi-name>
ejb/PersonCodeLookup </validation-service-jndi-name> <usercode-jndi-name>
ejb/PersonUserCodeLookup
</usercode-jndi-name> <reportgenerator-jndi-name>
ejb/PersonReportGenerator </reportgenerator-jndi-name> <object-sensitive-plug-in-class>
oracle.hsgbu.ohmpi.plugin.SensitiveFieldMaskPlugIn
</object-sensitive-plug-in-class></impl-details>
<impl-details>
<master-controller-jndi-name>ejb/PersonMasterController
</master-controller-jndi-name>
<validation-service-jndi-name>ejb/PersonCodeLookup
</validation-service-jndi-name>
<usercode-jndi-name>ejb/PersonUserCodeLookup</usercode-jndi-name>
<reportgenerator-jndi-name>ejb/PersonReportGenerator
</reportgenerator-jndi-name>
<object-sensitive-plug-in-class>oracle.hsgbu.ohmpi.plugin.
SensitiveFieldMaskPlugIn</object-sensitive-plug-in-class>
</impl-details>
To implement SensitiveFieldMaskPlugIn, copy the following SensitiveFieldMaskPlugIn.java to the EJB project:
package com.sun.mdm.index.ejb.util;
import com.sun.mdm.index.objects.ObjectNode;
import com.sun.mdm.index.util.ObjectSensitivePlugIn;
public class SensitiveFieldMaskPlugIn implements ObjectSensitivePlugIn {
public boolean isDataSensitive(ObjectNode objectNode) throws Exception {
return true;
}
}
In the midm-security.xml file, there is an operation called Field_VIP. If a user role has this operation (for example, Administrator role), the user can view the SSN.
In the web_project\web\WEB-INF\classes\com\sun\mdm\index\edm\presentation\messages\midm.properties, set the SENSITIVE_FIELD_MASKING property (for example, SENSITIVE_FIELD_MASKING=XXXXXXXXX).
Build the project and redeploy the new ear into the application server.
The midm.xml file contains configuration details of all screens in the MIDM. As some fields are sensitive and must not be viewed by everyone, they need to be set so that only users with the appropriate permissions can view certain fields. To do this, the MIDM uses the role-based security tags <is-sensitive>true</is-sensitive> or <is-global-sensitive>true</is-global-sensitive>. Set these tags to true for any field that must be masked in the midm.xml file.
For example,
<?xml version="1.0" encoding="UTF-8"?>
<midm xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="schema/midm.xsd">
<node>
<name>Person</name>
<field>
<name>PersonCatCode</name>
<display-name>Person Cat Code</display-name>
<display-order>1</display-order>
<max-length>8</max-length>
<gui-type>TextBox</gui-type>
<value-type>string</value-type>
<is-sensitive>true</is-sensitive>
<is-global-sensitive>true</is-global-sensitive>
<key-type>false</key-type>
</field>
You can set the conditional masking for each record in the MIDM in the field VIPFlag in the <impl-details> section of the midm.xml file. Use the VIPFlag field (see the example below) to control the masking of fields that have <is-sensitive> set to true. For example,
If a record's field such as SSN has is-sensitive set to true, and if the VIPFlag value is set to false in the midm.xml file, the SSN (123-12-1234) is not masked in the MIDM.
If a record's SSN has is-sensitive set to true, and if the VIPFlag value is set to true in the midm.xml file, the SSN (xxx-xx-xxxx) is masked in the MIDM.
Note:
The field VIPFlag is a placeholder and you can change this field name based on your configuration requirements (for example, MVP). You can also change the values true or false (for example, yes or no).
<impl-details> <master-controller-jndi-name>
ejb/PatientMasterController
</master-controller-jndi-name> <validation-service-jndi-name>
ejb/PatientCodeLookup
</validation-service-jndi-name> <usercode-jndi-name>
ejb/PatientUserCodeLookup
</usercode-jndi-name> <reportgenerator-jndi-name>
ejb/PatientReportGenerator
</reportgenerator-jndi-name> <object-sensitive-plug-in-class></object-sensitive-plug-in-class> <sensitive-mask-condition> <sensitive-field> <name>VIPFlag</name> <value>true</value> </sensitive-field> </sensitive-mask-condition></impl-details>
Note:
<sensitive-mask-condition> is used with the <is-sensitive> attribute to provide conditional masking for sensitive fields. For example, if you want to mask the SSN of certain patients, you can add <is-sensitive> to the <SSN field> and provide a mask condition. In the above example <sensitive-mask-condition>, the SSN for all patient records whose VIPFlag is set to true or yes are masked.The sensitive field added to the <sensitive-mask-condition> tag needs to be added to the <search-result-pages>. In the following example, the Person.VIPFlag sensitive field is added to the <search-result-pages> tag.
<search-result-pages>
<search-result-list-page>
<search-result-id>0</search-result-id>
<item-per-page>10</item-per-page>
<max-result-size>100</max-result-size>
<field-group>
<description></description>
<field-ref>Person.FirstName</field-ref>
<field-ref>Person.LastName</field-ref>
<field-ref>Person.SSN</field-ref>
<field-ref>Person.DOB</field-ref>
<field-ref>Person.Gender</field-ref>
<field-ref>Person.VIPFlag</field-ref> <-- sensitive mask
field needs to be added to the search result pages.
</field-group>
</search-result-list-page>
</search-result-pages>
You can define user roles for the MIDM to assign multiple security permissions to a user account at once. Roles are defined in the midm-security.xml file. Table 8-1 describes the elements of the security configuration file.
Table 8-1 MIDM User Role Configuration Elements
| Element | Description |
|---|---|
|
role |
A definition for a user role. Each role element contains a name for the user role, a list of security permissions, and, optionally, a user role from which permissions are inherited along with any exceptions to the inheritance. |
|
role-name |
The name of the user role, such as Administrator. |
|
inheritance |
A definition of how permissions are inherited from another user role. The definition includes the parent user role and any permission that must not be inherited. This group of elements is optional, and a role can inherit from multiple user roles. Note: The role from which permissions are inherited must be defined earlier in the XML file than the role that inherits the permissions. |
|
inherits-from |
The name of the user role from which the current role inherits permissions. If permissions are added to this user role at any time, the new permissions are also inherited by the current role. |
|
excluded-operations |
A list of permissions assigned to the parent role that the current role must not have access. Any permission assigned to the parent role that are not listed here are assigned to the current role. Note: If a role inherits from multiple parent roles and each parent is assigned an excluded permission, you need to specify that the permission must be excluded for each parent role. |
|
excluded-operations/name |
The name of a security permission that is not inherited from the parent user role. Security permissions are listed under Master Index Data Manager User Permissions. |
|
operation |
A list of security permissions to assign to the user role. If the role inherits permissions from another role, the permissions listed here are in addition to the inherited permissions. |
|
operation/name |
The name of a security permission to add to the current user role. Security permissions are listed under Master Index Data Manager User Permissions. |
Table 8-2 lists and describes user permissions for the MIDM. The user permission names are case-sensitive.
Table 8-2 MIDM User Permissions and Descriptions
| User Permission | Description |
|---|---|
|
AssumedMatch_Print |
Gives access permission to print the results of an assumed match search. |
|
AssumedMatch_SearchView |
Gives access permission to search for and view records that are automatically matched by the master person index application. This permission is required to perform any assumed match functions. |
|
AssumedMatch_Undo |
Give access permission to reverse an assumed match, separating the two records. |
|
AuditLog_Print |
Gives access permission to print an audit log search results report. This permission also requires AuditLog_SearchView. |
|
AuditLog_SearchView |
Gives access permission to search and view audit log entries. |
|
EO_Activate |
Gives access permission to activate enterprise records. |
|
EO_Compare |
Gives access permission to compare enterprise records. |
|
EO_Create |
Gives access permission to create new enterprise records. |
|
EO_Deactivate |
Gives access permission to deactivate enterprise records. |
|
EO_Edit |
Gives access permission to modify the SBR in enterprise records. |
|
EO_LinkSBRFields |
Gives access permission to link a field in a system record with a field in the enterprise record's SBR so the value of the SBR field is the same as the system object field. |
|
EO_LockSBRFields |
Give access permission to modify the SBR directly and lock SBR fields for overwrite. |
|
EO_Merge |
Gives access permission to merge enterprise records. |
|
EO_OverwriteSBR |
Gives access permission to choose an SBR field to retain during a merge. After the merge transaction, the field is locked for editing. |
|
EO_PrintComparison |
Reserved for future functionality. |
|
EO_PrintSBR |
Reserved for future functionality. |
|
EO_SearchViewSBR |
Gives access permission to search and view single best records, and generate and print the search results report. This permission is needed to perform any functions on the details page. |
|
EO_UnlinkSBRFields |
Gives access permission to unlink an SBR field and system record field that are previously linked. |
|
EO_UnlockSBRFields |
Gives access permission to unlock an SBR field that is previously locked for editing. |
|
EO_Unmerge |
Gives access permission to unmerge enterprise records. |
|
EO_ViewMergeTree |
Gives access permission to view a merge history of an enterprise object. |
|
Field_VIP |
Gives permission to view fields masked by any custom masking logic specified by midm.xml. |
|
PotDup_Print |
Gives permission to print results of a potential duplicate search. |
|
PotDup_ResolvePermanently |
Gives access permission to permanently resolve potential duplicate records. |
|
PotDup_ResolveUntilRecalc |
Gives access permission to resolve potential duplicate records. |
|
PotDup_SearchView |
Gives access permission to search and view potential duplicate records. This permission is needed to perform any functions on the Duplicate Records page. |
|
PotDup_Unresolve |
Gives access permission to unresolve potential duplicate records that are previously resolved. |
|
Reports_Activity |
Gives access permission to run an activity report. |
|
Reports_AssumedMatches |
Gives access permission to run an assumed match report. |
|
Reports_DeactivatedEUIDs |
Gives access permission to run a deactivated record report. |
|
Reports_Duplicates |
Gives access permission to run a potential duplicate report. |
|
Reports_MergedRecords |
Gives access permission to run a merge transaction report. |
|
Reports_UnmergedRecords |
Gives access permission to run an unmerge transaction report. |
|
Reports_Updates |
Gives access permission to run an update report. |
|
Reports_View |
Gives access permission to the reports page. This permission is needed to run any of the production or activity reports. |
|
SO_Activate |
Gives access permission to reactivate a deactivated system record. |
|
SO_Add |
Gives access permission to add system records. |
|
SO_Compare |
Gives access permission to compare system records. |
|
SO_Edit |
Gives access permission to modify system records. |
|
SO_Deactivate |
Gives access permission to deactivate system records. |
|
SO_Merge |
Gives access permission to merge system records. |
|
SO_Print |
Gives access permission to print results of a system record search. |
|
SO_Remove |
Gives access permission to delete system records. |
|
SO_Transfer |
Gives access permission to transfer system records. |
|
SO_SearchView |
Gives access permission to search for and view system records. |
|
SO_Unmerge |
Gives access permission to unmerge system records. |
|
TransLog_Print |
Gives permission to print results of a transaction history search. |
|
TransLog_SearchView |
Gives access permission to search and view the transaction history of enterprise records and view merged records. |
|
View_Sensitive |
Gives permission to view is-sensitive field values that are hidden on the MIDM. |
|
View_Global_Sensitive |
Gives permission to view is-global-sensitive field values that are hidden on the MIDM. |
|
View_Relationships |
Gives permission to view a button on the Record Details tab when a record is searched. For more information, see Oracle Healthcare Master Person Index Relationship Management User's Guide. |
You can define access roles for the EJB layer to assign multiple security permissions to a user or web client at once. EJB roles can be used to secure MIDM users and other clients accessing the master person index application, such as web services. Roles are defined in the security.xml file.
Table 8-3 describes the elements of the security configuration file. The default user, MasterIndex.Admin, is not defined in this file, but it gives access to all functions.
Table 8-3 EJB User Role Configuration Elements
| Element | Description |
|---|---|
|
ejbSecurity |
An indicator of whether EJB security is enabled. Enter ON to enable web service security and enter OFF to disable web service security. |
|
role |
A definition for one EJB user role. Each role element contains a name for the user role and a list of security permissions. |
|
role-name |
The name of the EJB user role, such as DataProcessor. |
|
operation |
A list of master controller functions to assign to the user role. |
|
name |
The name of a master controller function to add to the current user role. Functions are listed under EJB Security Functions. |
Table 8-4 lists and describes each security function in the master controller. The permission names are case-sensitive. For more information about these functions, see the Javadocs provided with Oracle Healthcare Master Person Index. These functions are defined in com.sun.mdm.index.ejb.master.MasterController.
Table 8-4 EJB Security Functions and Descriptions
| User Permission | Description |
|---|---|
|
activateEnterpriseObject |
Gives access permission to change the status of a deactivated enterprise object back to active. |
|
activateSystemObject |
Gives access permission to change the status of a deactivated system object back to active. |
|
addSystemObject |
Give access permission to add a system object to an enterprise object. |
|
calculatePotentialDuplicates |
Gives access permission to calculate potential duplicates for a transaction. |
|
calculateSBR |
Gives access permission to calculate a new SBR for an enterprise object that is updated. |
|
createEnterpriseObject |
Gives access permission to create a new enterprise object in the master person index application. |
|
deactivateEnterpriseObject |
Gives access permission to change the status of an enterprise object to inactive. |
|
deactivateSystemObject |
Gives access permission to change the status of a system object to inactive. |
|
deleteSystemObject |
Gives access permission to delete a system object from an enterprise object. |
|
executeMatch |
Gives access permission to process a system object using the standardization and matching logic defined for the master person index application. |
|
executeMatchDupRecalc |
Gives access permission to process a system object using the standardization and matching logic defined for the master person index application and lets you defer potential duplicate processing. |
|
executeMatchGui |
Gives access permission to process a system object using the standardization and matching logic defined for the master person index application. |
|
executeMatchUpdate |
Gives access permission to process a system object using the standardization and matching logic defined for the master person index application. |
|
executeMatchUpdateDupRecalc |
Gives access permission to process a system object using the standardization and matching logic defined for the master person index application and lets you defer potential duplicate processing. |
|
getConfigurationValue |
Gives access permission to retrieve the configuration of a master controller parameter. |
|
getDatabaseStatus |
Give access permission to retrieve the status of the master person index database. |
|
getEnterpriseObject |
Gives access permission to retrieve an enterprise object. |
|
getEUID |
Gives access permission to retrieve the EUID associated with a system and local ID. |
|
getMergeHistory |
Gives access permission to retrieve a tree structure of the merge transactions associated with a specific enterprise object. |
|
getRevisionNumber |
Gives access permission to retrieve the SBR revision number for an enterprise object. |
|
getSBR |
Gives access permission to retrieve the SBR for an enterprise object. |
|
getSystemObject |
Gives access permission to retrieve a system object based on the system and local ID information. |
|
insertAuditLog |
Gives access permission to add an audit log record to the master person index database. |
|
lookupAssumedMatches |
Gives access permission to retrieve a list of assumed matches based on the search criteria specified. |
|
lookupAuditLog |
Gives access permission to retrieve an audit log record. |
|
lookupPotentialDuplicates |
Gives permission to retrieve a list of potential duplicate records. |
|
lookupSystemDefinition |
Gives permission to retrieve the attributes of a source system in the master person index database. |
|
lookupSystemObjectPKs |
Gives access permission to retrieve an array of system object keys. |
|
lookupSystemObjects |
Gives access permission to retrieve the active system objects in an enterprise object. |
|
lookupTransaction |
Gives access permission to retrieve a transaction summary. |
|
lookupTransactions |
Gives access permission to retrieve an array of transaction summaries. |
|
mergeEnterpriseObject |
Gives access permission to merge two or more enterprise objects. |
|
mergeSystemObject |
Gives access permission to merge two or more system objects. |
|
ResolvePotentialDuplicates |
Gives access permission to flag a potential duplicate pair as resolved. |
|
searchEnterpriseObject |
Gives access permission to retrieve an iterator of enterprise objects based on the specified search criteria. |
|
transferSystemObject |
Gives access permission to transfer a system object from its current enterprise object to a different enterprise object. |
|
UndoAssumedMatch |
Gives access permission to reverse an assumed match transaction, unmerging the two objects that are matched, and creating a new enterprise object. |
|
unmergeEnterpriseObject |
Gives access permission to unmerge two previously merged enterprise objects. |
|
unmergeSystemObject |
Gives access permission to unmerge two previously merged system objects. |
|
unresolvePotentialDuplicate |
Gives access permission to mark as unresolved two potential duplicate records that are previously flagged as resolved. |
|
updateEnterpriseDupRecalc |
Gives access permission to update the master person index database to reflect new values for an enterprise object and optionally to defer potential duplicate processing. |
|
updateEnterpriseObject |
Gives access permission to modify enterprise objects. |
|
updateSystemObject |
Gives access permission to modify system objects. |
|
 Copyright © 2011, 2016, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|