Single Sign-On
Single Sign-On(SSO) allows the user to be authenticated once, after which the use of multiple services without re-authentication is allowed. Additionally, single sign-on allow user, to log in Tabella with username provided by her own organization.
Single sign-on provides a solution for both end users and IT -department. End users can avoid repeated logins in to several different services, thus streamlining their work. At the same time, it also provides a solution for forgotten passwords, because user authentication is done by the organization itself. Therefore the same username is valid, both to the organisation’s own services and to Tabella. Furhermore, the IT department can better influence users authentication. For example, if an organization has a widely used Multi-factor authentication (MFA / 2FA), then those configurations are also used in single sign-on. Similarly, if employee leaves company, his user rights to Tabella is immediately denied, when he is removed from the organization’s user list.
Note
Single sign-on is offered only in the Tabella Cloud service.
Implementing single sign-on
We use the SAML2 protocol to implement single sign-on. Implementing single sign-on requires that the customer organization is using an Identity Provider (IdP) service, that supports SAML2 protocol. For example, if your organization has Windows Active Directory (AD), then in addition to this, you need Active Directory Federation Services (ADFS) service.
List of common supported IdP services
ADFS
Azure AD
Shibboleth IdP
Okta
Google
Note
Please notice, even if you have one of IdP services, mentioned above, enabled, adding a new SAML2 application to it, may incur additional costs. Please check in advance, what SAML2 implementation will require for IdP-service.
Frequently asked questions
What does the implementing of single-sign-on requires from the customer?
Single sign-on implementation requires technical support from the customer i.e. a contact person, with whom integration can be build between services
Is it needed to create user names to Tabella, if SSO is in use?
Usernames must be set up in the Tabella, in the same way as before. With single sign-on the user management can’t be automatized for an external system yet. This is largely due to application-specific user rights management.
How does Tabella identify, which person in the organization corresponds to what Tabella user?
Every person using Tabella, must have own user name being setup. This means that Tabella must identify who corresponds to what Tabella username. Persons who do not have a username in Tabella, will not be able to log in. User authentication can be done based on the following information: username, alias, email. We use often the UserPrincipalName (UPN) record, while indentifying user. Then the equivalent information must be found in one of the three above mentioned basic user information.