Single Sign-On (SSO)

understanding and configuring single sign on (sso) for stratosphere single sign on (sso) is a method of authentication that allows users to log in once using a single set of credentials and then access multiple applications without having to re enter their username and password for organizations, sso improves security by centralizing authentication, while for users it enhances convenience by reducing the number of logins they must remember by enabling sso in stratosphere, you ensure that only authenticated users from your trusted identity provider (idp) can access your system this reduces the risk of weak passwords, phishing, and unauthorized access why use sso? improved security authentication is managed by a trusted idp such as okta, azure ad, or google workspace this makes it easier to enforce strong password policies, multi factor authentication (mfa), and monitoring user convenience users sign in once and gain access to multiple apps, reducing login fatigue centralized access management admins can control user access from one place, simplifying onboarding and offboarding compliance ready helps align with regulatory requirements like hipaa, iso 27001, and soc 2 steps to configure sso in stratosphere domain verification setting up sso in your stratosphere org requires domain validation to ensure ownership before it can be enabled with an administrator account, navigate to organization > add/remove features, then scroll down to the single sign on section input your domain name copy the txt dns record value access your public facing dns system add or append the data into the txt record for your domain note stratosphere checks dns records approximately every 15 minutes dns propgation can take up for 48 hours the domain in stratosphere will change to verified once the record is validated note the dns txt record must always exist for the domain to stay verified and sso to be functional sso idp configuration the identity provider can be configured once the domain has been verified configuration may vary slightly depending on your provider entra/azure ad is used for this example navigate to https //portal azure com and login navigate to enterprise applications and click the new application button click on the create your own application button name it appropriately, for example, stratosphere , and click the create button optionally, assign users and/or groups as to who is allowed to access stratosphere navigate to the set up single sign on area of the entra enterprise applcation you created configure the basic saml configuration options by clicking edit for identifier (entity id), copy the value found in the stratosphere single sign on section for the reply url (assertion consumer service url), copy the value found in the stratosphere single sign on section the other url options, if present, are not required attributes and claims can be left as they are stratosphere requires the following to be passed in meta data givenname > user givenname surname > user surname emailaddress > user mail name > user principalname unique user identifier > user principalname note a user's given and surname will automatically be updated in stratosphere if it changes in the identity provider copy the login url from the entra enterprise application and paste it into the sign in url field in stratosphere download the x509 certificate from the idp and upload it into stratosphere other settings in the application can be modified as desired without impacting the sso configuration sso is now ready to be tested note automatic user provisioning is not supported at this time strict mode by default, stratosphere allows mixed mode logins this means users can log in with their username and password as well as sso it is recommended to leave strict mode disabled while testing the sso configuration works properly if strict mode is enabled, username and password authentication will no longer be allowed; users must use sso to gain access to stratosphere contact terso support if all administrators are locked out to have sso switched back to mixed mode login best practices keep a backup admin account maintain at least one non sso admin account this prevents lockouts if your idp is unavailable or misconfigured roll out gradually test with a small group of users before enforcing across the organization enable mfa at the idp strengthen authentication by requiring multi factor authentication