Enabling Federated Identity Single Sign-On (SSO) Through SAML 2.0 For Primavera Products Hosted In Oracle Cloud Infrastructure (OCI) (Doc ID 2497983.1)

Last updated on NOVEMBER 06, 2020

Applies to:

Primavera P6 Enterprise Project Portfolio Management Cloud Service
Primavera P6 Standard Project and Portfolio Management Cloud Service
Primavera Gateway
Primavera Analytics Cloud Service
Primavera Unifier Cloud Service
Information in this document applies to any platform.

Purpose

Customers migrating to OCI will have to re-import SAML Metadata.

NOTE: This change will require NO DOWNTIME for your Cloud environment(s).

WHO WILL BE IMPACTED?

New and existing P6 and Unifier customers migrating or new customers to OCI who connect through SAML.

WHO WILL NOT BE IMPACTED?

All P6 and Unifier customers that have not yet migrated to OCI or do not use SAML

SUPPORTED PROTOCOLS

Only SAML 2.0 is supported at this time. OpenID is not supported.

Primavera Unifier, P6 EPPM and Primavera Unifier Cloud Services support Federated Identity Single Sign-On (SSO) through Security Assertion Markup Language (SAML).

Overview of Federated Authentication Services

A federated identity in information technology is the means of linking a persons electronic identity and attributes, stored across multiple distinct identity management systems. Related to federated identity is single sign-on (SSO), in which a users single authentication ticket, or token, is trusted across multiple IT systems or even organizations. SSO is a subset of federated identity management, as it relates only to authentication and is understood on the level of technical interoperability.

Centralized identity management solutions were created to help deal with user and data security where the user and the systems they accessed were within the same network – or at least the same domain of control. Increasingly however, users are accessing external systems which are fundamentally outside their domain of control, and external users are accessing internal systems. The increasingly common separation of user from the systems requiring access is an inevitable by-product of the decentralization brought about by the integration of the Internet into every aspect of both personal and business life. Evolving identity management challenges, and especially the challenges associated with cross-company, cross-domain access, have given rise to a new approach to identity management, known now as federated identity management (FIdM).

FIdM, or the federation of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common use-cases. Typical use-cases involve things such as cross-domain, web-based single sign-on, cross-domain user account provisioning, cross-domain entitlement management and cross-domain user attribute exchange.

Security Assertion Markup Language (SAML) will be the technology supported by Primavera Products for identity federation SSO in Oracle Cloud.

Overview of SAML

SAML is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between a service provider and an identity provider.

What are a Service Provider and Identity Provider?

A Service Provider (SP) is an entity that provides Web Services, for example an Application Service Providers (ASP). Service Provider technologies important to Identity Management include Software-as-a-Service (Saas), software offered using an Application Service Provider (ASP) model. A Service Provider relies on a trusted Identity Provider (IdP) or Security Token Service (STS) for authentication and authorization. In SAML 2.0, the XML-standard for exchanging data, the security domains that information is passed between are a Service Provider (SP) and an Identity Provider (IdP). The SP depends on receiving assertions from a SAML authority or asserting party, an IdP. Oracle Cloud will act as the Service Provider.
An Identity Provider (IdP), is an online service or website that authenticates users on the Internet by means of security tokens (SAML 2.0 for example, which will be supported in the Oracle Cloud). Service Providers depend on an Identity Provider or Security Token Service to do the user authentication. You (the customer) will act as the Identity Provider configured to your own identity store for authenticating users in your organization.

In-text Citation:

Federated Identity, Wikipedia

Refer to the following diagram for a general overview of the processes that occur when a user attempts to log in to a Primavera application after SAML authentication and identity federation has been successfully configured:

When a user attempts to log in to a Primavera application instance that requires SAML authentication, the following processes occur:

The Primavera application sends an authentication request.
The authentication request is intercepted by SSO in an embedded browser in which a user is required to enter their login information.
The user is authenticated against the identity provider (IdP).
After the user is authenticated, the IdP redirects the SAML assertion to the Service Provider (SP).
The SP parses the SAML assertion and sets the authentication header.
WebLogic reads the header and sets the authentication cookie. The Primavera application reads the cookie and establishes a session.
The user is logged in to the application.

The purpose of this document is to outline the procedure to initiate implementation of Federated Identity Single Sign-On through SAML in your Cloud environment.

