How do I see a SAML response?

Go to System->Logs-Configuration->Options and turn up SSO log level to Debug. Then, after a failed authentication attempt, look at the apm log in /var/log/apm and see if there are any clues there regarding parsing SAML response. You can also use SAML Tracer(https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) for Firefox to see actual SAML requests and responses to see what is being sent/received.

How can I see the SAMLResponse on the F5 side?

I would imagine this isn't necessary. Using a tool like SAMLTracer (a Firefox plugin), you should be able to see exactly what the APM SP is begin sent.

Thanks for the responses guys.

We are using Fiddler Web Debugger and according to what it captures the SAMLResponse appears to be valid.

I upped the log level to debug and tried to connect again. I've attached some entries from the logs.

Are there any examples or tools from F5 that I could use to validate the SAML response? I have used https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php and its able to be decoded and encoded fine.

Cheers

apd[6215]: 01490006:6: 37be1ed8: Following rule 'fallback' from item 'Start' to item 'SAML Auth'

apd[6215]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 303 Msg: variable "session.server.landinguri" was not found in the local cache for session "37be1ed8"

apd[6215]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 310 Msg: try to get it from MEMCACHED

apd[6215]: 01490000:7: memcache.c func: "mc_convert_session_var_to_mc_key()" line: 1160 Msg: Converted Var: session.server.landinguri to Session Var tmm.session.37be1ed8.session.server.landinguri

apd[6215]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 342 Msg: variable found, lets add it to the local cache "session.server.landinguri"="/saml/sp/profile/post/acs"(length=25)

apd[6215]: 01490000:7: modules/Authentication/Saml/SamlSPAgent.cpp func: "executeInstance()" line: 650 Msg: Matched idp connector name: /Common/DSS_ADFS_IdP

apd[6215]: 01490000:7: modules/Authentication/Saml/SamlSPAgent.cpp func: "executeInstance()" line: 654 Msg: Doing SAML IdP Initiated Auth: /saml/sp/profile/post/acs

apd[6215]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 303 Msg: variable "session.server.initial_req_body" was not found in the local cache for session "37be1ed8"

apd[6215]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 310 Msg: try to get it from MEMCACHED

apd[6215]: 01490000:7: memcache.c func: "mc_convert_session_var_to_mc_key()" line: 1160 Msg: Converted Var: session.server.initial_req_body to Session Var tmm.session.37be1ed8.session.server.initial_req_body

apd[6215]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 342 Msg: variable found, lets add it to the local cache "session.server.initial_req_body"=""(length=0)

apd[6215]: 01490192:3: 37be1ed8: SAML Agent: /Common/DSSAC_Access_Profile_act_saml_auth_ag cannot find assertion information in SAML request

apd[6215]: 01490004:6: 37be1ed8: Executed agent '/Common/DSSAC_Access_Profile_act_saml_auth_ag', return value 0

apd[6215]: 01490000:7: ./AccessPolicyProcessor/SessionState.h func: "clearTempSessionAgentState()" line: 84 Msg: Agent did not initiated the scheduled agent

apd[6215]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 290 Msg: Let's evaluate rules, total number of rules for this action=2

apd[6215]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 296 Msg: Rule to evaluate = "expr {[mcget {session.saml.last.result}] == 1}"

apd[6215]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 296 Msg: Rule to evaluate = ""

apd[6215]: 01490005:5: 37be1ed8: Following rule 'fallback' from item 'SAML Auth' to ending 'Deny'

Hm..this is really strange. What version of BIG-IP are you using here? Are you doing SP-initiated login(going to the F5 Virtual Server first, or are you doing IDP-initiated from the ADFS? If you are doing IDP initiated, can you try SP-initiated? If you are trying SP-initiated and it is not working, probably worth opening a case with support to have them take a look at the overall configuration - something must be misconfigured somewhere...

Can you post you SP config?

I have made some progress in the last day or two. I'm now able to see the SAML token being validated and the content pulled out and stored in session variables. We stripped the details being sent through to the bare minimum and it now validates.

However something else appears to be going wrong with the access profile. I'm currently getting the F5 logout pages with a "Invalid Session ID. Your session may have expired." error.

I added an iRule and put in a few outputs at various events. After the policy has completed and the next request starts, the access_session_started event is triggered and a new sessionID is created.

Mar 3 13:02:34 F5-int info tmm[8568]: Rule /Common/DSS_SAML_assertion : HTTP_REQUEST - sid:

Mar 3 13:02:34 F5-int info tmm[8568]: Rule /Common/DSS_SAML_ASSERTION : user -

Mar 3 13:02:34 F5-int info tmm[8568]: Rule /Common/DSS_SAML_ASSERTION : ACCESS_SESSION_STARTED - sid:c7016934

Mar 3 13:02:34 F5-int info tmm1[8568]: Rule /Common/DSS_SAML_ASSERTION : HTTP_REQUEST - sid:c7016934

Mar 3 13:02:34 F5-int info tmm1[8568]: Rule /Common/DSS_SAML_ASSERTION : user -

Mar 3 13:02:49 F5-int info tmm[8568]: Rule /Common/DSS_SAML_ASSERTION : ACCESS_POLICY_COMPLETED - sid:c7016934

Mar 3 13:02:49 F5-int info tmm[8568]: Rule /Common/DSS_SAML_ASSERTION : user - MG0028@production.local

Mar 3 13:02:49 F5-int info tmm[8568]: Rule /Common/DSS_SAML_ASSERTION : result - allow

Mar 3 13:02:49 F5-int info tmm1[8568]: Rule /Common/DSS_SAML_ASSERTION : HTTP_REQUEST - sid:c7016934

Mar 3 13:02:49 F5-int info tmm1[8568]: Rule /Common/DSS_SAML_ASSERTION : user - MG0028@production.local

Mar 3 13:02:49 F5-int info tmm1[8568]: Rule /Common/DSS_SAML_ASSERTION : ACCESS_SESSION_STARTED - sid:293dacc4

Why would the APM need to trigger the access_session_started event when it already has a sessionID?

Could there be something in my virtual server settings causing it? I set up an LDAP auth just to test and once it authenticates it maintains the same session and I am able to access the application.

Thanks

I upgraded our virtual F5 to v11.5 this afternoon and straight after the reboot the access policy started working as expected.

The saml token is being validated, pulled apart and stored in session variables, and now the access_acl_allowed event is triggering and the request is allowed to continue through to the server!

Might be an issue in v11.3???

Thanks everyone for your help and suggestions.