SSO / SAML Integration Specifications

Overview:

This document outlines the 1-way CLIENT to Unefi RMS SSO/SAML implementation and covers five primary functionality oriented areas:

• Assertion Attributes
• Unefi RMS URI
• Certificate Authority
• CLIENT to Unefi RMS store listing
• CLIENT to Unefi RMS User Marriage

Assertion Attributes:

There isn’t a tangible XML document or schema to represent a SAML assertion attribute collection, so the following keys need to be used by CLIENT when constructing the assertion and by Unefi RMS when consuming the request. If these case sensitive names are not present, misspelled or are of a type not outlined below, this contract will fail on the Unefi RMS side. Also, it is customary to send the key in the subject, but not required.

Field Descriptions

Field	Type	Description
userID	String	Unique user identifier
emailAddress	String	User email address
fName	String	First Name
lName	String	Last Name
store	String[]	Array of stores this user has access to
allStoreAccess	Bool	Flag to determine if the store array is empty and should be treated with authority to all store access (System Administrator)

Unefi RMS Assertion URI:

key="AssertionConsumerServiceURL" value="http://CLIENT.unefi.com/saml/index.php" key="SPTargetURL" value="http://CLIENT.unefi.com/"

Certificate:

Unefi requires CLIENT’ certificate, .cer, file exported and delivered. In addition, CLIENT and Unefi RMS will HAVE to be on the same page re: CLIENT certificate renewals for scheduled retesting per renewal. It is up to us to mutually decide what part of the SAML response is signed: The Message Signature, or Signed Assertions, or both. Since no sensitive data is sent in the SAML response, it is not necessary to encrypt the assertion.

Store:

All possible CLIENT user stores will be mapped from CLIENT to Unefi RMS in one of two ways: an array of string (assertion attribute array) or a single string, comma separated (or other delimiter if desired); both are a single assertion attribute. Based on the requirement, if a user doesn’t have a store in the assertion, they’re supposed to have access to all stores. Just to make sure and to avoid null reference on the store array, We are suggesting a flag to identify this ‘all store access’ so the array doesn’t have to be checked when it’s supposed to be empty.

CLIENT to Unefi RMS User Marriage:

Since the assertion attribute ‘userID’ is the SSO key, the validity of the CLIENT user is guaranteed after the assertion signature is verified, in the two ways previously mentioned, against the signing cert. Post validation, if the user doesn’t exist in the Unefi RMS environment, it is assumed that a 1-time user handling will be performed.

---