Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Update SAML filter to add support for XML requests

Description

The SAML filter currently only supports HTTP POST Binding, but there appears to be consumers sending in raw XML requests (i.e. unwrapped HTTP POST Binding requests) to Identity that we should continue to support until the consumers can get updated.

We're going to get rid of the check that requires the request to be form encoded. The filter will accept form encoded XML and XML (application/xml). We don't have to force XML requests to go through Flow 1 (i.e. if the issuer of an XML request is not in the list of legacy issuers, go through the Flow 2 logic).

Acceptance Criteria:

  • The filter processes an application/xml request the same way it would if the request was a form encoded XML request.

Environment

None
100% Done
Loading...

Activity

Jorge Williams February 23, 2017 at 4:42 AM

Yes, if the SAML filter receives an XML request – and you should know that it's XML because the content type is application/xml

For options, I'm saying those are two possible paths you guys can take – take the path that works best for you keeping in mind that we need to turn this around quickly.

Jorge Williams February 23, 2017 at 4:39 AM

It's okay to simply configure the legacy issuers and make the unpacking optional. I'm okay with accepting raw XML as well for v2.0 flow – especially if this turns things around faster.

Identity will be asking for encoded requests in documentation – and if we need to ensure that 2.0 requests are always encoded we can add that later.

Mario Lopez February 23, 2017 at 12:54 AM

To be clear, you mean if the SAML filter receives an XML request since it wouldn't go through AttributeMapper at all, right?

Also, for the options, are you asking for input from Repose on which option we recommend? Or are you saying we should add configuration to let Identity decide which option to go with (and if it's the second option, which endpoint to go to)?

Adrian George February 22, 2017 at 9:24 PM

Is there a large variance in issuers here? Otherwise i'd rather have them configure the issuers and we just optionally unpack from form encoding.

Jorge Williams February 22, 2017 at 9:11 PM

Here's the flow

If an XML request is sent to AttributeMapper (because we have a Content-Type of XML).

Then we have an option of:
1. Treat the request exactly as a Legacy v1.0 flow (even if the issuer is not in the issuers list) by forwarding the XML to identity. You should include the Version header etc.
OR
2. Forward the request, as is, to the endpoint `../RAX-AUTH/saml-tokens` – which is the legacy Federation endpoint. You need not include a version header if you use the alternate endpoint.

You do not need to guarantee signatures for these requests.

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Capitalizable

True

Story Points

Original estimate

Time remaining

0h

Sprint

Fix versions

Priority

Parent

Created February 16, 2017 at 9:44 PM
Updated May 14, 2018 at 4:06 PM
Resolved February 24, 2017 at 9:03 PM