Thursday, September 5, 2019

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

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 AUGUST 21, 2019

Applies to:

Primavera Unifier Cloud Service
Primavera P6 Enterprise Project Portfolio Management Cloud Service
Primavera Web Services
Primavera P6 Standard Project and Portfolio Management Cloud Service
Primavera Gateway
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 do not 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:
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:
      1. The Primavera application sends an authentication request.
      2. The authentication request is intercepted by SSO in an embedded browser in which a user is required to enter their login information.
      3. The user is authenticated against the identity provider (IdP).
      4. After the user is authenticated, the IdP redirects the SAML assertion to the Service Provider (SP).
      5. The SP parses the SAML assertion and sets the authentication header.
      6. WebLogic reads the header and sets the authentication cookie. The Primavera application reads the cookie and establishes a session.
      7. 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.

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:

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
*Not Available in OCI yet

Wednesday, September 4, 2019

Error: "Unable to connect to the database. Please run the Database Configuration tool or contact your administrator." Attempting Login To P6 Professional Configured For Cloud Connect (Doc ID 2280504.1)




Applies to: Primavera P6 Enterprise Project Portfolio Management Cloud Service - Version 8.4.0.0 and later
Information in this document applies to any platform.

Symptoms

When attempting to log into P6 Professional configured for Cloud Connect, the following error occurs:

ERROR

Unable to connect to the database. Please run the Database Configuration tool or contact your administrator.

STEPS

The issue can be reproduced at will with the following steps:
1. Attempt to log into P6 Client
2. Notice the error.

Cause

This issue may be caused by an incorrect configuration or by stuck threads in the server. If the user has altered the cloud connect settings at the database configuration level, this issue may occur. Likewise when there are stuck threads on the cloud connect server, this issue will arise with the Pro Clients.
Solution

Solution 1: If the cloud connect URL is incorrect in the database configuration this may cause the issue. To check whether the URL is correct, copy the URL from the database connection tab of the Pro Client login window and paste /checkbasichealth at the end of it and test in a browser. For example: https://<client>.oracleindustry.com/p6procloudconnect/checkbasichealth. If the URL produces a web page error, the URL is not correct. It is best to uninstall the client and then reinstall the client using the Pro Client installer link on the cloud portal page.

Solution 2: If the cloud connect URL is correct (for example having been reinstalled but still may be producing an error with /checkbasichealth) the Cloud Team should check for stuck threads on the server. Create an SR and ask for this Solution to be applied to your environment. Please be sure to specify which environment requires the Solution. Provide this KM document id in the SR problem description. Once the SR has been updated that the Solution has been applied, verify the Solution and close SR.