Rival Help CenterSearch
Help CenterSearchOrganization Admin

SSO integration methods

Single Sign-On allows CORP users to seamlessly log in to applications without requiring them to re- enter their password. The SSO system will be the sole location where users will present their credentials for authentication. This provides for a more consistent user experience and also increased security because the user credentials are only expected at one location. There are two basic methods of typical SSO integration. The cookie (Agent) based is used for Internal Service Providers within the network and SAML 2.0 protocol which is suitable for internal and mostly external applications. Please read further for details on each method and which approach would be suitable for you.

Agent based Integration

The Integration Kit (provided by Ping Identity) allows developers to integrate their applications with a PingFederate server acting as an Identity Provider (IdP). The kit allows a Service Provider (SP) application to receive user attributes from the PingFederate server. The following figure illustrates an SP-initiated SSO scenario, showing the request flow, and how the PingFederate OpenToken Adapter wraps attributes from an assertion into a secure token (OpenToken) and passes the token to target application.

Prerequisites

Applications must be SSL (https) enabled and behind the F5. This is to enable the users to continue to type-in short URLs (if any) into the browser when they are trying to access SSO enabled application. SSO team recommends the usage of SSL certificates issued by TA (Trusted Authorities like VeriSign) for sites that could be potentially accessed outside the network. For only CORP based sites PayPal signed certificates are ok to be used. Only for dev we can allow self-signed, not any other environment.

User Flow

  1. A user attempts to access a resource protected by the PingFederate Agent Kit.
  2. The user is redirected to the PingFederate server for authentication. (If an OpenToken session already exists, the user is granted immediate access.)
  3. The PingFederate server redirects the user’s browser to an IdP for authentication using either the SAML or WS-Federation protocols. The IdP partner authenticates the user and returns a SAML assertion.
  4. PingFederate validates the assertion, encrypts the data internally and generates an OpenToken including any configured attributes. PingFederate then redirects the browser, including the OpenToken, back to the target application.
  5. The Agent Toolkit on application side decrypts and parses the OpenToken and makes the user attributes available to the SP Application.

SAML Based SSO Integration

SAML defines an XML-based framework for communicating security and identity (e.g., authentication, entitlements, and attribute) information between computing entities. SAML promotes interoperability between disparate security systems, providing the framework for secure e-business transactions across company boundaries. SAML Assertions are usually transferred from identity providers to service providers. Assertions contain statements that service providers use to make access control decisions.

SAML Support Matrix

SUPPORT MATRIX

PAYPAL (IDP) SP APPLICATIONS (SaaS/Internal)

PROTOCOLS SAML 2.0/WS-

FED/OAUTH 2.0

MUST SUPPORT ONE OF THE PROTOCOLS

ENCRYPTION YES OPTIONAL FOR APPLICATIONS

PROFILE POST/REDIRECT MUST SUPPORT AT LEAST ONE PROFILE

SIGNING YES MUST FOR SP-INITIATED USE CASE

(AuthNRequest)

User Authentication Flow

  1. The user requests access to a protected resource and the user is directed to the Ping Federate system. Ping Federate system will validate if the user is already authenticated or not. If the user is not already logged in, then the Ping Federate will authenticate the user after collecting the user credentials.
  2. Once the Ping Federate System authenticated the user, the Ping Federate system can construct an identity assertion which can include data from any of the configured data sources.
  3. When the SAML assertion in ready, the Ping Federate System will deliver it to the user and have the user relay it to the end application.
  4. The Federate System at the Service Provider service needs to consume this SAML assertion and convert them into the tokens that the Target Resource application can understand. Ping Federate does NOT replace the unique application Session Tokens. Each Application is required to track individual user session states. Ping Federate only delivers an authentication token with a very limited lifetime.

SSO Authentication and Authorization

SSO provides authentication for application integrated with PayPal SSO. After successful authentication SSO will send the role information to application in the response to the application for authorization. SSO Role Master is integrated with Identity Hub/Identity manager for centralized role provision and de-provisioning. This Role master is dedicated for SSO server, Applications are not allowed to query this role master.

  1. SSO authentication + Coarse grained authorization (SSO will send the assertion with Role information after successful SSO authentication)
  2. SSO Authentication + Fine grained authorization (SSO will send assertion with role information. Application will query the Authscope API for fine grained authorization/permission associated with each role.)
  3. SSO Authentication + Local fine-grained authorization (Application which need local data store for role lookup have to build their own data store. Which do not support role information send as part of SAML assertion.)
  4. App team can integrate that local data store with Identity Manager/Identity HUB for role management (Provisioning/de-provisioning). b. App team owns the Data store