Benefits of Identity Provider initiated SAML login requests

What are the Benefits of Identity Provider initiated SAML login requests?

As smaller organizations continue to grow and expand their application usage, one thing that SMB’s should keep in mind is application access and security.

At the start of a new organization, owners or stakeholders are not thinking too much about security or access. They simply wish to purchase a product and move forward with their business. As the business continues to grow so does the applications the organization utilizes. It may start off with a email solution followed by a storage solution, or even a CRM application with permission levels. As time goes by, the organization finds themselves with many applications they need to access. As more employees join the workforce, the application owners find they need to start granting end-user access.

Soon the organization has their users managing not one, or two passwords, but many passwords. This leads to users having to remember all their passwords. They may write them down on a notepad, on a sticky note that’s on their desktop monitor, or the user might just start using the same password for all their applications.

Why you want to enable SAML!

This method of application access leaves your organization vulnerable to security breaches. Whether it is from someone finding out the username/password to an application because a user left their password on a notepad or from external brute force attacks/phishing attempts. This is especially true if your users do not have MFA enabled at the application level.

This can all be avoided by enabling SAML 2.0 for applications through a Identity Provider(IdP). Not only would this cut down on the amount of password the end-user would need to remember, but it also allows the organization to enable MFA in front of the SAML 2.0 Enabled applications.

As we can see in the diagram below, when a user accesses a SAML enabled application through an IdP such as Okta. There are a few actions that are taking place.

First the user navigates to the IdP. As the user has not signed into the IdP, business logic dictates that the user needs to verify who they are. They enter their username/password into the login page, if MFA is enabled the user also goes through the MFA process. The information is then sent back to the IdP. From here the information is validated with Active Directory. If all checks pass, the information is sent back to the IdP and the user is displayed the user interface for the IdP. As the user has successfully authenticated with the IdP, when the user clicks on a SAML enabled application the user will already be authenticated. In this instance the user will only see a redirect occur.

With an IdP initiated SAML login, the user does not need to know or manage the password at the application level. All they need to remember is their IdP credentials. If MFA has been configured the organization can have a head to pillow mentality when it comes to the security of their SAML integrated applications.

Note In our diagram above we have decided to show Active Directory, however Okta does have its own directory to manage users. Thus Active Directory is not required to enable SAML 2.0 on applications.