Describe IdP-initiated SAML workflow

Describe the SP-initated SAML Workflow

What is SAML
SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) such as Okta, and a service provider (SP) such as Box, Salesforce, G Suite, Workday, etc, allowing for a Single Sign-On (SSO) experience.
What does SAML do?
SAML completely changes how a user signs into a SAML-supported site or service.
Once an SP (e.g. Box or Salesforce) is configured to authenticate via SAML, users attempting to access its service will no longer be prompted to enter a username or password specific to the SP they are logging onto (e.g. a Box username and password). Instead, an exchange between the SP and the configured IdP will occur that will verify the user’s identity and permissions, and then grant or deny that user’s access to the SP.
What won’t the user have to do once SAML is enabled?
Instead of using user credentials (like a password) to verify a user, a SAML-configured service verifies that user’s identity with the IdP. Of course, this assumes the user has already logged into the IdP with a username and password (and ideally multi-factor authentication as well!).
What is SAML JIT Provisioning?
It occurs in the IdP-initiated flow.
How do SAML Assertions work?
Both IdP and SP initiated authentication flows rely upon assertions that are passed between the user’s browser and URLs that are specifically created to handle SAML traffic (known as endpoints). These assertions are in XML format and contain information that verifies who the identity provider is, who the user is, and whether the user should have access to the SP. At a basic level, a successful SP-initiated SAML flow occurs as follows:

What is ACS
Assertion Consumer Service or Entity ID
What are some of the inherent issues/troubleshooting with Assertion
What are deployment best practices
Begin by verifying the following information from the Service Provider you intend to integrate with Okta:
Whether standard login methods are disabled once SAML is activated, and if so, if there is another way for users to log in traditionally (using a username and password) if Okta authentication is disrupted.
If possible, it’s best to create at least one “service account” on the SP side that can bypass SAML and access its admin console via their login page. This will allow a “back door” entry in the event that the SAML flow is interrupted for any reason. Some service providers (G Suite, for example) bypass SAML automatically if the user is a member of a particular administrator group.
More deployment best practices
The endpoint information discussed above
Whether they support IDP and/or SP initiated authentication flows
Whether they support potentially useful features such as JIT Provisioning and Single Log Out (SLO)
What SAML attributes they expect to receive in the assertion
We also recommend familiarizing yourself with tools such as Fiddler and the aforementioned SAML Trace utility to examine the SAML assertion. Okta Support will occasionally require output from one of these tools to help determine what is causing a SAML assertion to fail.
What are the steps information that you will need from the vendor/developer?
You will also need to provide the vendor/developer with the following information from the Okta application (accessed via the View Setup Instructions button in the application’s Sign On tab):
The Identity Provider Issuer. This is often referred to as the Entity ID or simply “Issuer.” The assertion will contain this information, and the SP will use it as verification.
The x.509 Certificate. Some service providers allow you to upload this as file, whereas others require you paste it as text into a field.