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.
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).
Both IDp initiated and SP initiated Single Sign On/Single Log Out are supported with SAML 2.0.
The customer will provide their entity id, base URL, end point 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.
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|
Ex: ‘employeeid’, ‘email’, ‘username’...
The value used to identify the user (see property).
A MD5 representation of the id, a salt, and optionally a date; these fields are be separated by the pipe character.
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: