Oracle Fusion Cloud – How to set-up individual users

Over the last years, Oracle has been successful in transforming its own Oracle ERP on premise customers to its Oracle Fusion Cloud Service. In its journey to transform end-users to the cloud, Oracle is heavily competing (rather successfully) to get SAP ERP customers to switch over to Oracle Fusion Cloud, and has been named a Leader by Gartner.

However, early adopters from Oracle’s Fusion Cloud Services have already been confronted with the first "compliance claims" associated with the unlicensed use of Oracle Fusion Cloud Services. Many end-users thought "with the cloud, there are no compliance issues anymore;" but the reality is different.

In this article we will focus on how the actual license metrics of Oracle’s Fusion Cloud Services dictate the importance of setting up and monitoring your users in a complete and accurate manner. In the following articles we will focus on the most common compliance issues seen with Oracle Fusion Cloud customers and the different non-standard terms you can negotiate with Oracle during your next negotiations.

Oracle Fusion Cloud Services – different metrics

Oracle is famous for its wide variety of different license metric definitions. This is not different for Oracle’s Fusion Cloud Services either. The latest price-list published by Oracle already includes 36 distinct metrics and associated metric definitions under which Oracle sells its Fusion Cloud Service.

The most commonly used metrics are:

Hosted named user

Hosted Named User is defined as an individual authorized by You to access the hosted service, regardless of whether the individual is actively accessing the hosted service at any given time.

Hosted employee

Hosted User is defined as (i) all of your full-time, part-time, temporary employees, and (ii) all of your agents, contractors and consultants who have access to, use, or are tracked by the programs. The quantity of the licenses required is determined by the number of Employees and not the actual number of users. In addition, if you elect to outsource any business function(s) to another company, the following must be counted for purposes of determining the number of Employees: all of the company's full-time employees, part-time employees, temporary employees, agents, contractors and consultants that

• are providing the outsourcing services and
• have access to, use, or are tracked by the programs.

Based on these license metric definitions, how individual users are receiving "access" to the different roles, privileges, and associated cloud services within an Oracle Cloud Subscription is key to staying within compliance and controlling your costs. So, let’s have a closer look at how the "access" provisioning actually works.

Role based access control

The moment you receive your Oracle Cloud application, access to the different functionalities and data is done by using the standard industry framework for authorization: Role-Based Access Control. As an end-user, you implement this role-based access control provided by Oracle, so that individual users have appropriate access to data and functions. This sounds rather simple, doesn’t it?

But, if you look a bit deeper, this role-based access control model introduces several complexities you should be aware of. This since:

• An individual USER gets assigned to one or multiple ROLES
• A single ROLE is assigned one or more ACCESS PRIVILIGES (a role can either be a standard ["seeded"] or "custom")
• A PRIVILIGE belongs to one or more CLOUD SERVICES
• A CLOUD SERVICE belongs to one or more CLOUD SUBSCRIPTIONS

In order to get access to a specific cloud service, individual users gain access to application data and functions when you assign them different roles. These roles can be divided into four different categories:

• Abstract Roles: This role defines the user’s functions in the organization, which are independent of the actual job the individual has. It inherits duty role but does not contain security policies. (e.g. Employee)
• Job Roles: This role defines a specific job an employee is responsible for. An employee may have many job roles. It may require the data role to control the actions of the respective objects. (e.g. Accounts Receivable Specialist).
• Data Roles: This role defines access to the data within a specific duty. Who can do what on which set of data? The possible actions are "read," "update," "delete," and "manage." Only duty roles hold explicit entitlements to access the data. These entitlements control the privileges such as in a user interface that can see specific screens, buttons, data columns, etc.
• Duty Roles: This role defines a set of tasks. It is the most granular form of a role. The job and abstract roles inherit duty roles. The data security policies are specified to duty roles to control actions on all respective objects.

The below diagram provides an overview of the relationship between the different roles:

Understanding this concept makes you realize that one individual user can have any number of different roles at the same time. The combination of roles determines the user's level access to a specific cloud service.

For example, an individual user might be assigned the roles:

• Sales Manager
• Sales Analyst
• Employee

In this example, the individual user gets access:

• As an employee, so the user can access employee functions and data.
• As a sales manager, so the user can access sales manager functions and data.
• As a sales analyst, so the user can access sales analysis functions and data.

