Tracker I-9 SSO Integration Guide 05-2026

Benefits 

Benefits of single sign-on and claims-based identity systems include: 

• Reduction in the time taken by users in sign-on operations to individual domains, including reducing the possibility of such sign-on operations failing. 
• Improved security by minimizing the need for users to manage and remember multiple sets of authentication credentials. 
• Faster and more efficient user management for system administrators when adding, removing, or modifying user access rights. 
• Improved security through the enhanced ability of system administrators to maintain the integrity of user account configuration, including the ability to inhibit or remove an individual user’s access to all system resources in a coordinated and consistent manner. 

Claims-Based Identification

Claims-based identity is a straightforward concept, based on a small number of elements: claims, tokens, identity providers, and a few others. 

What is an identity? A digital identity is a set of information about someone or something. This set of identity information is commonly referred to as a security token, or simply a token. A token contains one or more claims, each of which carries a piece of information about the user it identifies. 

 

Who issues tokens and who uses them?  

• Tokens are created by software known as a Security Token Service (STS).  
• Applications that offer an STS are referred to as Identity Providers (IDPs).  
• Applications that rely on an STS are referred to as a Relying Party (RP). 

Open Standards 

• SSO is available for I-9 Complete using an industry-standard format: 

         Protocol SAML-P v2.0 

Token SAML 2.0 

• SSO uses signing certificates to package comprehensive employee data. This is a standard industry practice for all web-based applications.  
• SSO communicates over the Web using the Hypertext Transfer Protocol (HTTP), secured with a minimum of 128-bit Secure Sockets Layer (SSL) encryption, the same mechanism used by all secure websites. 

IDP Initiated SSO 

In an IDP-initiated use case, the identity provider is configured with specialized links that refer to the desired relying parties. These links actually refer to the local IDP's Single Sign-On Service and pass parameters to the service identifying the remote relying party. So instead of visiting the RP directly, the user accesses the IDP site and clicks on one of the links to gain access to the remote RP. This triggers the creation of an SSO assertion that is sent to the RP.  

Tracker does not support SP-initiated SSO. 

 

IDP Use Case 

1. A Web browser or other client acting on behalf of a user gets a token for a particular application from a Security Token Service (STS) owned by some identity provider (IDP).  
2. Once it has this token, the browser or client sends it to the application. 
3. The application attempts to verify the token's authenticity. 
4. If this verification succeeds, the application knows which STS, and thus which IDP, issued the token.  
5. If the application trusts this IDP, it accepts the claims in the token as correct and uses them to decide what the user is allowed to do.   

Dynamic User Management 

In this scenario, you send a complete list of claims needed to create the user.   

• If the provided username does not exist in the system, a new user is created.  
• If the user already exists, their account is updated based on the information in the assertion. If you can send a complete set of user claims, no additional integrations or manual intervention are needed to manage user accounts. 

Authorization Only

In this scenario, you send only one piece of information (username, email, or external id) to identify a user.   

• If the user exists in the system, they are authenticated and granted access.  
• If the user does not exist, access is denied. This approach is recommended only if you create and manage users via Tracker’s API. 

Hybrid 

In this scenario, you send a complete list of claims needed to create a user.   

• If the username does not exist, a new user is created.  
• If the user already exists, they are granted access, but their account is not updated. This approach is recommended if you have enough information to create a user, but plan to update the account manually. With Hybrid SSO, once you manually update a user’s account, the SSO integration will not overwrite those changes during future logins. 

Claim Descriptions 

