saml
218 TopicsSAML - LTM in front of SP
Hi everybody! We’ve got an F5 BIG-IP set up as a SAML IdP and an on-prem application acting as the SAML Service Provider (SP). The SP itself has two backend servers, which we’d like to load balance through the F5. Our goal is for all traffic between users and the SP to go through the F5 — not just the authentication part. In a typical SAML setup with F5 acting just as IdP, once the user is authenticated, the browser goes straight to the SP. That’s fine in theory, but in our case we’d rather keep the F5 in the mix — both as the SAML IdP and as a reverse proxy/load balancer for the SP. 1) Is it enough to just configure the IdP side on the F5 and point the ACS (Assertion Consumer Service) URL to the LTM virtual server? The idea being: the F5 receives the SAML Response and quietly passes it on to one of the backend SPs behind the same VS. 2) What’s the best way to troubleshoot or confirm that the SAML Response actually makes it from the F5 to the backend SP? For example, can I see this in the APM logs, session variables, or should I go full “tcpdump ninja”? Basically: how do I prove the SAML assertion isn’t getting lost somewhere between the F5 and the SP? Many thanks in advance!Solved121Views0likes6Commentstcl logic in SAML Attribute value field possible?
Hi. We're running BigIP as a SAML IDP. Can I somehow issue tcl logic in a SAML attributes? I'm talking about the Access ›› Federation : SAML Identity Provider : Local IdP Services, editing an object, under SAML Attributes. Based on what's in the memberOf attribute, I need to issue as a value either empty string or "SpecificValue". I am familiar with the %{session.variable} construct, but I don't want to clutter the session with more variables if I can avoid it, as that impacts all sessions using our IDP (30 or so federated services on the same VIP and AP). I tried these two approches: %{ set result {} ; if { [mcget {session.ad.last.attr.memberOf}] contains {| CN=SpecificGroup,OU=Resource groups,OU=Groups,DC=Domain,DC=com |}} { set result {SpecificValue} } ; return $result } expr { set result {} ; if { [mcget {session.ad.last.attr.memberOf}] contains {| CN=SpecificGroup,OU=Resource groups,OU=Groups,DC=Domain,DC=com |}} { set result {SpecificValue} } ; return $result } Expected result: An issued claim with the value "" or "SpecificValue" Actual result: An issued claim with the above code as the value As I mentioned, we've set it up using one VIP that is hosting 30 or so services. We're running 16.1.3.1. They are using the same SSO configuration and there's an iRule triggerd at ACCESS_POLICY_AGENT_EVENT, which does some magic to extract issuer and suchlike, and that helps to make decisions later in the Access Policy. It also populates a few session variables under the session.custom namespace for use in the Access Policy. Additional session variables are being populated in the Access Policy, such as resolved manager and their email address. I have looked briefly at the ASSERT::saml functions, but even if it would be possible to manipulate that way, I wish to keep this set up as stream lined as possible and with as few new "special cases" in an iRule. So while I appreciate pointers along that route as well, I would first of all like to know if there is a way to do it natively in the SAML attribute value field. And if there are any options I have not yet explored here?1.1KViews0likes6CommentsSOLVED: sending IsCompliant, IsKnown and IsManaged via SAML (SSO)
Background We have an EntraID (Azure/Microsoft365) SAML based VPN using the APM module and were keen to provide a different device pool to domain devices, rather than personal devices (BYOD). We noted that, in the EntraID logs, it included elements such as whether the device IsCompliant, IsKnown and/or IsManaged: Wrong step first We followed part of the exceptionally good video from Matthieu Dierick (https://www.youtube.com/watch?v=DBA84d4VJU8) in which he explains how to configure InTune to make the IsCompliant assertion and push a certificate onto the device to identify it.. and then the BIG-IP Edge client will send that certificate back to be used via an API call against InTune (even if EntraID isn't used for your APM authentication). To get the API bit to function we needed to follow the guidance in https://my.f5.com/manage/s/article/K00943512 But we aren't that far down the route with InTune and, without pushing that certificate, we got the error "Device ID was not found in session variables" (as explained in https://my.f5.com/manage/s/article/K93969130 ) To get working: Azure steps It seems exporting these variables isn't natively available through the GUI although there were some pointers available from Azure AD - SAML - Intune - ismanaged attribute - Microsoft Q&A In short, Navigate to: https://portal.azure.com/ Microsoft EntraID Under Manage > App registrations (this will default to "owned application") choose "all applications" tab Filter by the name of your SAML configuration Manage > Manifest Take a copy of the manifest incase you want to revert (note that it won't let you save it unless it can parse the input) Find the section "optional claims" and inject the following after any groups you pass back: "optionalClaims": { "accessToken": [], "idToken": [], "saml2Token": [ { "additionalProperties": [ "on_premise_security_identifier" ], "essential": false, "name": "groups", "source": null }, { "additionalProperties": [ ], "essential": true, "name": "is_device_managed", "source": null }, { "additionalProperties": [ ], "essential": true, "name": "is_device_compliant", "source": null }, { "additionalProperties": [ ], "essential": true, "name": "is_device_known", "source": null } ] }, To get working: APM steps In the visual policy editor you can now assign variables to those claims of the form: session.logon.last.isknown = mcget {session.saml.last.attr.name.http://schemas.microsoft.com/201 4/02/devicecontext/claims/isknown} session.logon.last.iscompliant = mcget {session.saml.last.attr.name.http://schemas.microsoft.com/201 4/09/devicecontext/claims/iscompliant} session.logon.last.ismanaged = mcget {session.saml.last.attr.name.http://schemas.microsoft.com/201 2/01/devicecontext/claims/ismanaged} So you can end up with a variable assignment box that looks like: (just be careful with copy/paste that it doesn't introduce spaces in the session variables) Then you can do a new general purpose > empty box with a branch rule evaluating: expr {[mcget {session.logon.last.ismanaged}] == "true"} Optionally you can record the output of these variables by adding a logging box with the entry: username=%{session.logon.last.username}, ismanaged=%{session.logon.last.ismanaged}, iscompliant=%{session.logon.last.iscompliant}, isknown=%{session.logon.last.isknown}163Views2likes6CommentsSAML 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.1.6KViews0likes3CommentsOffice 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 Alex416Views0likes2CommentsAPM as SAML SP
Hello, I have the BIG-IP virtual environment and I am trying to set up APM as a SAML SP. I've followed this KB to set it up successfully. However, I'm having a lot of trouble with the virtual server side of things. My understanding is that the virtual server is hit from a request from an IdP, and then the virtual server kicks the access policy into gear, then authenticating the user against the BIG-IP system. My issue is, my virtual server is not accessible, so when I try to complete the SAML authentication, I see that the connection has timed out. I have done the following: Configured an access policy for SAML SP Configured a virtual server with an IP address on a different VLAN than the one that BIG-IP resides on Configured an external IdP Configured a SAML SP service Configured a VLAN I'm not fully sure if the VLAN setup is correct, I had spoke with someone at F5, and they vaguely explained that I needed to have a VLAN set up inside my system, and that would allow for me to dedicate an IP to the virtual server. I've ssh'd into the box, and I can ping the IP of the virtual server successfully. It appears that I have all of the necessary components to complete this task, however, I have been fighting for a few days trying to figure out what the issue is. I think it's important to note that my virtual server usually is displaying a status of unknown . However, I've created a pool, and once I did that, I see that server status is now available . Currently I can see traffic to the virtual server, but still not able to access it from anywhere. The link I'm trying to hit is something of the nature Any help would be greatly appreciated.Solved1.1KViews0likes4CommentsF5 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.327Views0likes1CommentSAML 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.517Views0likes5CommentsF5 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>810Views0likes1CommentSAML: 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 Alex470Views0likes6Comments