SAML F5 as SP initiated with Azure MFA Integration
Hi Experts, I am deploying F5 as SP with Azure MFA, during the deployment we encountered this behavior below(which is expected): User access F5 VPN, F5 authenticates users thru local AD Users will redirect to Azure MFA for a second verification Users will key in their Azure account and Azure will send SMS OTP Once verified, users can access applications behind F5 APM The issue we encountered is when the user login for the 2nd time, there was no challenge/authentication presented to the users, we guess it's because of the SSO or cookie session on the Azure. User access F5 VPN, F5 authenticates users thru local AD Users will redirect to Azure MFA (no verification/authentication) Users can access F5 APM After we noticed the behavior above, we used the force authentication option in the F5 SAML configuration (which seems to be the answer): However, we want to minimize the user effort because every time they are redirected to Azure MFA they need to key in their Azure credentials (username & pass). My question is, is there a way to pass the credentials from the F5 logon page to the Azure MFA login portal thru SAML.
Office 365 with APM as IdP (no ADFS), troubleshooting
hello, I have starting a non-hybrid deployment of Office365 with DirSync (sync is working). My domain is a subdomain in a forest. I followed the F5 deployment guide (manual config, no iApp) and have the office365 portal redirection to my IdP (APM 11.6 HF5) and the IdP redirection with assertion (which seems correct) to the Office 365 portal. But signon doesn't work and I get an error 80043431. Questions: cannot find Microsoft troubleshooting guides that do consider a deployment without ADFS. I would like to verify the SSO configuration of Office365 but the PS command Get-MsolFederationProperty -DomainName seem to work only with ADFS... get an error Get-MsolFederationProperty : Failed to connect to Active Directory Federation Services 2.0 on the local machine. Please try running Set-MsolADFSContext before running this command again. Does anyone knows a way to get the SSO configuration in a deployment without ADFS? has anyone gone through the same error and found the solution? Thanks Alex
F5 SAML SP for a portion of a website
Let's say I have the following setup: a website called test.example.com an access policy called test_apol with SAML Auth If I assign the test_apol access policy to test.example.com VIP, the entire test.example.com becomes Service Provider (SP) and is protected by SAML Auth. Can I, and if yes then how, place only a portion of the website, i.e. a selected list of HTTP Paths/URIs behind SAML Auth, instead of the entire website? I.e. if test.example.com/private then SAML Auth, otherwise no restrictions. Just from top of my head, I was thinking about placing an iRule Event in front of SAML Auth; and inside iRule do the filtering of which HTTP Paths/URIs I want to send to SAML for authentication, and which ones just straight to the back-end servers without any authentication: However, I don't know whether this is the best approach to address my problem, or there is a better more elegant solution. Any ideas, suggestions, recommendations to address this are much appreciated.
SAML SLO response data destination modification needed
I have the following requirement to modify the SAML response data in particular the SLO destination. The goal here is to finalize the end user session on both the SP mywebsite, IDP1 and IDP2 (this is a chained setup). With this config the session is being terminated on the IDP1 and IDP2 but still not on the SP, this is because the IDP1 sends the SAML SLO response to IDP1 with the SLO destination being IDP1/logmeout, when resending the POST request via redirect to end user and direct it back to mywebsite it reponds with 400 BAD requests, this is because of the SAML SLO data contains the old IDP/logmeout destination and need to be modified. The Irule I use, which is working when ACCESS_ACL_ALLOWED { if { [HTTP::uri] contains "/logmeout" } { log local0. "logout requested from IP [IP::client_addr] URI [HTTP::uri] query [HTTP::query]" ACCESS::session remove ACCESS::respond 307 Location "HTTPS://myredirectwebsite[HTTP::query]" } How can I be able to modify the SAML SLO payload to match the SLO destination of SP mywebsite without having to change the SP metadata of IDP1? I know in version 14.1 is the new feature ACCESS_SAML_SLO_RESP which would be highly suitable for this, but we use version 13. https://devcentral.f5.com/wiki/iRules.ACCESS_SAML_SLO_RESP.ashx The SAML POST DATA is: https://IDP2/logmeout (this part needs to be modified to the mywebsite destination) All recommendations are welcome.
F5 APM SAML from SecureAuth
We are stuck on the VPE SAML Auth action based on the APM log message. The SAML XML Deflated Content shows "Success" in the output. Current setup: Client > SecureAuth presented MFA page: Client (IDP) - F5 APM (SP) > Citrix Storefront The Requests never seem to be making it past SAML Auth action: Oct 11 13:31:12 lb-ext1 err apmd[14020]: 0149020b:3: /Common/ACCESSTEST:Common:0ef40f05: SAML Agent: /Common/ACCESSTEST_act_saml_auth_ag, SAML AAA Server /Common/ACCESSTEST, unable to redirect user to an IdP. Error: could not find an IdP connector for saml aaa server that matches IdP selection criteria ******************** Oct 11 13:39:53 lb-ext1 err apmd[14020]: 0149020f:3: /Common/ACCESSTEST:Common:c9f13457: SAML Agent: /Common/ACCESSTEST_act_saml_auth_ag cannot find assertion information in SAML request ********************** Oct 11 13:40:31 lb-ext1 err apmd[14020]: 0149020a:3: /Common/ACCESSTEST:Common:5147979f: SAML Agent: /Common/ACCESSTEST_act_saml_auth_ag SAML assertion is invalid, error: Id of InResponseTo should match id of authentication request ******************* Oct 11 13:21:54 lb-ext1 notice apmd[14020]: 01490005:5: /Common/ACCESSTEST:Common:6cf6baf2: Following rule 'fallback' from item 'SAML Auth' to ending 'Deny' ********************** ******************** Configuration: ****************************************** apm aaa saml /Common/ACCESSTEST { entity-id https://accesstest.company.com idp-connectors { /Common/ACCESSTEST { idp-matching-source "%{session.server.landinguri}" idp-matching-value / } } sp-decryption-cert /Common/SecureAuth_Citrix_Test_2019_cert.crt sp-decryption-key /Common/SecureAuth_Citrix_Test_2019_cert.key sp-host accesstest.company.com } apm aaa saml-idp-connector /Common/ACCESSTEST { entity-id https://logon.company.com/CitrixTest/ idp-certificate /Common/SecureAuth_Citrix_Test_2019_cert.crt sso-binding http-redirect sso-uri https://logon.company.com/CitrixTest/TestProdAppsWeb/ } ************************************* apm policy policy-item /Common/ACCESSTEST_act_saml_auth { agents { /Common/ACCESSTEST_act_saml_auth_ag { type aaa-saml } } caption "SAML Auth" color 1 item-type action rules { { caption Successful expression "expr {[mcget {session.saml.last.result}] == 1}" next-item /Common/ACCESSTEST_act_variable_assign } { caption fallback next-item /Common/ACCESSTEST_end_deny } } } SAML XML Deflated Content Deflated SAML XML content: <samlp:Response ID="_e9cb37db-103b-4921-afaf-393276a79450" InResponseTo="_d3de7fa9516f067ee78a84205eacf91acc2a1f" Version="2.0" IssueInstant="2019-10-11T18:40:58.758Z" Destination="https://accesstest.company.com/saml/sp/profile/post/acs" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://logon.company.com/CitrixTest/</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status><saml:Assertion Version="2.0" ID="_82dc8a40-9951-478e-a16b-6b73da3d2d2e" IssueInstant="2019-10-11T18:40:58.758Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><saml:Issuer>https://logon.company.com/CitrixTest/</saml:Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><Reference URI="#_82dc8a40-9951-478e-a16b-6b73da3d2d2e"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><InclusiveNamespaces PrefixList="#default saml ds xs xsi" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><DigestValue>Zw0basdNmLtETu9w6v9vqseADmipeHDppg8NhboScFY=</DigestValue></Reference></SignedInfo><SignatureValue>Wp5bF2SKj/Npanasb/Xv7uovuR5+NN25HdNps+/cIySmV0pi6rgahHROHJZvtTM1XSWyNcSed0uWKrAbRQQBzMHcupciVyBwF6KB7gQrh+dg3mSrzMe6C4TCebXwujTKg1XyURfLmS2+lXBwHcq2nCQGGRvGXbeuKVcdQ0vK3SXQbACxwb3ppg1lMrEshRyplzwz6sHcn4sGFi7/Q7zy17hFFOB4CwoYVrCrQhKet4LfFz6vQsAbs1arD7gLgsapNQVbRsi8jULHlvQV8zJrN2PBh4cKqNHOOD8lOlD8lCwi2AX58XB1pOz2ZniuXMun5jzyRWTTORNpYpqWtOjZ5Q==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIGZzCCBU+gAwIBAgITXgAL7JV9V1pMYiNyMQAAAAvslTANBgkqhkiG9w0BAQsFADCB9TELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExDzANBgNVBAcTBklydmluZTEfMB0GA1UEChMWU2VjdXJlQXV0aCBDb3Jwb3JhdGlvbjFCMEAGA1UECxM5KGMpIDIwMTUgU2VjdXJlQXV0aCBDb3Jwb3JhdGlvbiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczE8MDoGA1UEAxMzU2VjdXJlQXV0aCBHMyBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDFBMB4XDTE5MDYyMDE3NTE1NFoXDTI1MDUxNjIwMTQwNlowgZAxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaXNzb3VyaTEUMBIGA1UEBxMLS2Fuc2FzIENpdHkxHTAbBgNVBAoTFEthbnNhcyBDaXR5IFNvdXRoZXJuMQswCQYDVQQLEwJTRTEsMCoGA1UEAxMjU2VjdXJlYXV0aDAxLmthbnNhc2NpdHlzb3V0aGVybi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCfefnj/mR4j2a3722hemJs6mq57IAdSgdoygpqxRQMgaeb22z7UuFdv2VZ1fv/ZTfrbLY/Qul4EqyMWoPQ3XuowZcVPCMg75XVpKcRdeRGPo0+lvVo0K+oTYGSOi2YbGAr7rR/kRNUK28yx9JAhBL4Zv4hJV1zScahIkuDETAa7UsmmcZt4QRnG8jdEZUuE3WcJbiWKtFOnJb59CbSt+0DGKXTtoczlwDFY9Pw5b73gVVAMr9Z3j/luFlWqzNuc6kTQkH+7/7GONfOtcY8AOzsL/o/0o3ahyTIGFuvyNzppueEPo64epQ5K7ij3KtnU/gl34gSEQ0j/E2YktqDBQxtAgMBAAGjggJRMIICTTAOBgNVHQ8BAf8EBAMCBPAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBRDMzJlMkc/LWq/IBJ/wSn8f+S4wzA5BgNVHREEMjAwgglsb2NhbGhvc3SCI1NlY3VyZWF1dGgwMS5rYW5zYXNjaXR5c291dGhlcm4uY29tMB8GA1UdIwQYMBaAFAY88yj3QiBrOerad6rYkmgxhzcsMIHnBgNVHR8Egd8wgdwwgdmggdaggdOGZmh0dHA6Ly9jbG91ZC5zZWN1cmVhdXRoLmNvbS9DZXJ0SW5mby9TZWN1cmVBdXRoJTIwRzMlMjBJbnRlcm1lZGlhdGUlMjBDZXJ0aWZpY2F0ZSUyMEF1dGhvcml0eSUyMDFBLmNybIZpaHR0cDovL3VzLWNsb3VkLnNlY3VyZWF1dGguY29tL0NlcnRJbmZvL1NlY3VyZUF1dGglMjBHMyUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTIwMUEuY3JsMIGzBggrBgEFBQcBAQSBpjCBozCBoAYIKwYBBQUHMAKGgZNodHRwOi8vY2xvdWQuc2VjdXJlYXV0aC5jb20vQ2VydEluZm8vTXVsdGlmYWN0ci1WTTIyLmJhbm5lci5tdWx0aWZhY3RvcnRydXN0My5jb21fU2VjdXJlQXV0aCUyMEczJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMjAxQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAMll4CeLg3lEqf9XWr5NnSMDVyizCXRsKm02m3sEKlvmb8j3baWHJLn7N4wXmBHpDLbtVySa+UbbGm8+/Dtu3P0SJj4GI3NxYKsYJigiBm5E3wzsC2jX8Tm4ni7H7u9ixWXyl2aA6lPLWhVBOzQWTVWElPe5fly0/3QA3RxI+WaUUkhq6+oigF5RagPOd4BEtoj3+7i0BrPARSUyqJj9YSn1q6fd4Tq/vZU4NKeQvCRCcWVabO3ZtcoMwYg7SvawhzJ6RfX+LVLeyBpRt+YgQyRj8PvNgpCdL4M9opIVDcvX18IoaSs1YH72xxXpEi02Ig2TLazEglwTz8lVGweGFa4=</X509Certificate></X509Data></KeyInfo></Signature><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">test2013ex07</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2019-10-11T19:40:58.758Z" Recipient="https://accesstest.company.com/saml/sp/profile/post/acs" InResponseTo="_d3de7fa9516f067ee78a84205eacf91acc2a1f" /></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2019-10-11T18:40:58.758Z" NotOnOrAfter="2019-10-11T19:40:58.758Z"><saml:AudienceRestriction><saml:Audience>https://accesstest.company.com</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2019-10-11T18:40:58.758Z" SessionIndex="_d3de7fa9516f067ee78a84205eacf91acc2a1f"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute Name="Password" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml:AttributeValue>SecureAuth!</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>SAML: apm vpe action selection based on SP Issuer
hello I have the following scenario: APM as IdP (works as portal and SP-initiated), v12.0. Multiple SAML IdP resources are configured and showned to the users depending on their AD group membership. For SP-initiated sessions, I need to perform an AD query in a different way, depending on the SP resource (Issuer). My issue is that the APM doesn't set any variable for the issuer ID when it receives the AuthnRequest (example such as urn:federation:MicrosoftOnline ) Am I overseeing something here? Is there a workaround? Thanks Alex
SAML to Workday - Deep Linking
We would like to provide deep links to business to maintain links at the service provider while going through the SAML authentication process. IdP initiated works just fine (i had to put a redirect location iRule to the webtop link to get this to do an unsolicited SAML assertion post to the Service Provider). Herein lies my challenge, Workday being the service provider does not formulate a standard AuthN request which ofcourse the APM module wont know what to do with. Instead this is what it does: Workday assists in this by appending the requested (deep-link) URL as a GET URL parameter (similarly, named done), to the URL for the IdP, when it redirects for sign on. i.e. the user clicks the deeplink in their email, their browser navigates to Workday, which in turn redirects to the IdP sign on page. That redirect navigates their browser to the IdP sign on page, with a GET parameter named done, appended, set to the value of the ultimate deep link URL. https://customers.identity.provider/sign-on-page.html?done= http://impl.workday.com/TENANT NAME/fx/task/2997$194.flex The customers’ IdP package logic must be developed or configured to observe this done parameter and be sure to pass it back to Workday, as an identically name POST variable, when POSTing the SAMLRequest assertion. So I could capture the query string payload in an iRule but posting it back? The webtop iRule is already somewhat of a hack and not true Identity Provider initiated SSO, how could I manipulate the Webtop link is really what I'm asking I think? The Irule I currently use to redirect to the webtop link is in a switch statement: HTTP::redirect "https://workday.mycompany.com/saml/idp/res?id=/SSO/workday" I need to somehow manipulate how I post back to the assertion consumer service URL, any ideas?
APM Access Guided Configuration with VIP in different partion
I am trying to use the Guided Configuration to create SAML Service Provider. However ths is can only be run from the Common partition whereas the VIP required has to be on a different parition for security reasons. I have tried to configure this manually but running in to problems and all online guides point to the guided configuration. Is there a way around this partition restriction while using the guided configuration? I am trying to deploy Big IP APM to perform SAML authentication through Azure. We have the Metadata file but would like to use the Guided configuration to complete the deploy.
