search cancel

SP initiated URL is throwing HTTP 400 error with session assurance

book

Article ID: 133892

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On SITEMINDER

Issue/Introduction

CA access gateway session assurance component alters raw SAMLRequest, which makes SAMLRequest become invalid after passing through session assurance .

SP initiated URL request is throwing HTTP 400 error, but IDP initiated URL request seems working fine.

Cause

Faulty session assurance component on access gateway related to url encode/decode.

SP initiated federation request on 12.7 base setup, user does not have smsession to begin with, so login is required.

Once SAMLRequest is passed through session assurance component,

when comes back, SAMLRequest content is altered. 

%2B becomes +, %2F becomes / , thus SAMLRequest is no longer valid. 

FWStrace transaction error:

[29880/140256324392704][Mon Apr 15 2019 15:25:04][SSO.java][ERROR][sm-FedClient-02890] Transaction with ID: 6cad6836-bc50f9f6-ddd9c3a4-50c3350c-d7efa07e-2c0 failed. Reason: BAD_SAML_REQUEST_ENCODING (, , )

apache request log shows below:

x.x.x.7 - - [26/Apr/2019:14:18:56 +0000] "GET /affwebservices/redirectjsp/redirect.jsp?SAMLRequest=lVJdT%2BMwEPwrkd%2FjfJC21.....Fmw3Odvdra%2FKMq3TSZbFU5xnswzKqZzLuILJDBHm1QikAojUgO%2BrRD1uNTnQLmdpnMzDOAvT6T7JRHItJhM%2Bu0r%2FsKC4BPND6Urpw9cplmcQiZv9vgiL%2B93eEwyqQns3ov83wEe05MMbydly4bMQ3rn92O3XpuCtULb8Vn0RfdS4KHbi5H27KcxYyEuwahpzXFsEN97jbI%2B%2Bmhbcv20kPPEvqgprDxW9pg6lqhVWLFpeZD%2F%2F3uUr&RelayState=https%3A%2F%2Fxxxxxxxx.com%2Fpage.do&SMPORTALURL=https%3A%2F%2Fxxxxxxxxxxxx.com%2Faffwebservices%2Fpublic%2Fsaml2sso&SAMLTRANSACTIONID=13555dc8-646ddfc8-a52897e1-c83341a1-e7b0c04f-7303 HTTP/1.1" 302 -

x.x.x.7- - [26/Apr/2019:14:18:56 +0000] "GET /authapp/flows/i/session_assurance_flow.html?SMAUTHREASON=53&SMAGENTNAME=-SM-7UFLyOuvUIz0WEp%2fGBDe%2bh5MctYO19ioyDO8wt%2ff1azs21z7uWIEf8AtGX9ObqLV&TARGET=-SM-HTTPS%3a%2f%2fxxxxxxxxxxxxxxxcom%2faffwebservices%2fredirectjsp%2fservicenowdev%2fredirect%2ejsp%3fSAMLRequest%3dlVJdT-%2BMwEPwrkd-%2FjfJC21Goq9VqdqMRBRHs83NvG2RRLiR28Tnr8e1K3CHg40L16Z2dm.....................m3Nz0R-%2BE-%2Br6iOWFj6KuLxslPTwlGtl-%2BGivRn5ezGhpCFmw3Odvdra-%2FKMq3TSZbFU5xnswzKqZzLuILJDBHm1QikAojUgO-%2BrRD1uNTnQLmdpnMzDOAvT6T7JRHItJhM-%2Bu0r-%2FsKC4BPND6Urpw9cplmcQiZv9vgiL-%2B93eEwyqQns3ov83wEe05MMbydly4bMQ3rn92O3XpuCtULb8Vn0RfdS4KHbi5H27KcxYyEuwahpzXFsEN97jbI-%2B-%2Bmhbcv20kPPEvqgprDxW9pg6lqhVWLFpeZD-%2F-%2F3uUr%26RelayState%3dhttps-%3A-%2F-%2Fxxxxx.......com-%2Fpage%2edo%26SMPORTALURL%3dhttps-%3A-%2F-%2F..........%2ecom-%2Faffwebservices-%2Fpublic-%2Fsaml2sso%26SAMLTRANSACTIONID%3d13555dc8--646ddfc8--a52897e1--c83341a1--e7b0c04f--7303 HTTP/1.1" 302 -