In case the user signs into the application (and is successfully authenticated), the user session is established, and all the roles assigned to the specific user are loaded into the session repository. The Fusion Cloud application determines the set of privileges to application resources that are provided by the roles, and then grants the user the most permissive level of access.

Example

In order to understand how the individual user with his or her associated roles and privileges creates the license requirements for the different cloud services and their associated cloud subscriptions, the below real-life example has been created.

User and its Roles: User John Doe has the roles of "Manager" and "Employee."

Roles and their Privileges: An individual user can have one or multiple roles.

The role Employee includes (among others) the privileges:

• Access Time Work Area
• Create Performance Document by Worker
• Manage Expense Report

The role Line Manager includes (among others) the privileges:

• Create Performance Document by Manager
• Manage Team Reputation Tasks
• Access Learning Common Components

Privileges and its Cloud Services: A privilege can belong to one or more cloud services. If you start "mapping" the different privileges to cloud services, the following conclusions can be drawn:

The privilege Access Time Work Area relates to

• Time and Labor Cloud Service AND
• Enterprise Resource Planning for Self Service Cloud Service

The privilege Create Performance Document by Worker relates to

• Performance Management Cloud Service

The privilege Manage Expense Reports relates to

• Enterprise Resource Planning for Self Service Cloud Service

The privilege Create Performance Document by Manager relates to

• Performance Management Cloud Service

The privilege Manage Team Reputation Tasks relates to

• Workforce Reputation Management Cloud Service

The privilege Access Learning Common Components relates to

• Oracle Learning Cloud Service

Cloud Services vs Cloud Subscriptions: A functional cloud service can belong to one or more "Cloud Subscriptions" that can be purchased from Oracle. If you start "mapping" the different cloud services to cloud subscriptions, the following conclusions can be drawn:

• The cloud service "Time and Labor Cloud Service" relates to the cloud subscription "Oracle Fusion Time and Labor Cloud Service"
• The cloud service "Enterprise Resource Planning for Self Service Cloud Service" relates to the cloud subscription "Oracle Fusion Enterprise Resource Planning for Self Service Cloud Service"

The cloud service "Performance Management Cloud Service" relates to the cloud subscription "Oracle Fusion Talent Management and Workforce Compensation Cloud Service," or "Oracle Fusion Talent Management for Coexistence Cloud Service"

• The cloud service "Workforce Reputation Management Cloud Service" relates to the cloud subscription "Oracle Human Capital Management Base Cloud Service"
• The cloud service "Oracle Learning Cloud Service" relates to the cloud subscription "Oracle Fusion Learning Cloud Service"

Conclusion: After doing all these “mappings,” the individual user “John Doe” requires (among others) a Hosted Named User subscription for:

• Oracle Fusion Time and Labor Cloud Service Oracle Fusion Enterprise Resource Planning for Self Service
• Oracle Fusion Talent Management and Workforce Compensation Cloud Service, or
• Oracle Fusion Talent Management for Coexistence Cloud Service
• Oracle Human Capital Management Base Cloud Service
• Oracle Fusion Learning Cloud Service

Standard (Seeded) roles

In the standard "out of the box" provision for Oracle Fusion Cloud Service, several standard job roles - so called Seeded Roles - are provided. These standard roles can be used instantly and enable you as an end-user to:

• use the pre-defined roles immediately (faster "time to value")
• reduce the operational security management costs (using standardized roles)
• scale-up quickly (since these roles exist in all Oracle Fusion solutions, the adoption of a new module is, in theory, simple)

However, there are several disadvantages as well. Apart from the fact that many end-users do not have any visibility into how the usage of the Fusion Cloud Service complies with their security requirements (since it is based on Oracle’s Cloud SoD Policies which are not publicly available), each quarter, a new update of the Oracle Fusion Cloud software is made available.

The updates of the Oracle Fusion Cloud software can introduce new functionality and access into these pre-configured "seeded roles." In other words, the individual users that are making use of "seeded roles" can unknowingly provide individuals access to functionality or cloud services that you as an end-user organization do not have an Oracle Cloud Subscription for, therefore creating a compliance issue. This is because each individual that is "authorized" to make use of the cloud service, regardless of whether the individual is actively using the cloud service, is required to have a subscription!

Although standard seeded roles are positioned to be used as "the way to go" (and although Oracle Support representatives sometimes may state that you don’t receive support if you are making use of custom roles) you are at all times recommended – both from a security and from a license compliance and cost control perspective – to make use of custom job roles. Custom roles will not be affected by newer versions of the cloud service.