Friday Jul 10, 2015

Data Masking in Fusion Applications

In Release 10 of Fusion Applications, Oracle Data Masking for Fusion HCM Security Cloud Service is offered as an optional subscription service for Fusion HCM Cloud customers.  Release 11 extends this to include ERP and Sales Cloud products, masking PII attributes in tables owned by these products.

Data masking, also known as data scrambling or data anonymization, is the process of obscuring sensitive information copied from a production database with realistic, scrubbed data based on masking rules, to a test or non-production database. Data masking is ideal for any situation where confidential or regulated data needs to be shared with non-production users who need access to the original data, but not necessarily to every column of every table. Examples of non-production users include internal application developers or external business partners, such as offshore testing companies, suppliers or customers.

Customers can submit a data masking service request as part of an environment refresh request. Personally Identifiable Information (PII) data are removed or masked in the Applications schema, and removed from temporary tables, interface tables and audit shadow tables including workflow notifications. In addition, links to attachments are removed, thus removing access to these attachments from the user interfaces. Data masking is run after the environment refresh and released to customers after the masking process is complete.

Data Masking in Release 10 Fusion Applications

Data Masking in Release 10 of Fusion Applications is designed to mask specific sensitive personal data or PII attributes. Different masking rules are applied for these attributes to ensure the masked data does not fail validation when the same is queried in Fusion Applications user interfaces. PII attributes covered by data masking are:

  • Person Name
  • Person Telephone Number
  • Date of Birth
  • Date of Death
  • Country / Town / Region of Birth
  • Address
  • Bank Account Number 
  • Credit Card Number
  • Instant Messaging / Email Address
  • Passport Number, Visa or Work Permit details
  • Tax Registration Number or National Taxpayer Identifier

Customers are strongly encouraged to use the principle of least privilege when granting users access to a masked database by restricting the access privileges. Users should be granted only those privileges that are necessary to complete their work.

There are some scenarios that are not addressed by the Oracle Data Masking for Fusion Applications.

  • Underlying identities are not masked in the Fusion schema; therefore, it is possible to associate internal database IDs with identities and infer those identities in the masked database.
  • User login accounts are not masked; therefore, certain formats such as firstname.lastname may reveal identities in the masked database.
  • Other sensitive information, such as compensation, performance and benefits are not masked.
  • Running Payroll on a masked database may not fetch valid results as any PII attributes related to payroll calculation are scrambled.

Ensure you understand the limitations with using masked data before requesting data masking service.  Masking data may not be helpful in certain scenarios which include:

  • Testing payroll calculation or other processes that uses data masked by data masking service
  • Verifying interfaces to downstream systems that require real or original (unmasked) data


More information and references can be found in My Oracle Support (MOS) Doc ID 1534683.1

Thursday Apr 11, 2013

Fusion Applications Single Sign On - Business User perspective

Common Use Cases & How to implement them (SSO Pilot Website)

The post outlines some of the more prevalent Single Sign On (SSO) use cases Fusion customers are currently using. It also provides an outline of work necessary to enable each of these use cases & links to more detailed technical information.

Case #1: From Corporate Portal

Employees, already authenticated into your corporate portal, should be able to click on the Fusion Apps link and get access without being challenged for their username/password as shown below.

Figure #1: SSO from Corporate Portal

Software you'll need:

Most companies will already have a directory (LDAP) that they are using to store their employees identities. If you already have Single Sign On configured for any of your applications, then you probably already have a "Federation Server" inhouse.

If your federation server is:
  • ADFS (Active Directory Federation Server) 2.0 from Microsoft
  • Oracle Identity Federation 11g
... you're all set.

If it's some other Federation Server capable of issuing a SAML 2.0 token, this is subject to approved by Oracle.

Configuration / Integration Work Needed:

