Considerations for setting up My Domain and SSO

1. If you are using My Domain, you can identify when and which users are logging in with the new login URL. We can follow the path Your Name | Setup | Manage Users | Login History to look at the Username and Login URL columns. 

2. When you use My Domain, since the target hostname at Salesforce is unique to your Organization, the correct IdP data for SSO can be looked up immediately from your own SSO configuration. 

3. Use of My Domain when you have multiple Orgs (either production or sandboxes) allows your users to use exactly the same Salesforce Username for all of their Orgs. 

This makes using SSO against your IdP-side credentials (AD, LDAP, Integrated Windows Authentication, etc.) easier since there is only one IdP identity per user that needs to be verified. In the best case, this means that one SSO login at one Org will allow that user access directly to any of their other Orgs without a new login. 

4. Also in the case of your own domain, you have your own SSL (hence increased security) and better SSO because you are using your own domain name rather than Salesforce. This improves your SSO because your name is in the domain. 

5. When you are doing SAML SSO into Salesforce by starting with a Salesforce link (login page, deep link, Outlook Sync URL, etc.), Salesforce will not know in advance what Identity Provider you need to use, since it does not even know yet what Organization you are trying to SSO into. 

This process is referred to as SP-initiated SSO, and is distinct from the scenario where you start SSO at the IdP and send the identity information to Salesforce along with SAML protocol information that identifies your Organization and your IdP (IdP-initiated SSO).  For generic login page setups, SP-initiated SSO requires that the user do an IdP-initiated SSO at least once first so that Salesforce can set a cookie in their browser identifying the IdP.

6. If SSO is enabled for your organization, API and desktop client users can't log into Salesforce unless their IP address is included on your organization's list of trusted IP addresses or on their profile, if their profile has IP address restrictions set.

7. Furthermore, the SSO authority usually handles login lockout policies for users with the “Is Single Sign-On Enabled” permission. However, if the security token is enabled for your organization, then your organization's login lockout settings determine the number of times a user can attempt to log in with an invalid security token before being locked out of Salesforce.

8. We do recommend customers not to enable single sign-on for system administrators. If your system administrators are single sign-on users and your single sign-on server has an outage, they have no way to log in to Salesforce. System administrators should always be able to log in to Salesforce so they can disable single sign-on in the event of a problem. 

Important links:

Please go through the below link in regards with the security concerns: