BIG-IP iRulesLX FakeADFS - WS-Federation/SAML11
Details This was created as a solution to REPLACE the need for AD FS to tie APM into SharePoint. The goal was originally to demonstrate the flexibility of iRulesLX and also to find a way to add WS-Federation support very quickly. This solution is currently SP initiated, but wouldn't take much to handle IdP initiated as well. An example of the process flow is detailed in the following image. All that's needed for this solution is to create or import the iRulesLX workspace, configure SharePoint as if you are connecting to AD FS as a trusted Identity Provider, but point to a virtual server on the BIG-IP. Instructions First, ensure that you have a certificate / key for the IDP, as well as the CA Chain/Root CA. These do not have to be from the same domain CA that SharePoint lives on, if it exists. We are going to add these to SharePoint as trusted. On one of the SharePoint servers, open the SharePoint Management Powershell, issue the following. To import the Trusted Root CA, that issued the signing cert: $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("") New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root To import the Trusted Certificate $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("") Next, create the Claim mappings for SharePoint: $emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress " -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming $upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn " -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming $roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role " -IncomingClaimTypeDisplayName "Role" –SameAsIncoming $sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid " -IncomingClaimTypeDisplayName "SID" –SameAsIncoming Note: Additional claim options here. Next, create the Trusted Identity Provider. $realm = "urn:sharepoint:" $signInURL = "https:///adfs/ls" $ap = New-SPTrustedIdentityTokenIssuer -Name (ProviderName) -Description (ProviderDescription) -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $emailClaimMap,$upnClaimMap,$roleClaimMap,$sidClaimMap -SignInUrl $signInURL -IdentifierClaim $emailClaimmap.InputClaimType To Associate a SharePoint Web Application with the new Identity Provider. To configure an existing web application to use the FakeADFS identity provider Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group. In Central Administration, on the home page, click Application Management. On the Application Management page, in the Web Applications section, click Manage web applications. Click the appropriate web application. From the ribbon, click Authentication Providers. Under Zone, click the name of the zone. For example, Default. On the Edit Authentication page in the Claims Authentication Types section, select Trusted Identity provider, and then click the name of your SAML provider (<ProviderName> from the New-SPTrustedIdentityTokenIssuer command). Click OK. Next, you must enable SSL for this web application. You can do this by adding an alternate access mapping for the “https://” version of the web application’s URL and then configuring the web site in the Internet Information Services (IIS) Manager console for an HTTPS binding. APM Policy Flow The current workflow works as follows: 1. A user opens a link to SharePoint. 2. SharePoint presents Authentication options for the WebApp. 3. A user selects Authentication Source (FakeADFS), enters credentials, which then redirects the user to Virtual Server configured with FakeADFS iRulesLX solution. 4. FakeADFS Generates a SAML11 assertion, then wraps it in the WS-Federation elements. <t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"> <t:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2016-12-20T13:56:01.349Z</wsu:Created> <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2016-12-20T14:56:01.349Z</wsu:Expires> </t:Lifetime> <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>urn:sharepoint:f5test</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <t:RequestedSecurityToken> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="_8Ed1lOeqLhnGTETTOn9BHJn72TZ8lE25" IssueInstant="2016-12-20T13:56:01.363Z" Issuer="http://fakeadfs.f5ttest.com/adfs/services/trust"> <saml:Conditions NotBefore="2016-12-20T13:56:01.363Z" NotOnOrAfter="2016-12-20T14:56:01.363Z"> <saml:AudienceRestrictionCondition> <saml:Audience>urn:sharepoint:f5test</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AttributeStatement> <saml:Subject> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" AttributeName="emailaddress"> <saml:AttributeValue>flip@f5test.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" AttributeName="upn"> <saml:AttributeValue>0867530901@f5test.com</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2016-12-20T14:56:01.363Z"> <saml:Subject> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> <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="#_8Ed1lOeqLhnGTETTOn9BHJn72TZ8lE25"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>fqLP9yVFDNveaOWwyEVl2Bc9M6bEzKb7KMZ2x33VgUc=</DigestValue> </Reference> </SignedInfo> <SignatureValue>tSLsHUu5m1Mc7qNmdfa5daEK2+noAgbuZ5faGaXQw7qCPEvNihXFUjGuwT4qgeIWFsiFcinin 6Q42DwjRZBL1jcYpAYxP3WQFc+JvRlOaaWecklLmlLGBp9qjyzNzNhgT374T1YkgWJLTm4Jky7bW6HAMWJzT2vCpbSWLbtU=</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIGgjCCBGqgAwIBAgITFQAAAAVVlNqAr99awAAAAAAABTANBgkqhkiG9w0BAQsFADBJMRMwEQYKCZImiZ PyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRZjVsYWIxGzAZBgNVBAMTEkY1IExhYiBDQSAoMksxNlIyKTAeFw0xNjEyMTYxN TE1MjNaFw0xODEyMTYxNTE1MjNaMG8xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJQQTEUMBIGA1UEBxMLRG93bmluZ3Rvd24xDzAN BgNVBAoTBkY1IExhYjEPMA0GA1UECxMGRjUgTGFiMRswGQYDVQQDExJmYWtlYWRmcy5mNWxhYi5jb20wgZ8wDQYJKoZIhvcNAQE BBQADgY0AMIGJAoGBALgtr7ROiet3GPUg0yWa2dGPoirQ9dI8XiA7BsUwjTUG5yhAysKm0ZsCstKN92a2e8HxoHxiEZL39XzTxg 5+3fY4A8hWttlqkKoWutnUS3GpPhfoVdufr8bTcr/vhLPCkuy9GsiDqAMwuiX/B3r0EHqFk3utfL3KDxZ5V94ArwqJAgMBAAGjg gK/MIICuzAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0AwwCgYIKwYBBQUHAwEweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgIC AIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgU rDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUL8AJuPouaekEIK8JuQAthnBS8wHwYDVR0jBBgwFoAUeyV8LWPBfaUCaLG/UR cYpOrjK48wgeMGA1UdHwSB2zCB2DCB1aCB0qCBz4aBzGxkYXA6Ly8vQ049RjUlMjBMYWIlMjBDQSUyMCEwMDI4MksxNlIyITAwM jksQ049V0lOMksxMlIyREMwMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZp Z3VyYXRpb24sREM9ZjVsYWrIsREM9Y29tP2NlcnRpZmljYXRl2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN 0cmlidXRpb25Qb2ludDCB0AYIKwYBBQUHAQEEgcMwgcAwgb0GCCsGAQxUFBzAChoGwbGRhcDovLy9DTj1GNSUyMExhYiUyMENBJT IwITAwMjgySzE2UjIhMDAyOSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlnd XJhdGlvbixEQz1mNWxhYixEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjANBgkqhkiG9w0BAQsFAAOCAgEAdom2Hvlw9MTKZbr6Ic3MLDR I10QGnflAq9w0/t6H8HN1jnEW8RTikIEpp2nOK7GknFq2161mJ4l5cRGroCyWsHN8to6VqhxqnESYHRyxwZDpS6a8JO4AYc111G fRWpB4nOIqs86aboUJDU+vRzrJHeuI1NzsI502i7fjlYqQVtE3FO2VIbekqx9zjHnliAX6l+VbDMFX8P8lP40U9rAIzHUPF+j3p 34i+4tPtv1/bwTco2EZE8hy2XvJ4xHXzpXYytchRhv+8glYNKK229vhML0micJfnCJQ3xaiJ2e08/GSVoBF9x4J+z4V+XS9aZSn P2+N3tZESVVBA8U4kk9u6syfmDc4+ryoIw5XGcBIyitaH7FbKbYyUHY0XuWPHx6FOWWnCe2kIA/Zfs9IDCP/z07egIJabLymLC vRhOMyd1s5lajnTFfoFaDd7LlL1ipz94OdhxJ5/Aga7sTEtFPbjnfcSZ8lFglQUOkaKuZt6D/LQ/TW6TyDqPC3RDCoaqkY4MXgnm P0dUk9ql1y2qFU2l692ZDZQPB4Tiaa3yXDKwDwCWITQ0YBvIiCcSWoMKXXea96Q2lB3R9n7v9Y6I7eSniZjGqlYYQ3Bdi3FMVz+ HGPeMOFq6HbzgnNtjFKwjqokUbwpwA7vZOQmFwEahEEaCPTpK25h4LSpLPtYa3fjfQ=</X509Certificate> </X509Data> </KeyInfo> </Signature> </saml:Assertion> </t:RequestedSecurityToken> <t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</t:TokenType> <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType> <t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType> </t:RequestSecurityTokenResponse> 5. The results are injected into a form embedded in an HTTP::respond 200 content with javascript that will automatically POST the form data to SharePoint. SharePoint accepts the assertion from its Trusted Identity Provider. The current solution pulls attributed from LDAP, but this isn't required, you can basically enter anything as username and SharePoint accepts it without question. iRule/TCL Portion when HTTP_REQUEST { # Wctx: This is some session data that the application wants sent back to # it after the user authenticates. set wctx [URI::decode [URI::query [HTTP::uri] wctx]] # Wa=signin1.0: This tells the ADFS server to invoke a login for the user. set wa [URI::decode [URI::query [HTTP::uri] wa]] # Wtrealm: This tells ADFS what application I was trying to get to. # This has to match the identifier of one of the relying party trusts # listed in ADFS. wtrealm is used in the Node.JS side, but we dont need it # here. # Kept getting errors from APM, this fixed it. node 127.0.0.1 # Make sure that the user has authenticated and APM has created a session. if {[HTTP::cookie exists MRHSession]} { #log local0. "Generate POST form and Autopost " # tmpresponse is the WS-Fed Assertion data, unencoded, so straight XML set tmpresponse [ACCESS::session data get session.custom.idam.response] # This was the pain to figure out. The assertion has to be POSTed to # SharePoint, this was the easiest way to solve that issue. Set timeout # to half a second, but can be adjusted as needed. set htmltop "<html><script type='text/javascript'>window.onload=function(){ window.setTimeout(document.wsFedAuth.submit.bind(document.wsFedAuth), 500);};</script><body>" set htmlform "<form name='wsFedAuth' method=POST action='https://sharepoint.f5test.com/_trust/'><input type=hidden name=wa value=$wa><input type=hidden name=wresult value='$tmpresponse'><input type=hidden name=wctx value=$wctx><input type='submit' value='Continue'></form/>" set htmlbottom "</body></html>" set page "$htmltop $htmlform $htmlbottom" HTTP::respond 200 content $page } } when ACCESS_POLICY_AGENT_EVENT { # Create the ILX RPC Handler set fakeadfs_handle [ILX::init fakeadfs_extension] # Payload is just the incoming Querystring set payload [ACCESS::session data get session.server.landinguri] # Currently, the mapped attributes are Email & UPN. In some environments, # this may match, for my use case, they will not, so there is an LDAP AAA # which is queried based on the logon name (email), and the UPN is retrieved # from LDAP. set AttrUserName [ACCESS::session data get session.logon.last.username] set AttrUserPrin [ACCESS::session data get session.ldap.last.attr.userPrincipalName ] # Current solution uses Node.JS SAML module and can support SAML11, as well # as SAML20. The APM policy calls the irule even ADFS, with generates the token # based on the submitted QueryString and the logon attributed. switch [ACCESS::policy agent_id] { "ADFS" { log local0. "Received Process request for FakeADFS, $payload" set fakeadfs_response [ILX::call $fakeadfs_handle Generate-WSFedToken $payload $AttrUserName $AttrUserPrin] ACCESS::session data set session.custom.idam.response $fakeadfs_response } } } # This may or may not be needed, they arent populated with actual values, but # have not tested WITHOUT yet. # # MSISAuth and MSISAuth1 are the encrypted cookies used to validate the SAML # assertion produced for the client. These are what we call the "authentication # cookies", and you will see these cookies ONLY when AD FS 2.0 is the IDP. # Without these, the client will not experience SSO when AD FS 2.0 is the IDP. # # MSISAuthenticated contains a base64-encoded timestamp value for when the client # was authenticated. You will see this cookie set whether AD FS 2.0 is the IDP # or not. # # MSISSignout is used to keep track of the IDP and all RPs visited for the SSO # session. This cookie is utilized when a WS-Federation sign-out is invoked. # You can see the contents of this cookie using a base64 decoder. # MSISLoopDetectionCookie is used by the AD FS 2.0 infinite loop detection # mechanism to stop clients who have ended up in an infinite redirection loop # to the Federation Server. For example, if an RP is having an issue where it # cannot consume the SAML assertion from AD FS, the RP may continuously redirect # the client to the AD FS 2.0 server. When the redirect loop hits a certain # threshold, AD FS 2.0 uses this cookie to detect that threshold being met, # and will throw an exception which lands the user on the AD FS 2.0 error page # rather than leaving them in the loop. The cookie data is a timestamp that is # base64 encoded. when ACCESS_ACL_ALLOWED { HTTP::cookie insert name "MSISAuth" value "ABCD" path "/adfs" HTTP::cookie insert name "MSISSignOut" value "ABCD" path "/adfs" HTTP::cookie insert name "MSISAuthenticated" value "ABCD" path "/adfs" HTTP::cookie insert name "MSISLoopDetectionCookie" value "ABCD" path "/adfs" } iRulesLX / Node.JS Portion If you you are starting from scratch, the npm install xxx --save option below is required. If you are importing the workspace or the github solution, npm update will pull in the latest version of all the referenced modules. /* Import the f5-nodejs module. */ var f5 = require('f5-nodejs'); /* Import the additional Node.JS Modules npm install saml npm install querystring npm install fs npm install moment npm install https */ var saml11 = require('saml').Saml11; var queryString = require('querystring'); var fs = require('fs'); var moment = require('moment'); var https = require('https'); /* timeout is the length of time for the assertion validity wsfedIssuer is, believe it or not, the Issuer SigningCert, SigningKey are the required certificate and key pair for signing the assertion and specifically the DigestValue. */ var timeout = 3600; var wsfedIssuer = "http://fakeadfs.f5test.com/adfs/services/trust"; var SigningCert = "/fakeadfs.f5test.com.crt"; var SigningKey = "/fakeadfs.f5test.com.key"; /* Create a new rpc server for listening to TCL iRule calls. */ var ilx = new f5.ILXServer(); ilx.addMethod('Generate-WSFedToken', function(req,res) { /* Extract the ILX parameters to add to the Assertion data req.params()[0] is the first passed argument req.params()[1] is the second passed argument, and so on. */ var query = queryString.unescape(req.params()[0]); var queryOptions = queryString.parse(query); var AttrUserName = req.params()[1]; var AttrUserPrincipal = req.params()[2]; var wa = queryOptions.wa; var wtrealm = queryOptions.wtrealm; var wctx = queryOptions.wctx; /* This is where the WS-Fed gibberish is assembled. Moment is required to insert the properly formatted time stamps.*/ var now = moment.utc(); var wsfed_wrapper_head = "<t:RequestSecurityTokenResponse xmlns:t=\"http://schemas.xmlsoap.org/ws/2005/02/trust\">"; wsfed_wrapper_head += "<t:Lifetime><wsu:Created xmlns:wsu=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\">" + now.format('YYYY-MM-DDTHH:mm:ss.SSS[Z]') +"</wsu:Created>"; wsfed_wrapper_head += "<wsu:Expires xmlns:wsu=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\">" + now.add(timeout, 'seconds').format('YYYY-MM-DDTHH:mm:ss.SSS[Z]') + "</wsu:Expires>"; wsfed_wrapper_head += "</t:Lifetime><wsp:AppliesTo xmlns:wsp=\"http://schemas.xmlsoap.org/ws/2004/09/policy\"><wsa:EndpointReference xmlns:wsa=\"http://www.w3.org/2005/08/addressing\">"; wsfed_wrapper_head += "<wsa:Address>" + wtrealm + "</wsa:Address>"; wsfed_wrapper_head += "</wsa:EndpointReference></wsp:AppliesTo><t:RequestedSecurityToken>"; /* Generate and insert the SAML11 Assertion. These attributed are configured previously in the code. cert: this is the cert used for encryption key: this is the key used for the cert issuer: the assertion issuer lifetimeInSeconds: timeout audiences: this is the application ID for sharepoint, urn:sharepoint:webapp attributes: these should map to the mappings created for the IDP in SharePoint */ var saml11_options = { cert: fs.readFileSync(__dirname + SigningCert), key: fs.readFileSync(__dirname + SigningKey), issuer: wsfedIssuer, lifetimeInSeconds: timeout, audiences: wtrealm, attributes: { 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress': AttrUserName , 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn': AttrUserPrincipal } }; /* Sign the Assertion */ var signedAssertion = saml11.create(saml11_options); /* Add the WS-Fed footer */ var wsfed_wrapper_foot = "</t:RequestedSecurityToken><t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</t:TokenType><t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType><t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType></t:RequestSecurityTokenResponse>"; /* Put them all together */ var wresult = wsfed_wrapper_head + signedAssertion + wsfed_wrapper_foot; /* respond back to TCL with the complete assertion */ res.reply(wresult); }); /* Start listening for ILX::call and ILX::notify events. */ ilx.listen(); And thats it. You can now get away with WS-Fed and SAML1.1 assertions with a quick import to your BIG-IP.
Enhanced security with F5 BIG-IP APM and Okta through Multi-Factor Authentication
This article is the third in the three-part series. Go to Part 1 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2) Go to Part 2 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2) Multi-factor Authentication (MFA) is a security best practice that enhances authentication by requesting two or more verifiable authentication factors. Common authentication factors are: Something You Know, Something You Have, and Something You Are. In addition to configuring native MFA support, the F5 BIG-IP Access Policy Manager (APM) system offers the flexibility to combine multiple authentication mechanisms from partners like Okta. In this DevCentral blog, we will look at how to configure APM for Okta MFA to authenticate using Something You Know and Something You Have. The HTTP connector for Okta MFA is supported in F5 BIG-IP APM system running TMOS v16.0 or later. Setting up Okta MFA Follow the steps below to configure ‘Okta Verify’ for mobile MFA. Navigate to Okta web UI >> Security >> Multifactor and activate Okta Verify. Figure 1: Activate Okta Verify MFA Click on the Factor Enrollment option in the sub menu, then click on the Edit button. On the popup screen, choose Everyone option under Assign to groups. When done, press the Update Policy button. Figure 2: Assign the MFA policy to the user group Configuring F5 BIG-IP APM for Okta MFA Follow the steps below to configure the HTTP connector for Okta MFA. Create a DNS Resolver to Resolve the DNS Queries and Cache the Results On the main menu, navigate to Network >> DNS Resolvers. On the DNS Resolvers web page, click on the Create button. Enter a name and click the Finished button. On the DNS Resolvers web page, click on the above created DNS resolver list name. Navigate to the Forward Zones tab in the sub menu to add any recursive nameservers. When done, press the Finished button. Figure 3: Create the DNS resolver Creating an HTTP Connector and Assign the DNS Resolver Navigate to Access >> Authentication >> HTTP Connector and click on HTTP Connector Transport. On the HTTP Connector Transport web page, click on the Create button. Enter a name and select the above created DNS Resolver and the SSL Server Profile. When done, press the Save button. Figure 4: Sample HTTP connector configuration Creating the Okta Connector and Assigning the HTTP Connector Navigate to Access >> Authentication and click on Okta Connector. On the Okta Connector web page click on the Create button. Enter a name and select the above created HTTP connector. Type the Okta Domain name and paste the Okta API Token from Okta. When done, press the Save button. Figure 5: Sample Okta connector configuration Note: To create a new Okta API token, navigate to Okta web UI >> Security >> API and click on Tokens. Creating and assigning the Access profile and Access Policy to the Application Follow the steps below to create an access profile and per-request access policy for Okta MFA and assign them to the application. Creating the Access Profile and Access Policy Navigate to Access >> Profiles/Policies and click on Access profiles (Per Session Policies). click on the Create button to create a new access profile. Enter a name and select All in the Profile Type drop down-list. Scroll down to the Language Settings section. Select the preferred language and move it to the left into Accepted Languages box. When done, press the Finished button. Figure 6: Sample access profile configuration Next, navigate to Access >> Profiles/Policies and click on Per-Request Policies. Click on Create button to create a new access policy. Enter a name and select All in the Profile Type drop down list. Scroll down to the Language Settings section. Select the preferred language and move it to the left into Accepted Languages box. When done, click on Finished button. On the Per-Request Policies page, click the Edit button next to the above created policy. Create the per-request policy using the Visual Policy Editor as show in the figure 7. Figure 7: Sample per-request policy To add the Okta MFA, click on the + sign. On the popup screen, click on the Authentication tab and select Okta MFA. When done, click on the Add Item button. On the popup screen, enter a name and choose the above configured Okta connector. When done, click the Save button. Figure 8: Sample Okta MFA configuration with ‘Okta Connector’ assigned Assigning the Access Profile and Access Policy to the Virtual Server Navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the Virtual server configured for the application. Scroll down to the Access Policy section and select the Access Profile and the Per-request Policy. When done, press the Update button. Figure 9: Assign the access profile and per-request policy to the virtual server Validating and Verifying the Solution Follow the steps below to setup and validate mobile MFA using ‘Okta Verify’. Download the ‘Okta Verify’ app on your mobile device. Login to Okta Web UI using your username and password. On the dashboard, click on the user setting. Under the extra verification section, click on the Setup button. On the resulting web page, click on Configure Factor and choose the Device Type (Android or Apple). Scan the presented barcode with the Okta mobile app for verification, this completes the setup. Access the application app.f5sec.net from a browser. When prompted enter the username and password. After successful authentication, you will be prompted for MFA, click on the Send Push button. Complete the MFA using the Okta Verify app on your mobile device. Figure 10: User prompted for MFA after successful authentication Conclusion The joint F5 and Okta MFA integration offers a compelling solution for customers who are interested in securely accessing enterprise applications on-premises and in any cloud by increasing the assurance of authentication. Additional Resources Part 1 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 Part 2 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 BIG-IP APM Product Information: Knowledge Center Free Training Course: Getting Started with BIG-IP Access Policy Manager (APM) Lightboard Lesson: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication External Resource: F5 | Okta partnershipAPM 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".
Evaluating common integrations between Azure AD and APM - Part 1
Identity as a Service providers (IDaaS) are exploding in adoption rate, Azure AD being one that I encounter most frequently. Given that, I am often asked what options are available for integration between Azure AD and BIG-IP APM, including implementation steps. In this 4-part series, I will first summarize and contrast the integration options, including the pros and cons of each, then in each subsequent article we will dive into the requirements and implementation details for each method of integration. Please note that there may be additional integrations and authentication flows, this article series is however only covering 3 in particular. The 3 authentication flows we will discuss in this article series are: Network Policy Server (NPS) Azure MFA extension** SAML federation ROPC Oauth grant authentication flow **This replaces the legacy integration with Azure MFA Server which is no longer supported: https://devcentral.f5.com/s/articles/heres-how-i-did-it-integrating-azure-mfa-with-the-big-ip-19634 Method 1: Azure NPS Extension The method we will be examining in the first article of this series is integration between BIG-IP APM and Azure AD via a Network Policy Server (NPS) extension. This method is used to achieve Azure AD Multi-factor Authentication (MFA) capabilities for user authentication which is most often the primary business requirement for integration. User authentication requests are sent from BIG-IP APM to the NPS server where the NPS extension for Azure MFA will then inform Azure AD to initiate the MFA challenge. The NPS extension for Azure MFA does NOT support any conditional access policies, as the source of every authentication request from Azure AD's perspective will be that of the NPS server itself.By using this method, we can capture the username and password on the APM logon page for seamless password-based Single Sign-On (SSO), plus we get the MFA capabilities of Azure AD, truly the best of both worlds. Architecture and authentication flow: User requests a resource protected by BIG-IP APM and is presented with an APM logon page where they enter their credentials. BIG-IP captures these credentials as session variables and sends them to the predefined RADIUS AAA server, in this case that would be the NPS server with Azure MFA extension. The RADIUS server first validates user credentials, if successful then the 'AzureMFA' extension will notify Azure AD of the incoming user authentication request and initiate MFA challenge. The user is challenged using the chosen MFA method. Azure AD notifies the NPS extension of the MFA challenge result. The NPS extension responds back to the BIG-IP with a RADIUS response based on the outcome of the MFA challenge. If successful, the user is granted access to the protected application, webtop or resource. Pros: BIG-IP APM can capture both the username and password as session variables as part of the logon process, making password-based Single Sign-on (SSO) viable Requires no federation between BIG-IP and Azure AD Cons: Requires external infrastructure dependencies (Redundant NPS infrastructure) Azure AD Conditional access policy support is limited ***This however can be augmented with conditional policies on BIG-IP APM Method 2: SAML federation with Azure AD SAML is a well understood and adopted standard for federation between identity domains. By federating BIG-IP APM with Azure AD as the Identity Provider (IDP) we direct all user authentication requests to Azure AD. This means that all authentication features supported by Azure AD, such as Conditional Access Policies and MFA will work as intended, as the user is interfacing directly with Azure AD during authentication. By its very design, SAML federation limits the SAML Service Provider (SP), which is the role of BIG-IP APM in this case, from receiving the user's password as part of the authentication flow; this means we must use passwordless Single Sign-On (SSO) methods such as Kerberos or SAML for seamless access to applications and resources. Architecture and authentication flow: **Above depicts SP-initiated SAML authentication flow where BIG-IP APM is the Service Provider (SP) and Azure AD is the (IDP) User requests a resource protected by BIG-IP APM. APM responds to the user with a SAML request and directs them to the IDP (Azure AD). The user browser relays the SAML request to Azure AD. It is at this point that the user authenticates DIRECTLY with Azure AD. Once successfully authenticated (including MFA, if applicable), Azure AD responds to the user with a SAML response containing an Assertion and directs the user back to the BIG-IP APM. The user browser relays the SAML response to the BIG-IP and is provided access to the protected application or resource. Pros: Widely deployed and understood + very easy implementation Full support for conditional access policies and authentication functionality in Azure AD Cons: BIG-IP APM will not receive a password as part of the logon process - this means that password-based Single Sign-On (SSO) will not work out of the box ***We will explore options to get around this further in Article #3 Method 3: ROPC Oauth Grant The Resource Owner Password Credentials (ROPC) grant allows an application or intermediary to sign a user in by directly handling their password. Put simply, BIG-IP APM first captures the user credentials with a standard logon page and then validates them with Azure AD directly. This authentication flow may resemble that of traditional authentication flows such as Active Directory domain controllers or RADIUS servers. In most cases, ROPC grant flows are not highly recommended, as the user credentials are provided to the Oauth 2.0 client (BIG-IP) directly instead of to the Authorization Server (Azure AD) which arguably introduces additional risk.By using this method however, we capture the username and password on the APM logon page for password-based Single Sign-On (SSO) without requiring any on-premises infrastructure such as domain controllers or AAA servers to handle authentication. Architecture and authentication flow: User requests a resource protected by BIG-IP APM and is presented with an APM logon page where credentials are input. BIG-IP captures these credentials as session variables and sends them to the predefined Oauth Authorization Server (AS), Azure AD. If the credentials are correct, Azure AD responds to the BIG-IP with an ID token, Access token and optionally a refresh token. If successful, the user is granted access to the protected application or resource. Pros: BIG-IP APM can capture both the username and password as session variables as part of the logon process, making password-based Single Sign-on (SSO) viable Requires no on-premises infrastructure such as Active Directory or RADIUS/NPS for authentication Cons: Not recommended by Microsoft for Security reasons. No direct support for Azure AD MFA No support for Azure AD conditional access policies ***This however can be augmented with conditional policies on BIG-IP APM Summary In the first article of this series we reviewed 3 unique options for integration between BIG-IP APM and Azure AD. We also described the authentication flow as well as the pros and cons for each method. In each subsequent article, we will dive deeper into these three methods, providing detailed implementation instructions, caveats, and requirements as well as some anecdotal wisdom from the field!Citrix Federated Authentication Service Integration with APM
Introduction This guide will cover how to use APM as the access gateway in front of Storefront when using Citrix FAS. This will enable you to leverage authentication methods like SAML, Kerberos, or NTLM on the client side. Note that almost any auth method can be supported via Receiver for web, but Receiver self-service does not support some auth methods such as SAML. Deploy Citrix Federated Authentication Service Now you’ll need to deploy Citrix Federated Authentication Service (FAS). Deployment of FAS is out of scope for this article, but as there are many parts I found the following guide from Carl Stalhood very helpful: http://www.carlstalhood.com/citrix-federated-authentication-service-saml. Ignore the section “SAML on Netscaler Gateway” since you’re going to deploy APM instead, but don’t miss that last section “Configuring Storefront for SAML Gateway”. When configuring Storefront anywhere it requests the Netscaler Access Gateway address you’ll use the FQDN you intend to use for your virtual server on Big-IP (how users will access Storefront). Examples include the callback URL field when configuring the authentication and when configuring the Netscaler gateway. Before proceeding, you should be able to go direct to the Storefront server, log in, and be able to launch an application successfully. There can still be misconfigurations that prevent access through an access gateway, but you will have fewer areas left as problems. You must use an Enterprise CA, otherwise on the CA you will see pending certificates not getting approved automatically and you will be unable to launch apps. Also note that if you have previously made configuration modifications usually needed forearlier versions like Citrix 6.5, such as host file entries, those should be removed prior to proceeding. For correct operation of FAS, DNS needs to be setup properly which may include setting up PTR records. Create the SAML SP In the Big-IP GUI go to Access Policy -> SAML -> Big-IP as SP and click create. You’ll create an SP config and for the entity ID in the format https://my-vs-fqdn.domain.com. All the rest can be left default. Now you’ll need to setup your IdP Connector. This could be another Big-IP APM, ADFS, Okta, or any other IdP service. You can import the metadata if available or you can manually configure it. Configuring the IdP connector is out of scope for this article, but after configuring it, you’ll select your SP and click the “Bind/Unbind IdP Connectors” button, “Add New Row”, select it from the drop down as the SAML IdP Connector, then click Update, OK. Note that you can bind multiple IdP connectors here if there are multiple IdPs. You need to set a matching source (variable) and the matching value that should cause use of that IdP. A common solution might be %{session.server.landinguri} for the source and /customer1 for the matching value to go to customer 1’s IdP. Now you’ll see this on the SP configuration page. Your IdP should be setup to send either the user’s userPrincipalName or sAMAccountName as the NameID. This should match either the userPrincipalName or sAMAccountName of the user account in the AD domain used by Citrix that you want the user logged in as. Carl Stalhood’s guide linked above provides an example configuring the ADFS IdP and he is using userPrincipalName. Note that if you decide to use alternate UPNs (not matching your AD domain name) for your users you will also need to enable those domains in “Trusted Domains” on your Storefront server. Deploy the iApp Now we can move on to deploying APM as your access gateway. First, deploy the latest iApp. At the time of writing this article, that’s version 2.4.0. When deploying the iApp you’ll need to answer the following questions as shown: You’ll need to specify your STA servers: Finally, pay special attention to the DNS name you’re going to have clients use. This should be the same as you used in the Citrix Storefront configuration earlier and the SAML configuration later. This is how users are going to access the deployment. Now you have the iApp for Citrix deployed, but it’s using the default forms based authentication. You need to customize the authentication method. This guide will help you deploy SAML authentication, but as mentioned you could use NTLM, Kerberos, or another authentication method. Before proceeding you need to verify that the certificate you’ve selected is valid. If it is not, SSO will fail when Storefront tries to callback to the virtual server and the user will get the error “Cannot Complete Your Request”. You can browse to the FQDN you entered from the Storefront server to make sure you don’t get certificate errors. Normally you would use a publicly signed certificate and that will work fine (but don’t forget the chain). If it’s an internally signed certificate, your Storefront server needs to trust it as well. Modify the iApp’s APM Policy By default the policy looks like this: We need to modify it to look like this: To modify the policy you will need to turn off “strict updates” on the iApp: Note that in this case we aren’t modifying the Receiver branch because Receiver doesn’t support SAML authentication. You could just change it to deny receiver clients if desired. First remove the Logon Page, AD Authentication, and SSO Credential Mapping objects from the Browser branch. Next add a SAML Auth object right before the Session Variable Assign object (plus sign, Authentication tab, SAML Auth). Select the SP you configured earlier. Next, open the Session Variable Assign. You need to add a new entry, and set session.logon.last.username to equal the session variable session.saml.last.nameIDValue. Notice that the domain and sta_servers variables were set here already, those were done by the iApp. Here is what creating that looks like: Now your policy should look like the one above. Be sure to click Apply Policy in the top left. Test And finally you should be able to browse to the FQDN of your new virtual server, be redirected to your SAML IdP for authentication, then get redirected back and SSO’ed in to your Citrix environment. You should be able to see the Storefront catalog and launch an application Updates 12/21/2016 - Removed an iRule that is not needed for SSO to function properly in a complete deploymentSecure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2)
This article is the second in a two-part series. Go to Part 1 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2) Step 2: Configure F5 BIG-IP APM as SAML SP for the Application Refer to the step by step instructions and screenshots below to configure F5 BIG-IP APM as SAML SA for a new application called app.f5sec.net. 2.1 Import Certificate for the Application Import the certificate for app.f5sec.net. This certificate will be later referenced when configuring the application. •Log in to the F5 BIG-IP System. • On the F5 Configuration Utility (Web UI) Main menu, navigate to System > Certificate Management > Traffic Certificate Management > SSL Certificate List. •On the Traffic Certificate Management page, click the Import button on the right-hand corner. •On the SSL Certificate/Key Source page, select Key from the Import Type drop-down box. •Specify a Key Name and browse to the folder that contains the Key. After selecting the key file, click Import. • Back in the Traffic Certificate Management page, click on the imported Key name. • In the General Properties page, click on the Import button. •Browse to the folder that contains the Certificate. After selecting the certificate file, click Import. Figure 9: Importing application certificate and key 2.2 Using Guided Configuration The F5 BIG-IP APM Guided Configuration presents a completely new and streamlined user experience. This workflow-based architecture provides intuitive configuration steps tailored for a selected use case. The steps below will walk through the Guided Configuration to build the application and configure F5 BIG-IP APM as SAML SP. •On the F5 Web UI Main menu, navigate to Access > Guided Configuration. •Click on the Federation tile. From the expanded option, click on the SAML Service Provider tile. Figure 10: Guided configuration initial selection. •Take a moment to review the various configuration options on the SAML Service Provider page. Figure 11: SAML Service Provider page •Satisfy any of the DNS, NTP, Interface, VLAN, Route, and Self IP configuration prerequisites from this initial configuration page. •Scroll down and click Next. 2.2.1 Configure Service Provider Properties •To configure these properties, follow the guidance below. Figure 12: Sample ‘Service Provider Properties’ configuration. •Accept the remaining default entries and click Save & Next. 2.2.2 Configure Virtual Server Properties •To configure a virtual server for the app, follow these steps. Figure 13: Sample ‘Virtual Server Properties’ configuration. •Click Save & Next. 2.2.3 Configure Okta Identity Provider Connector •To configure Okta as the external SAML IdP provider, follow the steps below. Figure 14: Sample Okta IdP configuration. •Click Save & Next. 2.2.4 Create a Pool •To create a load balancing pool of application servers, follow the steps below. Figure 15: Sample ‘Pool Properties’ configuration. •Click Save & Next. 2.2.5 Configure Single Sign-On Settings •To configure Okta as the external SAML IdP provided, follow the steps below. Figure 16: Sample ‘Single Sign-on Settings’ configuration. •Click Save & Next. 2.2.6 Endpoint Checks Select the Enable Endpoint Checks radio button to enable endpoint checks. For this demonstration, we will leave this setting at default. Figure 17: 'Endpoint Checks Properties' page to enable and configure endpoint checks. •Click Save & Next. 2.2.7 Session Management Leave the Timeout Settings at default. Figure 18: Default timeout settings •Click Save & Next. 2.2.8 Summary Review the Summary screen. When done, scroll down and click Deploy. Figure 20: Confirmation of a successful deployment. • Click on the Finish button. This completes the F5 BIG-IP APM configuration. Step 3: Verification We will verify the solution by accessing app.f5sec.net. •Open a web browser on an end host and navigate to https://app.f5sec.net. Notice the request will be redirected to Okta.com for user authentication. Figure 21: Redirection to Okta for user authentication. •The application default web page prints all the headers. Notice that the HTTP_MYAUTHORIZATION header has been inserted with the appropriate value. Figure 22: HTTP_MYAUTHORIZATION header inserted with user identity value. Additional Resources Part 1 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 BIG-IP APM Product Information: Knowledge Center Free Training Course: Getting Started with BIG-IP Access Policy Manager (APM) Lightboard Lesson: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication External Resource: F5 | Okta partnershipSecure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2)
This article is the first in a two-part series. Go to Part 2 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2) Introduction Despite recent advances in security and identity management, controlling and managing access to applications through the web—whether by onsite/remote employees or contractors, partners, customers, or the public—is as difficult as ever. IT teams are challenged to control access based on granular characteristics such as user role while still providing fast authentication and, preferably, unified access with single sign-on (SSO) capabilities. The ability to recognize and stop attempts at unauthorized access is critical in today’s security environment. The joint F5 BIG-IP® Access Policy Manager® (APM) and Okta identity management platform solution address these challenges. This solution provides extended access management capabilities across on-premises and cloud environments enabling organizations to secure web applications anywhere.In addition to authentication management and policy-based authorizations, the solution also supports applications with header-based and Kerberos based authentication. The F5 and Okta Solution In this SAML 2.0 integrated solution (shown in Figure 1), •Okta is the Identity Provider (IdP). Users can be defined locally within Okta. In most cases, an on-premises Active Directory and/or LDAP is the source of identities and is integrated with Okta via Okta’s AD/LDAP agent. •Between Okta and the F5 BIG-IP system, a SAML trust is built with the BIG-IP platform acting as a SAML service provider (SP). •The target applications are protected behind the BIG-IP reverse proxy by header-based or Kerberos authentication. •SAML assertion from Okta is consumed by the BIG-IP system, which then translates the assertion appropriately for the downstream application based on its authentication scheme. Figure 1: The basic integration between the F5 BIG-IP system and Okta for single sign-on (SSO) Deployment Procedure This procedure described below is based on a lab environment. The instructions below may be modified to match your specific needs or requirements. Prerequisites •Refer to AskF5 for additional information, including how to initially set up a BIG-IP environment including basic BIG-IP® Local Traffic Manager® (LTM) and BIG-IP APM configurations. F5 BIG-IP TMOS® version 15.1 is used for this demonstration. However, these practices apply for versions 11.0 and later. •For additional information about configuring the Okta portion of the solution, refer to Okta documentation. Step 1: Configure Okta as SAML IDP for a New Application Refer to the step by step instructions and screenshots below to configure Okta as a SAML IdP for a new application called app.f5sec.net. 1.1 Okta Classic User Interface For this lab demonstration, we are using the Okta developer account. Click here to sign up for an Okta developer account, if you don’t already have one. •Log in to the Okta developer portal using your username and password. •For this demonstration, we will be using the Classic UI. On the top left corner of the developer portal, change the drop-down from Developer Console to Classic UI. Figure 2: Switching the Okta user interface to the Classic option. 1.2 Build a New Application We will build a new web application for SAML 2.0 integration. •On the main menu, hover on the Applications tab and click on Applications. •On the Applications page, click on the Add Application button. •On the Add Application page, click on the Create New App button. •In the Create a New Application Integration dialogue box, select the Web option in the Platform drop-down and SAML 2.0 as the Sign on method and click Create. Figure 3: Creating a new application for SSO using SAML 2.0 •On the Create SAML Integration page, under the General Setting section, enter the app name and click Next. Figure 4: Entering the app name •In the SAML Settings section, under the GENERAL options, enter the Single sign on URL and the Audience URI. Figure 5: Sample SAML configuration •Leave all other values as default and click Next. •In the next section, check the radio button that says, “I’m an OKTA customer adding an internal app”. •In the expanded window, select “This is an internal app that we have created” for App Type and click on Finish. Figure 6: Sample feedback configuration •In the resulting application page for app.f5sec.net, navigate to the SAML 2.0 section. •Right-click the Identity Provider Metadata hyperlink and click Save Link As. •Save the metadata.xml to the local system. We will be using this file later when configuring F5 BIG-IP APM as SAML SP. Figure 7: Exporting the IdP metadata 1.3 Assign Users to the Application Next, we will assign users to the application, granting them access. •Scroll up and click on the Assignments tab beneath app.f5sec.net. •Click on the Assign button and then again click Assign to People from the drop-down. •In the pop-up dialog box, click on the Assign button next to all the users that you want to assign access to app.f5sec.net web application. •When finished, click Done. Figure 8: Assigning users to the application This completes the Okta configuration. Next, we will move on to F5 BIG-IP APM for SAML SP and web app configuration. Part 2 - Secure Access to Web Applications with F5 and Okta using SAML 2.0APM Cookbook: AutoLaunch SAML Resources
Introduction After the SAML labs at Agility I got a lot of questions about how to automatically launch SAML resources and skip the webtop, and I promised I'd write it up for you. If you haven't been to Agility, check it out next year, it's a great event! Let's say you have a virtual server available at idp.company.com with a webtop and SAML resources on it. Users are complaining that they have to login to the webtop and click the resource they want instead of automatically getting to what they wanted. Fortunately this is easy to solve! There are two easy ways to automate this and improve your user's experience. In either solution below you'll add the iRule to the virtual server hosting the webtop. You can add additional lines for more matches right below the switch statement just like I've shown on the example. The part that starts with "/saml/idp/res?id=" is a reference to the SAML resource, so it will be the full SAML resource path after that. My example SAML Resource object is named "app1-saml-resource" and is under the default /Common partition. Yours may be under a different partition or iApp container so you can adjust the path accordingly. URI Based Autolaunch iRule This solution requires users to specify in the URI which resource they want. In this example, putting idp.company.com/app1 into the address bar will autolaunch the app1 SAML resource. when ACCESS_POLICY_COMPLETED { switch -glob [string tolower [ACCESS::session data get session.server.landinguri]] { "/app1" {ACCESS::respond 302 Location "/saml/idp/res?id=/Common/app1-saml-resource"} } } when ACCESS_ACL_ALLOWED { switch -glob [string tolower [HTTP::uri]] { "/app1" {ACCESS::respond 302 Location "/saml/idp/res?id=/Common/app1-saml-resource"} } } Improvement: Hostname Redirects This improvement enables the user to use an alternate hostname to reach the webtop VS and get redirected to the autolaunching URI. You'll need to have a wildcard or SAN certificate and you can CNAME the new hostname to your original one, idp.company.com. In this example, if the user reaches the webtop by going to app1.company.com then they will be redirected to https://idp.company.com/app1 and get autolaunch. You just add this code to the bottom of the other iRule or place in a separate iRule. when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { "app1.company.com" { HTTP::redirect "https://idp.company.com/app1" } } } And that's it!Post of the Week: SAML IdP and SP on One BIG-IP
In this Lightboard Post of the Week, I answer a question about being able to do SAML IdP and SP on a single BIG-IP VE. Thanks to DevCentral Members hpr and Daniel Varela for the question and answer. +25 DC points for ya! Posted Question on DevCentral: https://devcentral.f5.com/s/questions/apm-ltm-121-saml-idp-and-sp-possible-in-one-ve-58114 If you got an answer you'd like lit up on the Lightboard, let us know in the comments! psSingle Sign-On (SSO) to Legacy Web Apps Using BIG-IP & VMware Workspace ONE
A few months back VMware announced a joint collaborative effort on delivering even more applications to their Workspace One suite utilizing F5 BIG-IP APM to act as an authentication translator from SAML to legacy Kerberos and header-based web applications. How does it work? VMware Workspace ONE acts as an identity provider (IDP) that provides SSO access to cloud, mobile and SAML applications. F5 BIG-IP APM extends that functionality and as a service provider (SP) to Workspace ONE for Kerberos and header-based web applications. BIG-IP APM can take in a user’s SSO authentication credential (SAML assertion) from Workspace ONE and authenticate as that user into BIG-IP APM. Once the Authentication is completed BIG-IP APM will create a Kerberos Constrained Delegation (KCD) or header-based authentication using the user’s Realm (Domain). BIG-IP APM will then pass the authentication token to the legacy web application on behalf of the user. This will prevent the pop-up login dialog boxes from appearing and providing a seamless authentication from Workspace ONE to the legacy web application. BIG-IP can provide intelligent traffic management, high availability, secure SSL access through bridging or offloading, and monitoring using BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS (Formerly BIG-IP GTM). BIG-IP's Access Policy Manager (APM) can also provide secure access to the apps and resources accessible through the Workspace ONE portal. You can now download the updated step-by-step guide for integrating VMware Workspace ONE and BIG-IP APM for Legacy Web applications. https://www.vmware.com/pdf/vidm_implementing_SSO_to_kdc-and-hb_apps.pdf. You can also read more about this integration from VMware’s publishing’s from Ben Siler discussing the integration. https://blogs.vmware.com/euc/2016/10/single-sign-on-sso-legacy-apps-workspace-one-f5.html F5 has also provided a brief video talking and showing this integration in action Click the link below to see the video. https://devcentral.f5.com/s/articles/lightboard-lessons-sso-to-legacy-web-applications-24410 Here is an snipping from the documentation on setting up Kerberos within F5 APM. Setting up Kerberos Constrained Delegation (KCD) in BIG-IP APM If you are integrating a KCD app, you should now set up KCD in APM. Open the F5 BIG-IP admin console. Click Access Policy > SSO Configurations > Kerberos > plus icon ( +). In the New SSO Configuration menu, click Kerberos. Enter a unique name for your KDC SSO Configuration Set the Username Source field to session.sso.token.last.username Set the User Realm Source field to session.ad.last.actualdomain Set the Kerberos Realm field to your active directory domain (in CAPS). Set the Account Name field to your Kerberos service account and enter your account password. Note: If a Kerberos Service Account hasn’t been created it is recommended to create one via the following documentation. https://www.f5.com/pdf/deployment-guides/kerberos-constrained-delegation-dg.pdf Set the Account Password and Confirm Account Password fields with the Password associated to the Kerberos service account. Leave all other non-required fields with the default settings. (Required fields have a blue line) . Click Finished. Setting up Domain Authentication In the BIG-IP admin console, click Access Policy > AAA Servers > Active Directory > plus Icon ( + ). Enter a friendly name in the Name field. Set the Domain Name field to your Active Directory Domain Name (FQDN). Set the Server Connection radio button to Use Pool to increase resiliency. Set the Domain Controller Pool Name to a friendly name for your pool (no spaces allowed). Set the IP Address field to the IP Address of your domain controller. Set the Hostname field to the short name for your domain controller. Click Add, to add the domain controller to your pool. Repeat steps iv, v, and vi for each domain controller you want to add to the pool. Set the server pool monitor drop-down to gateway_icmp. Set the Admin Name field to your domain admin user. Set the Admin Password field to your domain admin’s password. Set the Group Cache Lifetime field to 30 days. Set the Password Security Object Cache Lifetime to 30 days. Click Finished. Special Thanks to Ben Siler, Paul Pindell, Peter Silva and Cody Green for all of their assistance putting this together!
