SP initiated URL is throwing HTTP 400 error with session assurance
Article ID: 133892
Updated On:
Products
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.
Environment
Release :12.7
Component : SITEMINDER - CA Access Gateway
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.
Resolution
Feedback
