Skip to main content

Common Logon, Single Sign On, or Federated Identity (SAML)

Eptura Knowledge Center

Common Logon, Single Sign On, or Federated Identity (SAML)

This describes options for what is known as common login, single sign on, or federated identity. This frees users from the need to maintain an additional user name and password for access to the application.

Federated Identity

iOFFICE supports a variety of federated identity options in partnership with Ping Identity. Specifics may vary between customers or protocol used. Business requirements define that the customer’s user information be loaded during application configuration, because of this requirement “just in time” or “on the fly” user provisioning is not supported. This means that only an identifying attribute needs to be sent in the assertion (as the SAML_SUBJECT).

SAML responses with encrypted assertions will be rejected if the enclosing Response element is not signed. This is a required client-side configuration that provides protection against a potential protocol vulnerability. See Signature Validation Error When Receiving Encrypted Assertion at PingIdentity.

SAML 2.0

Both Identity Provider (IdP)-initiated and Service Provider (SP)-initiated Single Sign-On (SSO) are supported with SAML 2.0. Mobile apps use SP-initiated SSO authentication.
IdP and SP validation - SAML.png

The customer will provide their entity id, base URL, endpoint URL(s) and signature verification certificate. The verification certificate may be an ‘unanchored’ certificate. Alternatively, if the customer is using Ping Federate, the customer and iOFFICE have the option of exchanging a connection metadata file to automate the configuration process on both ends.

Base URL:
Endpoint: /sp/ACS.saml2
MetadataDownload (iOFFICE_metadata_2026.xml)

Certificate: Download (iOFFICECert2026.crt)

  • Was this article helpful?