All Collections
Get Started
Setting up integrations & SSO
Setting up integrations & SSO

Part of phase 4 of onboarding with AlexisHR - this article gives an overview of how to set up our integrations, apps & SSO

Mio Mattsson avatar
Written by Mio Mattsson
Updated over a week ago

This article is a introduction of all things possible to connect with AlexisHR. This can be sent to IT/system admins to prepare them for the things needed to enable the full potential of our integrations and apps - Or if you want to learn more about possible solutions you might want to check out!

Note: Some articles linked down below might require a user in AlexisHR

SSO - Single sign-on

To use Single Sign-on (SSO) means to give users the opportunity to use one user-id and password to sign in to multiple accounts. Once logged in you should not have to re-enter the credentials again (unless there are rules in place that says otherwise).

SSO is the conceptual name and not a technology.

AlexisHR supports SSO via SAML 2.0

When you log in to Alexis with Google Workspace, Azure or Okta you are using SSO via SAML 2.0.


When you use the “Sign in with Google”-button you are using a social login (and not a SSO via SAML)

AlexisHR and Okta

Okta connects any person with any application on any device. It's an enterprise-grade, identity management service, built for the cloud, but compatible with many on-premises applications. With Okta, IT can manage any employee's access to any application or device. Okta runs in the cloud, on a secure, reliable, extensively audited platform, which integrates deeply with on-premises applications, directories, and identity management systems.

AlexisHR’s Okta app is a ready made integration that helps to keep HR and IT in sync. Profile and Employee data updates in AlexisHR inform IT systems, making fully automated user lifecycle management across apps (both SaaS and on-premises) and directories like Microsoft Active Directory a reality. Having your HRIS, like AlexisHR as the source in Okta is called HR as a Source (HRaaS).

SCIM

The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in cloud-based applications and services easier.

The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.

Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols.


In essence: make it fast, cheap, and easy to move users into, out of, and around the cloud.


SCIM uses a Client and a Server. A Client is usually an IdP that has all information about the user (and should be seen as the source of truth). A SCIM Server is most often a Service Provider (like Slack, Hubspot, Gmail etc.).

AlexisHR can act as both but we highly recommend setting us up as a Client!


API

An Application Programming Interface (API) is an interface that defines interactions between multiple software applications [...]. It defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc. It can also provide extension mechanisms so that users can extend existing functionality in various ways and to varying degrees.

Source: Wikipedia

AlexisHR’s API follows the OpenAPI 3.0.0 specification (formerly known as Swagger) and is based on REST. In daily conversation you would say “AlexisHR has a RESTful API”).

Did this answer your question?