Note: When you configure SAML for the STAGE environment, this will not show up in the PRODUCTION page, e.g. Cloud landing page. This will only show when going to the STAGE URL - oraclecloud.com/p6/stage or oraclecloud.com/unifier/stage/bluedoor

Scope

Intended Audience

This document is intended for Oracle Primavera Cloud customers.
This document should be consumed by the Primavera Administrator and IdP/IDCS Administrator in your organization.

Identity Federated SSO and SAML Technical Notes

Primavera Product Technical Notes

P6 EPPM, Unifier and all Enabling Technologies in the Cloud will support usage of SAML 2.0.
P6 EPPM, Unifier and all Enabling Technologies in the Cloud support both SP Initiated Authentication and IdP Initiated Authentication.
- In SP initiated SSO:
  - The SP generates an AuthnRequest that is sent to the IdP as the first step in the Federation process, and the IdP responds with a SAML Response.
  - RelayState:
    - Oracle (SP) populates an 'ID' attribute in the SAML assertion
    - The IdP should relay back the value in an 'InResponseTo' attribute.
- In IdP initiated SSO:
  - The Federation process is initiated by the IdP sending an unsolicited SAML response to the SP.
- P6 EPPM, Unifier and all Enabling Technologies in the Cloud will utilize the NameID for mapping an IdP username to an equivalent unique ID created in the Service Provider for the user.
- P6 EPPM, Unifier and all Enabling Technologies require stub information to be created using the Cloud Administration Utility to a) establish account linking and basic identity for the Service Provider and b) allow provisioning into the purchased Oracle Cloud applications.
  - This is done by creating a user through Cloud Administration, where the user ID will match the Identity Cloud Service (IDCS) attribute mapped/sent by the IdP in the NameID to identify the subject of a SAML assertion.
    - Note, after federated identity SSO through SAML is implemented, the local user created by the Cloud Administration Application will not store password context since the user will not be authenticated by Oracle SSO.

IdP Technical Notes and Requirements

The NameID utilized by the IdP (which is mapped to an outgoing claim rule) must map to an IDCS attribute which uniquely identifies the user.
- This NameID must map to an IDCS attribute which matches the username value stored under the service provider (created by your application administrator through the Cloud Administration application).
- If required, ensure you either create or scrub the associated usernames under the service provider to match an associated IDCS attribute which can be sent.
- When Oracle (the Service Provider) creates a profile for your IdP, an authentication request NameID format is not defined.
  - This will result in the nameID format to not be specified in an SP-initiated SAML authentication request.
  - This allows any of the SAML 2.0 supported formats to be sent by the IdP, as long as the NameID maps/sends the value of an IDCS attribute which matches the username value stored under the service provider (created by your application administrator through the Cloud Administration application).
  - A specific SAML 2.0 compliant nameID format can be set if required by your IdP.
    - Example:
      - urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
      - urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
      - urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
- If using Primavera Virtual Desktop (PVD) Offering, Usernames must follow these guidelines:
  - A user name cannot be identical to any other user name or group name on the computer that is being administered.
  - The user name can contain up to 20 uppercase characters or lowercase characters, except for the following: / \ [ ] : ; | = , + * ? < > @
    - For example, email addresses cannot be used do to the @ symbol being present.
  - A user name cannot consist solely of periods (.) or spaces.
  - Reference: Secure Global Desktop Error Session Failed: Network Level Authentication Failed When Attempting to Launch P6 Professional via Primavera Virtual Desktop (Doc ID 2200935.1)

Process Overview

The following outlines the general process for enabling SAML within your Cloud Environment (details noted below):
- Step 1: Complete username creation / scrubbing prerequisite requirements
- Step 2: Implement Federated Identity
  - [P6 EPPM Only, Required] Part A:
    1. Configure P6 Professional using Cloud Connect
  - Part B:
    1. Complete self-service steps to configure IDCS (These are for IDCS Administrators) for Web Based Applications: P6 Web, Team Member Web and Mobile, Primavera Analytics, Unifier Web and Mobile, BI Publisher, Cloud Administration, PVD, Gateway
    2. Part B does not cover the following applications within the Stage Environment: P6 Web Services, Unifier Web Services
  - [P6 EPPM Only, Optional] Part C:
    1. Complete steps to configure P6 Web Services