x.x.x.7- - [26/Apr/2019:14:18:56 +0000] "GET /authapp/mfpcollector.jsp HTTP/1.1" 200 2127

...

x.x.x.7- - [26/Apr/2019:14:18:58 +0000] "POST /authapp/sasignaturereceiver HTTP/1.1" 302 -

x.x.x.7- - [26/Apr/2019:14:18:58 +0000] "GET /siteminderagent/redirect.sac HTTP/1.1" 302 -

x.x.x.7- - [26/Apr/2019:14:18:58 +0000] "GET /affwebservices/redirectjsp/redirect.jsp?SAMLRequest=lVJdT+MwEPwrkd/jfJC21Goq9VqdqMRBRHs83NvG2RRLiR28Tnr8e1K3CHg40L16Z2dmZ7wgaJu0E6vePekHfO6RXPC3bTSJ8yRnvdXCACkSGlok4aTYrX7dipTHorPGGWkaFqyI0Dpl9Npo6lu0O7SDkvj74TZnT851JKLIgT2gq3DgdJ6G2hy5NG2kYejggLwyLNiMHpSGE9n76skNV9DyDm3Nz0R+E+r

So we know that SAMLRequest was good before entering /authapp/mfpcollector.jsp and /authapp/sasignaturereceiver.

But once it reached /siteminderagent/redirect.sac, it is already changed. This matched with fiddler trace result too.

%2B becomes +, %2F becomes /

Fiddler trace (session_assurance.saz):

Frame 41

SAMLRequest=nVJBbtsw............bW0Nij26E7aoU%2FH%2B9L9uz9QDJJPLgDegLT1PaV0wURG3viyvaJgeMAB%2BSNZdFm8qENnAnfxs%2BOuIaeD%2BhafiELk9C2J6.....................2UaMStIQ%2FGl0ykWRGneSyKfTaXIpd5zovZ%2FBeLqms437RptDl8nWR9AZG82%2B%2BruPqx2weCo27QPUzo%2FwnxCR2FACcBtlyEPGRw7953%2FLUx%2BFssW%2F6Tg0XyXueqOsjzDttNZadifkerrrOntUPw017ejRgq6sF%2FbiXjWXjRTdwGqBwNDah0q7FhyfIq%2B%2FGSl38A

Frame 49

POST /authapp/sasignaturereceiver HTTP/1.1

Frame 50

GET /siteminderagent/redirect.sac HTTP/1.1

Frame 51

GET /affwebservices/redirectjsp/redirect.jsp?

SAMLRequest=nVJBbtswE.........bW0Nij26E7aoU/H+9L9uz9QDJJPLgDegLT1PaV0wURG3viyvaJgeMAB+SNZdFm8qENnAnfxs+OuIaeD+hafiELk9C2J6yvfJQMY91pFeCCaGK7tU5hWLFkLXSELNpuSrZ7WN8oMZs3RZ0W4mZWNJDVIlVY1LO6zZTIz0CqgEgf8W2UaMStIQ/Gl0ykWRGneSyKfTaXIpd5zovZ/BeLqms437RptDl8nWR9AZG82++ruPqx2weCo27QPUzo/wnxCR2FACcBtlyEPGRw7953/LUx+FssW/6Tg0XyXueqOsjzDttNZadifkerrrOntUPw017ejRgq6sF/biXjWXjRTdwGqBwNDah0q7FhyfIq+/GSl38A&RelayState=https://xxxxxxxx.com/navpage.do&SMPORTALURL=https://xxxxxxxx.com/affwebservices/public/saml2sso&SAMLTRANSACTIONID=10775ff4-18cc0291-41b0fde1-04112166-71287ce8-fce HTTP/1.1

There is no configuration customer can do to change this behavior. ACO SecureURLs if used could break many other applications flow in production.

And  "POST /authapp/sasignaturereceiver" makes it not visible to what data was being sent, even though what was sent most likely unrelated to SAMLRequest itself.

Once SAMLRequest content is changed, it becomes invalid.

Environment

Release :12.7

Component : SITEMINDER - CA Access Gateway

Resolution

Dev fix sessionassurance.war in CA access gateway was provided to customer DE417198.