What is Single Sign-On?
Simple definition:
SSO is your one click access to multiple applications using one set of login credentials. Applications maybe located internally in your enterprise or hosted in the cloud. Application access is generally made through an application portal.
Which SSO solutions do we support?
SOLABS QM has the ability to leverage the functionalities of the following external Single Sign-On (SSO) solutions: Microsoft Azure, Onelogin and Okta.
How does the SOLABS External SSO connector works?
Like in any SSO solution, the External SSO connectors have two distinct parts: the SAML connector and the SSO connector.
SAML Connector
The SAML connector is the part of the solution that is responsible for the seamless transitions from the application dashboard or portal to SOLABS QM. This is where the magic is seen by the end user! It will automatically send the credentials from to SOLABS QM and redirect the end user directly in the application without him having to type in is username and password.
SSO Connector
The connector is used to authenticate to an external SSO user directory. It acts like the traditional authentication methodology: the end user needs to enter is username and password to either get acess to the system or in 99.9% of the time in SOLABS QM, to perform an e-signature.
Limitation
Currently SOLABS QM has many authentication types, but once this authentication type is activated in the system, all other types become unavailable.
Schema of authentication sequences
Authentication sequence over SAML
Authentication sequence using the SSO connector
Can external users access my SOLABS QM through Azure SSO?
Yes, you can grant access to external users such has manufacturers, vendors, clients, auditors, etc. and still use the SSO feature. SOLABS QM pulls its user information from the Azure Active Directory, therefore any user available there can be granted access to the software.
Microsoft has a feature called B2B collaboration, which enables you to add users that are not from your Azure Active Directory.
Microsoft B2B collaboration feature currently supports 4 different account states:
- State1: Homed in an external instance of Azure AD and represented as a guest user in the inviting organization. In this case, the B2B user signs in by using an Azure AD account that belongs to the invited tenant. If the partner organization doesn't use Azure AD, the guest user in Azure AD is still created. The requirements are that they redeem their invitation and Azure AD verifies their email address.
- State2: Homed in a Microsoft or other account and represented as a guest user in the host organization. In this case, the guest user signs in with a Microsoft account or a social account (google.com or similar). The invited user's identity is created as a Microsoft account in the inviting organization’s directory during offer redemption.
- State3: Homed in the host organization's on-premises Active Directory and synced with the host organization's Azure AD. You can use Azure AD Connect to sync the partner accounts to the cloud as Azure AD B2B users with UserType = Guest.
- State4: Homed in the host organization's Azure AD with UserType = Guest and credentials that the host organization manages.
For more information on Microsoft B2B feature please consult the article here.
Comments
0 comments
Please sign in to leave a comment.