SAML2 request from Okta to configured Idp doesn't contain Subject related information

I have created a custom OpenIDConnect app in Okta. I have also configured a SAML2 Idp and added necessary routing rules for this idp.

Everything is working fine including SSO login and SLO logout. But there is a case which is not working as expected.

When the user is redirected from my app to Okta and enters the email address, it redirects to the idp. Once the user authenticates in the idp it redirects back to Okta and Okta redirects user back to my app. Now when the user logouts from my app I am using SLO and redirecting him to Okta to invalidate the session at Okta end. Upto this point it is working fine and as expected. Now if I again try to login with different email address on the Okta sign in page, it redirects the user to idp but instead of asking the user to authenticate at idp with new email address, the idp returns the response of the previous user itself. Now at Okta end the user is getting logged in by the initial email address itself and subsequently in my app as well.

I have debugged using SAML Tracer and found out that the SAML Request sent by Okta to the Idp is not having any Subject Information. The AuthnRequest contains only the Issuer, Signature and NameIDPolicy info. There is nothing related to Subject and NameID which should ideally contain the email address that was entered on the Okta Sign In page. Am I missing something? Is there any configuration that needs to be done to include Subject and NameId in the request?

It sounds like the previous user is still logged in with the IDP so when the new user is redirected to the IDP, it returns the the previous user’s information to Okta. I don’t believe Okta will log you out of the IDP.

Yes the previous user is still logged in with the IDP. But when a new SAML request is posted to IDP from Okta, if there is a subject information(email address in this case) in the request then I believe IDP will not respond with the previous user’s information and is forced to authenticate the new user. But in my case that information isn’t present in the SAML request originating from Okta.