SOLVED: 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}Sharing User Credentials Between SAML IDP and SP Policies in F5 APM
In F5 APM environments with one SAML Identity Provider (IDP) and multiple Service Providers (SPs), SP policies may need access to user credentials (like passwords) for SSO mechanisms such as NTLM or RDP. Since SAML doesn't transmit passwords, this solution enables secure credential sharing by storing the password in a custom session variable on the IDP side and passing the IDP session ID to the SP as a SAML attribute. An iRule on the SP side then uses this session ID to retrieve the password from the IDP session, making it available for SSO credential mapping. This approach maintains security by avoiding password exposure in the SAML assertion and leverages internal session sharing between policies.APM Cookbook: SAML IdP Chaining
As an APM subject mater expert at F5 I often find myself in situations where a customer or colleague needs an example of a particular configuration. While most of these requests are easily handled with a call or WebEx I'm a firm believer in sharing knowledge through documentation.. and I don't like getting calls at 3 AM. If you're like me you grew up with the O'Reilly Cookbook series which served as a great reference document for various development or server configuration tasks. My goal is to create a similar reference resource here on DevCentral for those one-off scenarios where a visual example may help your complete your task. For the first APM Cookbook series I'll discuss SAML IdP chaining. Overview Security Assertion Markup Language, more commonly known as SAML, is a popular federated authentication method that provides web based single sign-on. One of the key security advantages to SAML is the reduction in username/password combinations that a user has remember... or in my experience as a security engineer the number of passwords written on a post-it note stuck to their monitor. There are two major services in a SAML environment: IdP - Identity Provider SP - Service Provider The identity provider is the SAML service that authenticates the user and passes an assertion to then service providers proving the user's identity. F5's APM performs both IdP and SP services and allows customers to easily deploy federated authentication in their environment. In more complex scenarios you may run across a requirement where multiple SAML IdPs need to be chained together. This comes up from time to time when customers have contractors that utilize federated authentication for authorization to corporate resources. Example For our configuration we have the Globex Corporation that uses APM to authenticate uses to Office 365. Globex hire contractors from Acme Corp. who authenticate using the Acme Corp. ADFS environment. However, since Office 365 is configured to authenticate against the Globex APM we need to convert the Acme Corp. SAML assertion into a Globex SAML assertion, which is known as IdP chaining. The step ladder for this process is shown below: 1. User requests https://outlook.com/globex.com 2 - 3. Office 365 redirects user to idp.globex.com 3 - 4. idp.globex.com determines user is a contractor and redirect user to sts.acme.com 5 - 8. User authenticates using Acme credentials and is then redirect back to idp.globex.com 9. idp.globex.com consumes the Acme SAML assertion and creates a Globex SAML assertion 10. User is redirected back to Office 365 11 - 12. Office 365 consumes the Globex SAML assertion and displays the user's mail Configuration To configure your APM SAML IdP to accept incoming assertion from sts.acme.com we need to create an external SP connector. Under the Access Policy -> SAML -> BIG-IP as SP configuration section: 1. Create a new SAML SP Service 2. Export the SP metadata and configure sts.acme.com accordingly (follow your IdP vendor's documentation) 3. Click the External IdP Connectors menu at the top 4. Click the dropdown arrow on the create button and choose From Metadata (import the metadata from sts.acme.com) 5. Bind the Local SP service to the external IdP connector Now that idp.globex.com and sts.acme.com are configured to trust one another we need to configure the APM IdP to consume the sts.acme.com SAML assertion. The IdP's Visual Policy Editor should look similar to the image below: 1. The Decision Box asks the user what company they're with. This is a simple example but more elaborate home realm discovery techniques can be used. 2. The SAML Auth box is configured to consume the sts.acme.com assertion 3. Since we no longer have a login form on the IdP we need to set a few APM session variables: session.logon.last.username = Session Variable session.saml.last.identity session.logon.last.logonname = Session Variable session.saml.last.identity 4. Create an Advanced Resource Assign that matches your existing IdP Advance Resource Assign. Conclusion This particular post was a little longwinded due to the steps required but overall is a fairly simple configuration. So the next time someone asks if your F5 can do IdP chaining you can confidently reply "Yes and I know how to do that".
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 AlexSaaS Federation iApp
Problem this snippet solves: f5.saas_idp.v.1.0.1rc1 The official release candidate iApp template has been posted to downloads.f5.com in the RELEASE_CANDIDATE directory of the iApp package. This release has the following changes: Added support for BIG-IP v12.1 Modified the 'SP Initiated?' field in the iApp to 'IdP Initiated?' and the values to 'No, SP only' and 'Yes, IdP and SP' to make this section more clear. f5.saas_idp.v.1.0.0rc1 This release candidate version of the iApp template, released on 4/20/16, provides improved functionality and additional options. The deployment guide has also been substantially updated. f5.saas_idp.v.0.9.0 This iApp allows you to configure F5 BIG-IP Access Policy Manager(APM) as SAML Identity Provider(IdP) to 11 commonly used SaaS applications: Office 365 Salesforce.com Workday Amazon Web Services(limited support) Concur Service-Now Jive Wombat Zendesk WebEx Google Apps How to use this snippet: For information on how to download, install, and use the iApp (and various other prerequisites), see the deployment guide for this configuration: http://f5.com/pdf/deployment-guides/saml-idp-saas-dg.pdf Code : https://downloads.f5.com/esd/product.jsp?sw=BIG-IP&pro=iApp_Templates
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>
