Offline Mode

Welcome to the P6 EPPM User and Integration Library

https://docs.oracle.com/cd/F12057_01/helpmain.htm?toc.htm?98373.htm

Managing remote projects

You can "check out" projects so that they can be worked on remotely. Once a project is checked out, it can no longer be modified until it has been checked in. In addition to checking in the project, you may replace the existing project with the remote copy of the project by using the Import wizard.

If you are working in P6 EPPM, you can choose whether to check out to an XML file or to a local database. If you choose to check out to a local database, a new local database is created for you the first time you check out projects from P6 EPPM. Each time you check out the local database is overwritten. To avoid losing your work, you must check projects back in again before you check out more projects from the same EPPM database. If you connect to more than one EPPM database, checking out projects to a local database will create separate local databases for each EPPM database.

Once you have checked out the projects you need to work on offline, you can log into the local database. While you have projects checked out, other users will be able to open the projects in the EPPM database but will not be able to modify them. After you have finished updating the projects offline, you can check them back into the EPPM database so that other users can work in those projects.

When checking out to a local database:

• You cannot checkout baselines with your project.
• Users' security settings do not apply to checked out projects; all data for the project is exported to the local database, including data which the user is prevented from seeing by their security profile.
• If errors occur during the process of checking in from a local database, no data will be imported.
• Checking in from a local database does not respect admin preferences limits during import and can therefore import invalid data. For example, codes are imported even if they are longer than the code length specified in admin preferences.
• When you check in projects, project calendar data is replaced not merged. Global calendar data is not imported.
• When you check in projects from a local database, resource security is not honored so resources can be assigned to the project even if the user who checks in the project does not have permissions to view that resource.

Check out a project to P6 Pro Local Database

https://docs.oracle.com/cd/F12059_01/client_help/en_US/helpmain.htm?toc.htm?95541.htm

HTML5 in P6 EPPM

Removal of remaining Java applets from P6: With the release of P6 18.8 in August, all remaining applets will be disabled. Recent P6 versions included Portfolio Capacity Planning and Dashboard Scorecards in HTML5. Version 18.8 will also include a new HTML5 user interface for Risk.

What's New in P6 EPPM 18.8

P6 EPPM User and Integration Documentation Version 19

P6 EPPM User and Integration Documentation Version 19

What's new?

Learn what New Features we've recently added to P6 EPPM.

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:

• 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:

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:
    • 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

*Not Available in OCI yet

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.

If you're not able to assign OBS or project access...

Check your global security profile. It may be set to something other than what it needs to be to change these elements. Typically if you're assigning users to an OBS, you should be an Admin Superuser.

An Admin Superuser is a global security profile that gives a user read/write privileges for application-wide information and features. The Admin Superuser always has access to all resources. If resource security is enabled, resource access settings are not applicable. To make global information read-only for a user, choose No Global Privileges. The No Global Privileges profile provides read-only access to all global data except costs and secure codes.

Note: Only Admin Superusers can create, edit, and delete other Admin Superusers. You must have at least one Admin Superuser to create other Admin Superusers.

From a consulting colleague….Admin Superuser is a built in global profile. “Administrator” would be a profile created by a user that may have similar rights.

P6 One Hour Idle Timeout

Our product has a 1hr idle timeout.

If you are connected in P6 Professional and your machine goes into hibernation for > 1hr, the next operation you attempt will result in the “Internal error Invalid Session” error.

Based on your note below, this is likely due to exceeding the 1hr inactivity period (machine moving into hibernation for greater than one hour while you have a connected session).

If the layout you were using did not carry over to the new session, it was likely not updated in your USERDATA row which gets set upon successful logout of P6 Pro (which did not happen in the case below due to abnormal termination from inactivity).