Skip to main content

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

Last updated: Thu, 18 Oct 2018 15:21:17 GMT
iOFFICE Knowledge Center

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


This section 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 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

Certificate: Download

Token and Hash Based

The token and hash-based interface is designed for customers that do not have an existing federated identity solution or are looking for a simple solution for use with their corporate intranet. 


The customer’s corporate intranet provides user authentication, generates a hash and forwards the user to a URL. The hash is used to verify the link was generated by an authorized source, such as the customer’s corporate intranet.


The hash is generated in part by using a salt and the user’s identifying value. The salt is a string, similar to a password, provided to iOFFICE by the customer. Optionally, adding the current date (in GMT) ensures that the hash is only valid for twenty-four hours. Append the date to the hash using the YYYY-MM-DD format.


The below address is the URL the customer’s intranet will forward the user to. Parameters are accepted via HTTP POST or HTTP GET.

Sample Hash Results

The customer’s developer verifies their hash implementation using the below samples. 

Pseudo Code Hash Result








Name Value

property (required

Ex: ‘employeeid’, ‘email’, ‘username’... 

user (required) 

The value used to identify the user (see property). 

hash (required

A MD5 representation of the id, a salt, and optionally a date; these fields are be separated by the pipe character. 

landing (optional)






A “Landing Page” to redirect the user to after logging in instead of the desktop (default). When used all users must have permission in the application to the desired landing page. 


The following are valid landing pages:





  • Was this article helpful?