Single Sign-On
Single Sign-On Setup
The preferred and recommended login method is SAML 2.0 for exchanging authentication and authorization data between security domains—specifically, between an Identity Provider (IdP) (e.g., Okta, Azure AD/Entra ID, Ping Identity, OneLogin, or your enterprise IdP).
Cross-domain single sign-on: Users authenticate once via their enterprise IdP and gain access to Sentinel without re-entering credentials.
Centralized identity management: Leverages existing corporate credentials, reducing password fatigue and improving compliance.
Stronger security: Supports federated authentication, attribute mapping (e.g., roles/groups), and protocols for secure assertion exchange (signed/encrypted as configured).
Web-based scenarios: Enables SP-initiated (user accesses Sentinel directly) or IdP-initiated (starts from corporate portal) SSO flows.
Sentinel acts as the SAML Service Provider (SP).
Integration requires configuring Sentinel with your IdP's metadata (or vice versa) — typically involving:
Entity IDs
Assertion Consumer Service (ACS) URLs
Signing certificates
Attribute mappings (e.g., for user provisioning or role assignment)
Once set up, Sentinel redirects unauthenticated users to the IdP for login; successful authentication returns a SAML assertion, granting access with appropriate permissions.
Fallback to local Sentinel credentials remains available if needed (e.g., for admin recovery).
No custom code or modifications to PeopleSoft core are required — Sentinel handles SAML independently via its web layer (Nginx-proxied).
Last updated