Creating Employees in Fusion Apps: First thing you'll need to plan is how to create your employee identities in Fusion Applications and how to assign them the appropriate roles in Fusion Applications (this is required before Single Sign On will work). For testing purposes, you can just create the users using the Fusion Applications "Manage Users" or "New Person" screens and typing them in. If you're a small company, you can continue to do this for new hires. If you're a large company, refer to the "Employee/Role data flow" page - this might reflect the flow you need. If it does not, let us know.

When creating the employee in Fusion HCM, the value that you enter as the "HCM username", should be a unique value also present in your Federation Server for that employee, as you will need to configure your Federation Server to send this value as the "Name Id" when it issues the SAML token for Fusion Applications to consume. [The "Name Id" is just a unique value that tells Fusion Apps who this user is].

View Co-existence and SSO Presentation for more details.

Configuring your Federation Server & Fusion Applications (Cloud): Then it's simply a matter of doing some configurations in your Federation Server and for Oracle's Cloud Operations team to do some configurations in your Fusion Applications Pod. This part is done via filing a Service Request. The details of all this are available in My Oracle Support under Note 1477248.1.

Embedding URL: Finally you will embed the url into your corporate portal and your authenticated users will be able to click on the Fusion Applications link and be taken directly into Fusion Applications without being challenged again.

Case #2: From a 3rd Party Application

Employees already authenticated to a 3rd party SaaS Application should be able to click on a Fusion Applications URL and access Fusion Applications without being challenged for their username/password.

Figure #2: SSO from 3rd Party Application

Software you'll need:

If your employees are already configured for SSO into the 3rd party Cloud App, then you probably already have all the On-Premise Software needed in place (LDAP & Federation Server). Refer to Corporate Portal page.

Configuration / Integration Work Needed:

Creating Employees in Fusion Applications: Exactly the same as the "Corporate Portal" use case above.

Configuring your Federation Server & Fusion Applications (Cloud): Exactly the same as the "Corporate Portal" use case above. Single Sign On will operate between your On-Premise Identity Provider and Fusion Applications in exactly the same manner, but your end user will experience Fusion Applications embedded within your 3rd party Cloud Application (as long as the 3rd party Cloud Application supports embedding the URL).

Embedding URL: You will embed the URL into the 3rd party Cloud Application and your authenticated users will be able to click on the Fusion Applications link & access Fusion Applications screens without being challenged again.

Case #3: Accessing Fusion HCM & Taleo

Employees authenticated against Fusion Apps via SSO, should be able to access Taleo without being challenged for their username/password.

Figure #3: Accessing Fusion HCM & Taleo

If you wish to Single Sign On into Fusion HCM, you will need to configure that as outlined in the "Corporate Portal" use case above.

Then you follow the configuration steps to get Taleo SSO working with your On-Premise IdP. This includes a step of ensuring that the employees that need to access Taleo are already created in Taleo.

Now once your users are logged into Fusion HCM, they can bring up an additional tab for Taleo and will be automatically logged into Taleo.

Case #4: Access from Home

All the use cases above should also work when the employee logs in from home (outside work network).

Figure #4: Access from Home

Case #5: SSO plus Non-SSO

Some of your employees (contractors etc) or partners are not present in your LDAP and need to be authenticated by Fusion Applications. All the others need to be authenticated via SSO. NOTE: This is supported as of Release 7 only.

Figure #5: SSO plus Non-SSO

As of Release 7, when you click on the Fusion Applications URL, you will be able to choose between SSO authentication and authentication via Fusion Applications. Contractors and Partners can choose to authenticate via Fusion Applications and employees via SSO.

The SSO setup & configuration remains the same as in the "Corporate Portal" use case above.


Co-existence and SSO Presentation
My Oracle Support (MOS) Interlinked documents on Fusion Apps SSO
MOS Note on Configuring Taleo Business Edition

Employee/Role data flow (from SSO Pilot Website)
SSO Pilot Website

Feedback via comments below or email

This blog shares with the broader Fusion Applications community instructional material in the areas of Enterprise Structures, Extensibility, Integration and Security with the a focus on implementation. This blog is updated by the Fusion Applications Functional Architecture organization.


« October 2016