Application Programming Interface (API) Authentication types simplified
API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX API Connectivity Manager authentication and NGINX Single Sign-on.
BIG-IP APM: Max Sessions Per User – Enable users to terminate a specified session
Technical Challenge Recently I was speaking with a customer and they mentioned that they leveraged the “Max Sessions Per User” setting within BIG-IP APM Access Profile to limit the number of concurrent connections that a single user could have at any point in time. The customer mentioned that this works but often their users would complain that the “wrong” session was terminated or that a session they were actively using was closed. After reproducing the scenario in a lab environment I observed that the BIG-IP APM would terminate sessions based on FIFO (First In, First Out). Meaning that the oldest session was always terminated first regardless of which session the user was actively interacting with. Since this was confusing for the customer I figured others experienced this problem and it would be worth sharing my solution with the world. So how do you enforce “Max Sessions Per User” and enable your users to intelligently select which session to terminate? The Solution If we break down the problem statement above we can see that it it is really two issues. First we need to identify if a user has exceeded the maximum number of allocated sessions, then if they have we need to provide them a way to select which session should be terminated. Enforce Max Sessions Per User BIG-IP APM Access Profiles natively provide a way to limit the Maximum number of Sessions a user can establish but it doesn’t provide a way to interact with pre-existing sessions. For more information on Access Profile settings see => https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-network-access-11-6-0/9.html#taskid If the built-in functionality won’t achieve what we want lets build our own using APM iRule Events. iRule Session Enforcement The ACCESS::uuid iRule function will allow us to identify all active sessions for a specified Access Profile and Username. The iRule below will prevent a user from establishing more than 3 sessions when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when ACCESS_POLICY_COMPLETED { set max_sessions 3 set apm_username [ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] log local0. "[PROFILE::access name].$apm_username => session number [llength $apm_cookie_list]" if {[llength $apm_cookie_list] >= $max_sessions} { ACCESS::session remove ACCESS::respond 302 location "/vdesk/hangup.php3" } } This will allow us to limit concurrent connections for a user but is too late in the authentication process to enable the user to select a session to terminate. Instead of having the logic execute in the ACCESS_POLICY_COMPLETED section let’s try using an VPE iRule event. APM VPE iRule Event Session Enforcement First update your Access Policy to look similar to the images below with an iRule Event placed after the user authentication event. The iRule event id will be referenced in your iRule max_session_count The branch logic will be used to identify if the user has more than 3 concurrent sessions expr { [mcget {session.logon.last.count}] >= 3} Update the iRule you created earlier with the code below, this will allow the VPE policy to pause and execute events within the iRule. when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } } } Now as long as the user is below the defined maximum allowed connections they will be allowed to connect as normal. Enabling users to select a Session to be Terminated Now this is the tricky part, we need to provide an interface to the user that will enable them to select a session to be terminated. We could spend a bunch of time creating a custom web interface using javascript or we could re-purpose the Logon Page object built into the APM and display the information to the user with minimal customization. Remove the Password field from the Logon Page object and replace it with Radio and set the variable name to terminate Click on the textbox in the Values column of the terminate row and add one entry for each session the user is allowed to have. (If the max session count is set to 3 then add 3 options) The contents for the radio buttons will be dynamically generated within the iRule Event and stored as APM Session Variables The Value field should be %{session.logon.active.#.sid} (Session ID’s will be stored in a list variable that starts at 0, replace # with the appropriate index number starting at 0) %{session.logon.active.0.sid} %{session.logon.active.1.sid} %{session.logon.active.2.sid} The Text field should be %{session.logon.active.#.text} (The # should be replaced with the corresponding list index id) %{session.logon.active.0.text} %{session.logon.active.1.text} %{session.logon.active.2.text} After adding the appropriate number of options the final option should be cancel with text that will indicate that the current session will be terminated if the user selects cancel Click on the Branch Rules tab and add a new Branch Rule to handle logic that will allow the user to cancel Session Termination expr { [mcget {session.logon.last.terminate}] == "cancel" } Next update the iRule created earlier with the snippet listed below. The updated iRule will populate the session variables that will be used to display session information to the user. when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list[ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _clientip[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.clientip] set _starttime[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.starttime] set _timeformat[clock format $_starttime -format "%H:%M:%S %d %b %Y "] set _connectiontype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.user.sessiontype] set _browsertype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.client.type] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] set _sessioninfo"<table style='border-collapse: collapse' width='100%'>" append _sessioninfo"<tr><td style='border: 1px solid black'>Session ID</td><td style='border: 1px solid black' align='center'>$_sessionid</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Start Time</td><td style='border: 1px solid black' align='center'>$_timeformat</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Client IP</td><td style='border: 1px solid black' align='center'>$_clientip</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Connection Type</td><td style='border: 1px solid black' align='center'>$_connectiontype</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Browser Type</td><td style='border: 1px solid black' align='center'>$_browsertype</td></tr>" append _sessioninfo"</table>" ACCESS::session data set session.logon.active.$i.sid $_sessionid ACCESS::session data set session.logon.active.$i.text $_sessioninfo } ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } } } Terminate the selected Session Now that we have a way to select a session to terminate add a second VPE iRule Event to handle the Session Termination The iRule event id will be referenced in your iRule terminate_session The branch logic will be used to verify that the session was terminated successfully, if it fails to terminate the users current session will be terminated instead. expr { [mcget {session.logon.last.terminateresult}] == 1 } Next update the iRule created earlier with the snippet listed below. The updates will add a second iRule Event that will handle the session termination when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list[ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _clientip[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.clientip] set _starttime[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.starttime] set _timeformat[clock format $_starttime -format "%H:%M:%S %d %b %Y "] set _connectiontype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.user.sessiontype] set _browsertype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.client.type] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] set _sessioninfo"<table style='border-collapse: collapse' width='100%'>" append _sessioninfo"<tr><td style='border: 1px solid black'>Session ID</td><td style='border: 1px solid black' align='center'>$_sessionid</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Start Time</td><td style='border: 1px solid black' align='center'>$_timeformat</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Client IP</td><td style='border: 1px solid black' align='center'>$_clientip</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Connection Type</td><td style='border: 1px solid black' align='center'>$_connectiontype</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Browser Type</td><td style='border: 1px solid black' align='center'>$_browsertype</td></tr>" append _sessioninfo"</table>" ACCESS::session data set session.logon.active.$i.sid $_sessionid ACCESS::session data set session.logon.active.$i.text $_sessioninfo } ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } "terminate_session" { set removed0 set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _terminateid[ACCESS::session data get session.logon.last.terminate] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] if {$_sessionid eq $_terminateid} { set removed 1 ACCESS::session remove -sid [lindex $apm_cookie_list $i] break } } ACCESS::session data set session.logon.last.terminateresult$removed } } } Time to Test Now establish enough sessions to exceed the maximum concurrent user count and you should see receive a logon page prompting you to select a session to terminate. Putting Everything Together Step 1 – Edit your Access Policy When this step is complete your Access Policy should look similar to the attached imaged The first iRule Event should have the following information populated The iRule event id will be referenced in your iRule max_session_count The branch logic will be used to identify if the user has more than 3 concurrent sessions expr { [mcget {session.logon.last.count}] >= 3} The “Logon Page – Session Termination” should have the following information populated Remove the Password field from the Logon Page object and replace it with Radio and set the variable name to terminate Click on the textbox in the Values column of the terminate row and add one entry for each session the user is allowed to have. (If the max session count is set to 3 then add 3 options) The contents for the radio buttons will be dynamically generated within the iRule Event and stored as APM Session Variables The Value field should be %{session.logon.active.#.sid} (Session ID’s will be stored in a list variable that starts at 0, replace # with the appropriate index number starting at 0) %{session.logon.active.0.sid} %{session.logon.active.1.sid} %{session.logon.active.2.sid} The Text field should be %{session.logon.active.#.text} (The # should be replaced with the corresponding list index id) %{session.logon.active.0.text} %{session.logon.active.1.text} %{session.logon.active.2.text} After adding the appropriate number of options the final option should be cancel with text that will indicate that the current session will be terminated if the user selects cancel Click on the Branch Rules tab and add a new Branch Rule to handle logic that will allow the user to cancel Session Termination expr { [mcget {session.logon.last.terminate}] == "cancel" } The second iRule Event should have the following information populated The iRule event id will be referenced in your iRule terminate_session The branch logic will be used to verify that the session was terminated successfully, if it fails to terminate the users current session will be terminated instead. expr { [mcget {session.logon.last.terminateresult}] == 1 } Step 2 – Create and Apply the Custom iRule when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list[ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _clientip[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.clientip] set _starttime[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.starttime] set _timeformat[clock format $_starttime -format "%H:%M:%S %d %b %Y "] set _connectiontype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.user.sessiontype] set _browsertype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.client.type] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] set _sessioninfo"<table style='border-collapse: collapse' width='100%'>" append _sessioninfo"<tr><td style='border: 1px solid black'>Session ID</td><td style='border: 1px solid black' align='center'>$_sessionid</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Start Time</td><td style='border: 1px solid black' align='center'>$_timeformat</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Client IP</td><td style='border: 1px solid black' align='center'>$_clientip</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Connection Type</td><td style='border: 1px solid black' align='center'>$_connectiontype</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Browser Type</td><td style='border: 1px solid black' align='center'>$_browsertype</td></tr>" append _sessioninfo"</table>" ACCESS::session data set session.logon.active.$i.sid $_sessionid ACCESS::session data set session.logon.active.$i.text $_sessioninfo } ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } "terminate_session" { set removed0 set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _terminateid[ACCESS::session data get session.logon.last.terminate] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] if {$_sessionid eq $_terminateid} { set removed 1 ACCESS::session remove -sid [lindex $apm_cookie_list $i] break } } ACCESS::session data set session.logon.last.terminateresult$removed } } }
Windows 10 Support (including F5 BIG-IP Edge Client) Available With Certain BIG-IP APM Versions
This isthelatestinformation available from F5 regarding MicrosoftWindows 10 support (including F5 BIG-IP Edge Client) with certain BIG-IP APM versions. Microsoft Windows 10 support is available for certain BIG-IP APM versions. This entry replaces the original AskF5 solution (SOL16626) on support.f5.com F5 currently supports Microsoft Window 10 for the following versions: BIG-IP 12.0.0(seeF5 BIG-IP APM Client Compatibility Matrix for 12.0.0) Note: Support for Windows 10 has been added in BIG-IP 12.0.0 HF1 and later. For more information about BIG-IP hotfixes, please refer toSOL13123: Managing BIG-IP product hotfixes (11.x - 12.x). BIG-IP 11.6.0 (see F5 BIG-IP Client Compatibility Matrix for 11.6.0) Note: Support for Windows 10 has been added in BIG-IP 11.6.0 HF6 and later. For more information about BIG-IP hotfixes, refer toSOL13123: Managing BIG-IP product hotfixes (11.x - 12.x). BIG-IP 11.5.3 (see F5 BIG-IP APM Client Compatibility Matrix for 11.5.3) Note: Support for Windows 10 has been added in BIG-IP 11.5.3 HF2 and later. For more information about BIG-IP hotfixes, please refer toSOL13123: Managing BIG-IP product hotfixes (11.x - 12.x). Previously, in the original AskF5 solution (SOL16626), it was stated that F5 planned to support Windows 10 withBIG-IP 11.4.1. However, as many customers have been able to upgrade to newer versions of BIG-IP, and because F5customersshouldbenefit substantially from stability improvements in BIG-IP 11.5 and 12.0.0, which are within F5’sMajor Release/Long Term Stability Release model, F5 will not be providing additional support for Windows 10 with BIG-IP APM 11.4.1, as previously stated. Additionally, F5 will be enabling the following as regards Windows 10: Windows 10 Browser Support The Windows Internet Explorer browser included in the Windows 10 release is supported. The BIG-IP APM system does not currently support the Microsoft Edge (Spartan) browser. Inbox F5 VPN Client Windows 8.1 includes a built-in VPN client for BIG-IP APM (Inbox F5 VPN Client). For Windows 10, the VPN client for the BIG-IP system will be available for download from the Windows Store. Please note that the name of the app may also change. Windows Protected Workspace The Windows Protected Workspace feature of BIG-IP APM is not currently supported on Windows 10. Client side checks Certain client-side security checks (such as Patch Management and Windows Health Agent) are no longer supported on Windows 10. Depending on how you use these checks with BIG-IP APM, these Windows 10 client checks may fail. For information about adding Windows 10 clients to BIG-IP APM, please refer toSOL16874: Adding a new device type detection to an access policy.Addressing Security Loopholes of Third-Party Browser Plug-ins - UPDATED FEBRUARY 2017
February 2017 Update Endpoint inspection and network access support with Chrome browser, Firefox, and Edge Browser is now available for BIG-IP v13 . Release notes with details are available here:https://support.f5.com/kb/en-us/products/big-ip_apm/releasenotes/related/relnote-helper-apps-13-0-0.html. January 2017 Update As the popularity of browser-based security attacks and vulnerabilities continue to increase, scrutiny is turning to third-party browser plugins as an attack vector. Java and Flash have both been successful targets, as have certain third-party malicious plugins. As a result, browser vendors are eager to close loopholes that allow control of page content and computer operation outside of the browser context. The longstanding F5 client technique of using browser plugins to allow VPN, application tunnel, and endpoint security checks utilize these functions. To mitigate these concerns, F5 will soon end the use of browser plug-ins. This will support the ability to run the endpoint security checks and connectivity operations such as SSL VPN and app tunnels with client PCs using new versions of popular web browsers - Google Chrome, Firefox, and Microsoft Edge Browser, in addition to Microsoft Internet Explorer and Apple Safari. F5’s plan is to use components that will be installed by end users that run outside of the browser process, thereby eliminating the security concerns of using browser plug-ins. These client components will register a URI scheme and will be able to be called from the browser when users launch a VPN or app tunnel from BIG-IP APM web portals, endpoint security checks (firewall, antivirus, and OS patch and registry checks). Additionally, a plug-in-less technique will be used to launch native Microsoft Remote Desktop apps or desktops on the user’s device without the traditional use of an ActiveX plugin. This solution will not require the use of browsers’ NPAPI support. Although end users will be required to download and install components that run outside of the browser process, F5’s most important goal is to keep the user experience as close to the current browser-initiated experience on currently supported browsers as much as possible. Alternatively, the client components may be installed by Microsoft’s SCCM or other automatic software installation systems in end user populations with limited rights on PCs. With this plan, F5 will also be able to support 64-bit versions of browsers specified above as well. In the meantime, you can use the below instructions to detect unsupported browsers and guide the user to a supported browser with a remediation message. Handling new Firefox and Chrome browsers in BIG-IP APM. Client browsers can be detected by their User-Agent header transmitted along with HTTP requests. APM automatically creates a session variable during Access Session creation that contains this value. It’s a simple matter to handle this in an appropriate way. Launch the Visual Policy Editor. Access Policy => Access Profiles => (your access policy) => Edit. The VPE will launch in a new browser tab Click the + icon to add a new Policy Item. Choose General Purpose => Empty and click Add Item. The new Policy Item will appear Name the Policy Item appropriately. (In this example, “Browser Info” was chosen.). Select the Branch Rules tab and click Add Branch Rule. Name the branch rule “Firefox 43” Click Advanced. Insert the TCL code: expr { [mcget "session.user.agent"] contains "Firefox/43" } Repeat the last 3 steps, this time for Firefox 44. Your new Policy Item should look something like this: 10. ClickSaveto save the changes to the Policy Item. Now we need to add a user friendly error message. 11. Near the top of the VPE screen, clickEdit Endings. 12. ClickAdd Ending. 13. Name the ending “Unsupported Firefox” 14. Click the+near Customization. 15. Change the text to something appropriate for your users. This is a sample: 16. Because the user should close the browser and use a different one, it doesn’t make sense to display a “Restart Session” link, so we simply hide it using the HTML <!-- and --> tags in the New session text and New session link areas. 17. Click the Deny endings attached from Firefox 43 and 44, and change them to the new “Unsupported Firefox” endings. 18. Review your Access Policy. The new section should appear similar to this (note that this policy is empty -- your normal policy should be attached to the “fallback” branch). 19. Test this with Firefox 43 or 44. You should see an error page similar to this: If you need to detect additional browsers and are not sure of the user agent, simply add a Message Box Policy Item to the beginning of the policy to log your browser’s User Agent string, like this: When a browser activates this Policy Item, the User-Agent will be displayed. We hope this is helpful. Update January 2017 Currently the latest Firefox version is release 50. Releases 50 and 51 include NPAPI plugin support that is required by F5 endpoint inspection and VPN access. Firefox release 52 will not allow the use of F5 plugin by default. This means that endpoint inspection and VPN will not function with Firefox browser for BIG-IP APM end users. F5 is planning to release BIG-IP version 13.0 that includes the new lite endpoint check and VPN clients that support a seamless end user experience with Firefox, Microsoft Edge Browser, and Chrome Browser. Based on current release schedules from F5 and Mozilla, the BIG-IP v13.0 release may not be available before Firefox 52 is released. If your end users require endpoint inspection or VPN launch capability with Firefox browser, we recommend installing Firefox ESR. This version will include plugin capability until early 2018. Firefox 51 Firefox 52 Firefox 53 Firefox ESR 52 F5 plugin allowed F5 plugin not allowed by default F5 plugin can be enabled via a configuration parameter in Firefox.* F5 plugin not allowed. F5 plugin will not be enabled even with a configuration parameter used in Firefox 52. F5 plugin allowed by default until Q2 Calendar Year 2018 *Firefox 52 Note: The configuration parameter is called plugin.load_flash_only, and it should be set to false. After this configuration parameter is created and set, the user needs to quit Firefox and delete pluginreg.dat file under profiles folder. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1269807 for more details. Note that this is preliminary information about a non-F5 product and is subject to change. Refer to the information about Firefox ESR: https://www.mozilla.org/en-US/firefox/organizations/ Information from Mozilla on future NPAPI support: https://blog.mozilla.org/futurereleases/
F5 Access Policy Manager and Firefox Browser version 43 and 47+
Firefox Browser version 43 has new plug-in signing requirements. F5 will be providing Engineering Hotfixes for BIG-IP versions 12.0.0, 11.6.0, and 11.5.3, which will include a F5 Access Policy Manager plug-in signed by Firefox for Microsoft Windows and Linux platforms. With F5 officially supporting Firefox version 34, this is a “best efforts” approach to alleviate any disruptions brought about by Firefox version 43 and the upcoming Firefox version 44, related to plug-in signing requirements (Feature Enhancement ID:564253). If issues are uncovered with versions of Firefox greater than version 34 after installing the appropriate Engineering Hotfix, it is recommended that users be guided to use Microsoft Internet Explorer on Windows, and Safari on Mac, as detailed in thisDevCentral post. Another option is to use BIG-IP Edge Client for these two platforms. For Linux, there is a CLI client available for network access. These Engineering Hotfix releases are short-term fixes. A more permanent solution will be available in an upcoming release of BIG-IP; specifics will also be available in the aforementioned DevCentral post. We will make the Engineering hotfixes available for customers who create a support case with F5 Support. This Engineering Hotfix should be good for up to Firefox 46 and F5 will need to have Mozilla sign the plug-in again for Firefox 47+. This is just how Firefox plug-in signing works currently. January 7, 2016 Update: While we (F5) is making progress in getting the Engineering hotfixes out, we are currently working through some issues seen with the Mozzilla add-on submission tool. Once that is resolved, then we expect to be able to provide an ETA for the Engineering Hotifxes. F5 is working on this with urgency. January 8, 2016 Update: We (F5) have the issue with the Mozilla add-on tools resolved, so we can provide a target ETA of January 15, 2016 (Friday) to provide Engineering Hotfixes for the 3 versions of BIG-IP we had mentioned on this post. January 14, 2016 Update: We have run into a few issues that need to be addressed so we will need a few more days to have the Engineering Hotfixes available. Again,F5 is working on this with urgency. January 21, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.6.0, based on BIG-IP 11.6.0 Hotfix 6 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 12.0.0 and 11.5.3 soon. January 25, 2016 Update: We have an Engineering Hotfix for BIG-IP 12.0.0 based on BIG-IP 12.0.0 Hotfix 1 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 11.5.3 soon. January 26, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.5.3 based on BIG-IP 11.5.3 Hotfix 2. Customers should create a support case with F5 Support. F5 will target to release Engineering Hotfixes before Firefox 47 is available. May 9, 2016 Update: F5 is currently working on Engineering Hotfixes for the various BIG-IP for Firefox 47+ that would work for all Firefox versions (even Firefox 46 and earlier). Mozilla is allowing for plug-in signing for all (*) versions of Firefox again. We do not have the releases ready for customers yet but expect to have it shortly. Once they are available, we will announce it here and also provide it initially to F5 Support and thus customers can get it via a Support ticket. Shortly after it is available via F5 Support, we will provide it on https://downloads.f5.com. May 16, 2016 Update: F5 has Engineering Hotfixes for 11.5.4 HF1 and 11.6.0 HF6 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for12.0.0 HF2 and 11.6.1. May 21, 2016 Update: F5 has Engineering Hotfix for 12.0.0 HF2 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for11.6.1 and 12.1.0. May 31, 2016 Update:F5 has Engineering Hotfix for 11.6.1 available. For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. *These Engineering Hotfixes should work on all versions of Firefox, including 47+, until Firefox removes its NPAPI support. To address that we have another DevCentral post: here:https://devcentral.f5.com/s/articles/addressing-security-loopholes-of-third-party-browser-plug-insPlugging Data Leaks
Whether intentional or accidental, data leaks are a huge concern for organizations. And it has been for years. Going back to a 2004 survey from an IT security forum hosted by Qualys, found that 67% of security executives do not have controls in place to prevent data leakage, A December 2006 survey, Boston-based researchers Simon Management Group noted that some 78% of respondents said they were "very concerned" about data exposure. A 2010 article published by Trustwave on CSOonline.com said that 65% of leakage occurs due to the following combined methods: Microsoft SMB sharing, Remote Access Applications, and Native FTP clients. And a recent informal survey conducted by the Avast Mobile Enterprise team at two healthcare technology events indicates that Data Leakage (69%) was the greatest security concern of Healthcare CISOs. Insider threats (34%) and Malware (28%) got silver and bronze. Information seems to be the gold standard in today’s digital society and it comes in many forms. It can be personally identifiable information (PII) of customers or employees; it can be corporate or financial info; it can be litigation related; it can also be health care related and really, any data that should be kept secret…except from those who are authorized to view it. According to Cisco, some risky behavior by employees can aggravate the situation. Areas included: Unauthorized application use: 70% of IT professionals believe the use of unauthorized programs resulted in as many as half of their companies' data loss incidents. Misuse of corporate computers: 44% of employees share work devices with others without supervision. Unauthorized physical and network access: 39% of IT professionals said they have dealt with an employee accessing unauthorized parts of a company's network or facility. Remote worker security: 46% of employees admitted to transferring files between work and personal computers when working from home. Misuse of passwords: 18% of employees share passwords with co-workers. That rate jumps to 25 percent in China, India, and Italy. How can you reduce and mitigate some data leakage risks? BIG-IPcan help shore up some areas. The overall category of Data Loss Prevention (DLP) is a multi-faceted area of security that encompasses securing data storage, data transmission, and data in-use. Specifically, BIG-IP ASM focuses on the protection of data in-flight. For instance, ASM’s DataGuard is a method of protecting against SSN or CC# information from leaking out of back-end databases but ASM’s benefits in a DLP strategy extend well beyond that. DLP is concerned with unauthorized access to any private data, whether confidential personal or corporate information. ASM provides comprehensive protection against unauthorized back-end database access, by preventing the exploit of well-known vulnerabilities such as XSS, SQL-injection, cookie poisoning, etc. If you can’t even reach the info, less likelihood of it leaking. No single product is going to provide a comprehensive, all inclusive DLP solution. HIPAA, PCI, and other regulatory standards are focused almost entirely on DLP. BIG-IP ASM, as a WAF, provides a vital part of any overall DLP solution in today’s security-conscious environment. ps Related: Survey Says: Data Leakage Tops Healthcare CISOs Concerns Data Leakage Worldwide: Common Risks and Mistakes Employees Make Stealing 11.5 million documents not so hardInternet of Insider Threats
Identify Yourself, You Thing! Imagine if Ben Grimm, aka The Thing, didn’t have such distinctive characteristics like an orange rocky body, blue eyes or his battle cry, ‘It’s Clobberin’ Time!’ and had to provide a photo ID and password to prove he was a founding member of the Fantastic Four. Or if the alien in John Carpenter’s The Thing gave each infected life-form the proper credentials to come and go as they please. Today the things we call ‘Things’ are infiltrating every aspect of society but how do organizations identify, secure and determine access for the 15+ connected chips employees will soon be wearing to the office? And what business value to they bring? Gartner refers to it as the ‘Identity of Things’ (IDoT) and an extension to identity management that encompasses all entity identities, whatever form those entities take. According to Gartner, IoT is part of the larger digital business trend transforming enterprises. It means that the business, the people/employees and the ‘things’ are all responsible in delivering business value. The critical part is the relationships between or among those participants so the business policies and procedures can reflect those relationships. Those relationships can be between a device and a human; a device and another device; a device and an application or service; or a human and an application or service. For instance, how does the system(s) know that the wearable asking for Wi-Fi access is the one connected to your wrist? It really doesn’t since today’s Identity and Access Management (IAM) systems are typically people-based and unable to scale as more entities enter the workplace. Not to mention the complexity involved with deciding if the urine powered socks the VP is wearing gets access. The number of relationships between people and the various entities/things will grow to an almost unmanageable point. Could anyone manage a subset of the expected 50 billion devices over the next 4 years? And set policies for data sharing permissions? Not without a drastic change to how we identify and integrate these entities. Talk about the Internet of Insider Threats. That's IoIT for those counting. Gartner suggests that incorporating functional characteristics of existing management systems like IT Asset Management (ITAM) and Software Management Systems (SAM) within the IAM framework might aid in developing a single-system view for IoT. The current static approach of IAM doesn’t take into account the dynamic relationships, which is vital to future IAM solutions. Relationships will become as important as the concept of identity is for IAM in the IDoT, according to Gartner. My, your, our identities are unique and have been used to verify you-are-you and based on that, give you access to certain resources, physical or digital. Now our identities are not only intertwined with the things around us but the things themselves also need to verify their identity and the relationship to ours. I can hear the relationship woes of the future: A: ‘I’m in a bad relationship…’ B: ‘Bad!?! I thought you were getting along?’ A: ‘We were until access was denied.’ B: ‘What are you talking about? You guys were laughing and having a great time at dinner last night.’ A: ‘Not my fiancé…it’s my smart-watch, smart-shoes, smart-socks, smart-shirt, smart-pants, smart-belt, smart-glasses, smart-water bottle, smart fitness tracker and smart-backpack.' IT said, 'It’s not you, it’s me.' ps The Identity of Things for the Internet of Things IoT Requires Changes From Identity and Access Management Space: Gartner What is IoT without Identity? IoT: A new frontier for identity Health and Finance Mobile Apps Still Incredibly Insecure Internet of Things 'smart' devices are dumb by design Authentication in the IoT – challenges and opportunities Technorati Tags: iot,things,wearables,iam,insider threat,security,silva,f5,identity,access Connect with Peter: Connect with F5:
Big-IP Access Policy Manager (APM) Identity Federation SAML Documentation
As enterprise customers start to accelerate their cloud Software-as-a-Service (SaaS) deployments their IT staff is observing increased help desk calls and user password fatigue issues. F5’s Big-IP Access Policy Manager (APM) product can address these requirements through its support for SAML 2.0 federation services like Identity Provider (IdP) for popular SaaS services such as Office 365, Salesforce etc. Big-IP APM supports both Service Provider (SP)-initiated and IdP-initiated deployments for identity federation to SaaS services as illustrated below User logs on to the Big-IP APM IdP and is directed to the webtop User selects a Salesforce service from the webtop. Big-IP APM may retrieve attributes from the user data store to pass on to the SaaS service provider. Big-IP APM directs the requests to the SaaS service with the SAML assertion and optional attributes via the user browser. User accesses Salesforce SaaS service. Salesforce redirects the user back to the Big-IP APM SAML IdP with SAML request via the user's browser. Big-IP APM prompts the user to logon with the relevant credentials. At this time Big-IP APM may retrieve attributes from the user data store to pass on with the SaaS service provider (SP). Big-IP APM then sends a SAML response to Salesforce with the authentication information and optional attributes via the user's browser for allowing access to the service. Over the years F5 has been extending its support for identity federation including support for SAML 2.0 OASIS standard features and publishing collateral for administrators to easily deploy Big-IP APM IdP services. Below is a consolidated list of documentation which includes the deployment guides to federate against the following SaaS services Office 365 Salesforce Workday Amazon Web Services Concur Service Now Jive Wombat Zendesk Cisco Webex Box Google Apps The deployment guides mentioned below provide details on setting up the following Big-IP APM objects for above mentioned SaaS applications Profiles, AAA server and Virtual Server IdP Configuration SP Connector Configuration Access Policy Setup using Visual Policy Editor iApps to setup the above configuration is also available in the guide* The deployment guides also have pointers on configuring SaaS SP services based on the SaaS provider documentation. While these deployment guides are provided as a quick reference for configuring the above mentioned SaaS applications, Big-IP APM can be used to setup almost any other SaaS applications that support SAML 2.0 OASIS standard. Deployment Guides Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Common SaaS Applications (For all SaaS applications other than office 365) Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Microsoft Office 365 Please add comments below should you have any feedback for this documentation or need other APM related documentation. * Production version of APM IdP to Office 365 iApp is available in the Office 365 guide. Beta version of iApp for all other SaaS applications is available here (production version will be released soon)Meet the Sensors
I often write about the Internet of Things, or the soon-to-be-cliché IoT. You know, the smart-fridges, smart-cars, smart-thermostats, healthcare devices, wearables and any of those connected devices that have a sensor, gathers data and reports back to some entity. You are able to control these devices (and see the data) with mobile apps or even your own voice and gestures. They are all the rage and sitting at the top of the Gartner Hype Cycle. But it’s all the various sensors inside those devices that are doing the actual measuring, calculating, tracking and reporting. Each has its own specialty providing specific functionality. I’ve always wondered about what’s inside some of the wearables let’s take a look at a few. Have you ever wondered what spins the screen so you’re not looking at an upside down picture? That’s an Accelerometer. It measures orientation and movement. The iPhone was the first to use this back in 2007 and amazement ensued. It can tell the difference between running away from a charging buffalo in Yellowstone verses making faces with a chimp at the zoo. It can also tell if you’re sleeping simply by the fact that you haven’t moved for a while. These are typically used to track step count and how well you’ve rested. I noted that the accelerometer measures step count but what about those steps up a flight of stairs? Well, that would be the Altimeter. Altimeters measure altitude so it can sense changes in height. In conjunction with the steps the accelerometer counted, the altimeter will add its bits and give you a more accurate calorie count for those fire escape runs. Instead of asking how tall someone is, next time ask ‘What’s your alti?’ And if you’re going to step out for a run, you might want to know if it’ll be sunny or sprinkles during the trek. Often seen as a smaller dial on an outdoor clock but now on wristbands, a Barometer measures atmospheric pressure – the weight of air in the Earth’s atmosphere. It’s used in forecasting the weather and you often hear meteorologists note, ‘There’s a high ridge of atmospheric pressure keeping the rain away.’ At least that’s what they’ve been saying in California about the drought. So you thought of attempting an Iron Man competition but wondered if your device could differentiate between the swimming, biking and running. You’re in luck if your device has a Gyroscope. Using the Earth’s gravity, it can help determine orientation. The big difference between an accelerometer and a gyroscope is that a gyroscope can also measure rotation or more specifically, the rate of rotation around a particular axis. Gyroscopes take into account the Earth’s gravity and rotation while the accelerometer does not. If tracking stars for navigation and location like the early Polynesians is not your style, then the ever popular GPS is your tool. Using three satellites to ‘triangulate’ your location, the receiver measures distance to the first satellite. Based on that, you are in a certain sphere location on the planet. It then measures the distance to the second satellite to get another sphere location. Therefore, you must be somewhere on the circle where these two spheres intersect. By using a third satellite reading, the sphere that cuts through the circle of the intersection of the first two spheres narrows your location even more. Now our position is narrowed to two points in space. One of those two points is so absurd and instantly tossed, thus leaving you with an exact location. There are a bunch of other sensors like Optical Heart Rate Monitors, typically worn on the wrist and it shines a tiny light against your skin to measure the blood pumping through your arm veins. And the various Gesture Tech things that use a little camera to see your hand and body movements to translate that into action on a gaming device, or a drone following your Snake River Canyon jump or even turning up the volume on the TV. It’d be cool to move something out of the way by effortlessly swiping your hand in the air, huh? Sensors have been all around us for a while but now they are becoming close confidants. We should get to know our new Ohana. ps Related What do the sensors in wearable tech actually do? The World's First Urine-Powered Wearable Is Here Accelerometer vs. Gyroscope: What's the Difference? Wearables Head to Tail Oh, Is That The Internet You're Wearing? Connecting the Threads Our Five Senses on Sensors Sensors and IoT Technorati Tags: iot,wearables,sensors,humans,silva,f5,mobile Connect with Peter: Connect with F5:Five Information Security New Year's Resolutions
Shot this late last year for Information Security Buzz. What are five information security new year's resolutions for improving cyber security in 2016 and why? ps Related: New Year's Resolutions for the Security Minded Blueprint: 2016 is the Year SDN Finds its Home, and its Name is NFV 10 Cloud Security Predictions for 2016 2016 security predictions: Partnerships, encryption and behavior tracking Technorati Tags: 2016,resolutions,security,infosec,silva,f5 Connect with Peter: Connect with F5:
