support ExternalAuthnConfiguration as well as Password Flow at the same time.

[Cantor, Scott]

> 1.  Added all the required flows
> idp.authn.flows=Password|Facebook|Google, Registered the bean in
> general-authn.xml file, added new Servlet entry in Web.xml file and added
> multiple metadata for each flow in Shibboleth2.xml file.

There's no metadata for these, so I don't know what that means.

> When I hit any Idp from discovery URL it always choose Password flow which is normal
> behaviour, later I updated the URL from idp/profile/SAML2/Redirect/SSO to
> idp/authn/facebook?conversation=facebook in one of the Metadata's file
> and when I select particular Idp, It goes to external authn flow but see error
> as No conversation state found in session for key (facebook).

That's not how it works. Controlling the flow used is a function of the SP requesting an AuthnContextClassRef that maps to a Principal type associated with the specific login flow you want to use. This is not about endpoints. The endpoint cannot change and there is only one. That explains your metadata comment above: you can't do that.

> 2. Second I looked into the ShibRequestSetting authnContextClassRef
> urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken,I added this
> attribute in our virtual host and updated general-authn.xml file and seems
> like it solves the issue but one vhost can point to one login flow but I want all
> the flow should be enabled for the same vhost.

Then your application code needs to control it and tell the SP what it wants to have happen. The system can't just guess which value to use.

> 3. I read about SessionInitiator tag i.e. I have added below snippet into
> Shibboleth2.xml file but this property is getting set for each entity Id that I
> have registered not to the particular entityID that I mentioned in tag.

You don't need to add a SessionInitiator, and your entityIDs for the IdP are not specific to the authentication type, that is not how this works. You have one IdP. You tell it what you want done by requesting the context class to use, and then enforcing that during authorization.

> I had an internal discussion as well about upgrading IdP 3.2.1 to 3.3

You need to upgrade because that is what you have to do to run this software. You upgrade because that's what it means to operate software safely.

> and I read about ExternalAuthnPathStrategy i.e.
>   As of V3.3, you may dynamically derive the path to use, typically so that it
> can vary based on aspects of the request, by defining a bean named
> shibboleth.authn.External.externalAuthnPathStrategy of type
> Function<ProfileRequestContext,String>

That's used if you need to support multiple versions of the External authentication flow at the same time without having to copy the flow and deploy it separately. It's just a more convenient way of ending up in the same place.

> Please let me know if you think by upgrading I can get my solution easily or
> by doing some changes to my current setup or point me something which I
> am missing in above 3 points.

You need to upgrade because that's just how it is.
 
You're also coming up against to the limit of what somebody not funding the project can expect to get for free. Have your organization fund the project [1] and you'll be amazed how much help you get from me. Open source isn't free. I answer casual questions happily because they don't take time. You're asking for much more detailed help.

-- Scott

[1] http://shibboleth.net/consortium/fees.html