Skip to main content

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

Last updated: Tue, 17 Oct 2017 21:57:25 GMT
iOFFICE Knowledge Center

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

Summary

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 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, 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: https://federation.api.iofficeconnect.com Endpoint: /sp/ACS.saml2
Metadata: Download

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. 

Details

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.

URL

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

 

https://customer.example.com/external/api/login/sso/

Sample Hash Results

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

Pseudo Code Hash Result

MD5("myemployeeid|mysalt") 

d39b6b4e63930982fd4f14b0f48fd071 

MD5("myemployeeid|mysalt|2008-05-07") 

d2c9cfea80e391cb79bc2bcc4a36448c 

MD5(“myemail@example.com|mysalt”) 

fe5ffb4c5ab3378e46aed327e05c32eb 

Parameters

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)

 

 

 

 

HASH ONLY 

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:

SPACE DESKTOP

COPY_DESKTOP

MOVE_DESKTOP

MOVE_REQUEST

  • Was this article helpful?