Description	Assertion Claim Name	Notes
Account Management Type	accountmanagementtype	See Choose an Account Management Type section.  Default is “0” = Auth Only
First Name	givenname	First Name of the User (aka HR Manager, Section 2 Signatory, etc).
Last Name	surname	Last Name of the User (aka HR Manager, Section 2 Signatory, etc).
Job Title	title	The User’s job title to be displayed on the Form I-9 when signing Section 2.
I-9 Complete User Role	role	See Appx B. The role assigned to the User in our application which governs what functionality they can access.
Time Zone ID	timezoneid	See Appx A. The timezone of the User which is used in the application to know when to send scheduled email alerts.
Username	name	This is the username for User Account.  It must be unique across all clients within our system.  Our suggestion is that you concatenate your Client ID with your system’s unique usernames so that you do not encounter conflicts with existing clients’ users.
Email Address	emailaddress	The User’s email address.  It is used to send email alerts.
Phone Number	phone	The User’s phone number. Must be 10 digits.
Extension	ext	The User’s phone number extension. Must be between 1-8 digits.
External ID	externalid	An ID that originates in the client’s system used to uniquely identify a User.
All Client Access	allclientaccess	True/False flag that grants a user access to all I-9s within an employer
Employer ID*	employerid	I-9 Complete’s internal ID for an Employer.  It grants the user access to all I-9s within the scope of one or more Employers.
External Employer ID*	externalemployerid	A partner’s ID or client’s ID for an Employer.  It grants the user access to all I-9s within the scope of one or more Employers.
Security Group ID*	securitygroupid	I-9 Complete’s internal ID for a Security Group (which is a group of other security groups and or worksites - see attached Hierarchy Guide for details).  It grants the user access to all I-9s within the scope of one or more Security Groups.
External Security Group ID*	externalsecuritygroupid	A partner’s ID or client’s ID for a Security Group (which is a group of other security groups and or worksites - see attached Hierarchy Guide for details).  It grants the user access to all I-9s within the scope of one or more Security Groups.
Worksite ID*	worksiteid	I-9 Complete’s internal ID for a Worksite.  It grants the user access to all I-9s within the scope of a Worksite.
External Worksite ID*	externalworkstieid	A partner’s or client’s ID for a Worksite.  It grants the user access to all I-9s within the scope of a Worksite.

* Multiple claims can be sent to assign more than one value for this claim to the user. See the Claim Example – Sending Multiple Values section of the document for details. 

Claims by Account Management Type 

Client Administrator Claims 

The full claim set for the Client Administrator role is described below. Client Administrators leverage fewer claims. 

Description	Dynamic User Management	Hybrid	Authorization Only
Account Management Type	required (“1”)	required (“2”)	do not send
First Name	required	required	do not send
Last Name	required	required	do not send
Job Title	required	required	do not send
I-9 Complete User Role	required	required	do not send
Username	required*	required*	One (and only one) of these three claims is required to identify the User.
Email Address	required	required
External ID	optional	optional

* Used as the identifier to determine if the user exists already or not. 

Claim Details 

Account Management Type 

http://schemas.trackercorp.com/ws/20...managementtype 

http://www.w3.org/2001/XMLSchema#integer 

First Name 

http://schemas.xmlsoap.org/ws/2005/0...aims/givenname 

http://www.w3.org/2001/XMLSchema#string 

Last Name 

http://schemas.xmlsoap.org/ws/2005/0...claims/surname 

http://www.w3.org/2001/XMLSchema#string 

Title 

http://schemas.trackercorp.com/ws/20...y/claims/title 

http://www.w3.org/2001/XMLSchema#string 

Role 

http://schemas.microsoft.com/ws/2008...ty/claims/role 

http://www.w3.org/2001/XMLSchema#string 

Time Zone 

http://schemas.trackercorp.com/ws/20...ims/timezoneid 

http://www.w3.org/2001/XMLSchema#integer 

Phone Number  

http://schemas.trackercorp.com/ws/20...ms/phonenumber   

http://www.w3.org/2001/XMLSchema#string  

Extension  

http://schemas.trackercorp.com/ws/20...phoneextension   

http://www.w3.org/2001/XMLSchema#string  

Username 

http://schemas.xmlsoap.org/ws/2005/0...ty/claims/name 

http://www.w3.org/2001/XMLSchema#string 

Email Address 

http://schemas.xmlsoap.org/ws/2005/0...s/emailaddress 

http://www.w3.org/2001/XMLSchema#string 

External ID 

http://schemas.trackercorp.com/ws/20...ims/externalid 

http://www.w3.org/2001/XMLSchema#string 

All Client Access 

http://schemas.trackercorp.com/ws/20...llclientaccess 

