I am implementing a SAML 2.0 Service Provider which uses Okta as the Identity Provider. I would like to configure the Assertion Consumer Service (ACS) URL so that the SAML 2.0 from my Service Provider app is reflected back in the assertion.
However, I am noticing that the Okta Identity Provider instead sends the SSO Endpoint configured in the Okta configuration and ignores the ACS that was actually sent. Also, I get an error perhaps the ACS from SP doesn't match the meta-data there.
If ACS URL is not the right way to send a short ID to IDP for it to reflect back in the assertion, what other mechanism can be used for this purpose.
Example:
The SAML 2.0 SAMLRequest sent by the SP app is:
assertion_consumer_service_url: https: //host.com:port/saml/consume? entityId=N&myName=username
The configuration on Identity Provider has the meta-data:
Single Sign-on URL: https: //host.com:port/saml/consume?entityId=N
Note that the myName changes from one request to the next, as it is our way of verifying that the response has name_id which matches the original username being sent.
Also, if there is a way for the Service Provider to let the Identity Provider assert that an SP-managed name (such as username), that would be fine for our needs. How does one specify this?
Thanks
In SAML, the ACS is assumed to be static for a SP. To correlate the Response with the originating AuthnRequest you should save the ID of the outgoing AuthnRequest and then use the InResponseTo
of the received response.
The SP can add a subject to the AuthnRequest, telling the IdP what username you want to have authenticated. It's defined in section 3.4.1 in the SAML2 Core spec.