http://www.w3.org/2001/XMLSchema#boolean 

Employer ID 

http://schemas.trackercorp.com/ws/20...ims/employerid 

http://www.w3.org/2001/XMLSchema#integer 

External Employer ID 

http://schemas.trackercorp.com/ws/20...rnalemployerid 

http://www.w3.org/2001/XMLSchema#string 

Security Group ID 

http://schemas.trackercorp.com/ws/20...ecuritygroupid 

http://www.w3.org/2001/XMLSchema#integer 

External Security Group ID 

http://schemas.trackercorp.com/ws/20...ecuritygroupid 

http://www.w3.org/2001/XMLSchema#string 

Worksite ID 

http://schemas.trackercorp.com/ws/20...ims/worksiteid 

http://www.w3.org/2001/XMLSchema#integer 

External Worksite ID 

http://schemas.trackercorp.com/ws/20...rnalworksiteid 

http://www.w3.org/2001/XMLSchema#string 

Claim Example – Sending Multiple Values

This is an example of how you would send multiple Worksite IDs  

<saml:Attribute Name="http://schemas.trackercorp.com/ws/2010/08/identity/claims/externalworksiteid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> 

        <saml:AttributeValue>1</saml:AttributeValue> 

</saml:Attribute> 

<saml:Attribute Name="http://schemas.trackercorp.com/ws/2010/08/identity/claims/externalworksiteid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> 

        <saml:AttributeValue>2</saml:AttributeValue> 

</saml:Attribute> 

<saml:Attribute Name="http://schemas.trackercorp.com/ws/2010/08/identity/claims/externalworksiteid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> 

        <saml:AttributeValue>3</saml:AttributeValue> 

</saml:Attribute> 

Certificate for TLS/SSL (Issuer, Browser Scenario) 

The Transport Layer Security (TLS) protocol, Secure Sockets Layer (SSL) protocol uses a certificate to protect communication with the issuer—for example, for the credentials transmitted to it. The purpose is to avoid man-in-the-middle attacks, eavesdropping, and replay attacks. 

Requirements: The subject name in the certificate must match the Domain Name System (DNS) name of the host that provides the certificate. Browsers will generally check that the certificate has a chain of trust to one of the root authorities trusted by the browser. 

Recommended certificate store: LocalMachine\My 

Example: CN=login.your-company.com 

Certificate for Token Signing (Issuer, Browser Scenario) 

The issuer’s certificate for token signing is used to generate an XML digital signature to ensure token integrity and source verification.   

Requirements: The worker process account that runs the issuer needs access to the private key of the certificate. It must be 2048 bits in key length and use a SHA-256 signature algorithm. 

Recommended certificate store: LocalMachine\My and if ADFS 2.0 is the issuer, the ADFS 2.0 database will keep a copy. 

Example: CN= your-company -tokensign.com  

Note: The subject name on the certificate does not need to match a DNS name. It’s a recommended practice to name the certificate in a way that describes its purpose. 

Code snippet – STSURL and RelayState 

string stsUrl = "https://sts.i9complete.com/{clientId}"; 

string i9Url = "https://i9complete.com/path/to/i9"; 

XmlElement assertion = assertionService.GetSaml2(); 

var encoding = Encoding.GetEncoding("iso-8859-1"); 

var samlResponse = Convert.ToBase64String(encoding.GetBytes(assertion.OuterXml)); 

var html = new StringBuilder(); 

html.Append("<html>"); 

html.Append("<body onload=\"document.forms.samlpost.submit()\">"); 

html.AppendFormat("<form id=\"samlpost\" method=\"post\" action=\"{0}\">", stsUrl); 

html.AppendFormat("<input type=\"hidden\" name=\"SAMLResponse\" value=\"{0}\">", HttpUtility.HtmlEncode(samlResponse)); 

html.AppendFormat("<input type=\"hidden\" name=\"RelayState\" value=\"{0}\">", i9Url); 

html.Append("</form>"); 

html.Append("</body>"); 

html.Append("</html>"); 

var response = Response.AsText(html.ToString()); 

response.ContentType = "text/html"; 

return response;