The Burden of Federated Authentication
If you’ve ever had the pleasure to hear me rant on web access management then you know I like to stress the difference between authentication and authorization. Authentication is the process of verifying a user’s identity while authorization is the process of determining the level of access the user possesses for any given application and/or resource; one does not imply the other. So why bring up a topic that has been discussed to death in many forums around the Internet? Federated authentication… In my years as a developer and sys admin it was common place to either write or include a publicly available authentication framework and based upon group membership allow or disallow access to certain application functionality. These frameworks made it easy to quickly deploy applications without the need to “recreate the wheel” over and over again. However, what we gained in deployment speed we lost in code maintenance and software patching over time. This ultimately lead to security issues, such as phishing attacks, because the end-user had: too many usernames/passwords too many application login points Ultimately the user could no longer, well didn’t care to, keep track of these and resorted to less secure mechanisms for storing passwords as well as entering their extensive list of passwords on any site that resembled one of our applications. So in early 2005 we started to use Shibboleth and Jasig Central Authentication Services (CAS) for federated authentication and single sing-on. Shibboleth and CAS addressed my issues by: reducing the number of username/password combinations as well as login entry points to 1 allowed non-employees access to our websites without the need to maintain their identity in our authentication database - commonly know as federated authentication While the paradigm of federated authentication caught on in higher education over a decade ago enterprise environments were slow to adopt until now. With the explosion of Software-as-a-Service offerings, such as Salesforce and Office 365, enterprises are quickly deploying federated authentication services with little to no understanding of what the snake oil, or IAM, vendor has sold them. Too often, I sit in meetings regarding issues a customer is having with their IAM solution because of two issues: Customer did not understand the difference between authentication and authorization IAM vendor promised that multi-factor authentication capabilities would integration easily with . So lets take a look at these issues. Federated authentication protocols, like SAML, have made it easier for users to consume and/or modify data inside web applications without the need to maintain a local persona of that user. Now from an application perspective this feature might have marginal gain but from a security perspective it allows you to eliminate a substantial amount of risk. The concern I stress to my customers is that while federated authentication reduces the risk of managing and maintaining that user's persona it does not alleviate the risk of unauthorized access. This is because authentication in a federated world does not imply authorization. So what are the challenges of this in a federated application? Lets assume we have a user Alice accessing App1. First, App1 has the responsibility of consuming Alice’s authentication assertion, sent by the SAML IdP, as well as authorizing that Alice has access to the application. From a security point of view this can be very dangerous. What if Alice's credentials were stollen and the malicious actor now has access to sensitive information. What if App1 has not been patched in several years, which never happens in the real world, and is vulnerable to authentication and/or authorization attacks. Ideally we want to remove the initial authorization functionality from the web application like we have done for authentication. This can be achieved by leveraging a web access management solution that also operates as an authentication proxy.So what is web access management (WAM)? It's a proxy that controls access to web applications based upon contextual authentication and provides a least privilege model for authorization. So back to our concern: What if Alice's credentials are compromised? The WAM can look at the full content of Alice's connection and request to App1. If the WAM notices something out of the ordinary, say Alice normally access App1 from within the USA but this request is coming from China, then the WAM could request that the IdP perform multi-factor authentication. What if App1 may have known vulnerabilities and exploits? The WAM only allows authenticated and authorized users access to App1 so we can reduce our threat vectors; typical in this use case we would combine a web authentication management and web application firewall together to fully alleviate this risk. Okay, so if your still reading then what is my point - that with the growing adoption of federated authentication in enterprises we are relying too heavily upon identity providers to secure access to our applications. Only a handful of Identity vendors on the market provide both authentication and web access management capabilities. The vendors that do not posses WAM functionality leave the authorization to the application, which in our current security landscape can be a risky bet. Now, unless you’ve been under a rock for the past 5 years you know I’m a big advocate of F5’s Access Policy Manager. APM is the tool I use over and over again to help my customers resolve their federated authentication burdens. Oh, and did I mention APM works with every major MFA vendor on the market! So you can easily add 2nd factor authentication to services such as Office 365 - even free solutions like Google Authenticator.
tacacs attibute value pair settings for remote role attributes
Hi, I've read Sol8811 and sol8808 and articles https://devcentral.f5.com/articles/v10-remote-authorization-via-tacacs-43.U0yHO_mulsE http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_mgmt_auth.html1030640 on ACS 4.2 - i got auth working via the following: create a 'new service' on the Interface Configuration>Tacacs+(Cisco IOS)>New Services. I created a new service called 'F5_extras' with protocol 'IP'. This enables the new setting to appear in my existing Group (which contains many different vendor equipment). In the Group setting I can assign PPP IP via 'custom attributes' window: service=PPP protocol=IP Obviously set your F5_extras in your LTM tacacs configuration. (NOTE: ip assignment of dialup was not required for me - its mentioned a in a forum). For REMOTE ROLES how to I configure the ACS for the attributes? eg, mentioned on the dev central forum a user applied these attributes to the ACS device: F5-LTM-Host=4500ltm1 F5-LTM-User-Role=administrator F5-LTM-User-Partition=Common F5-LTM-User-Console=tmsh From Cisco site the Attribute values eg's are: eg's •acl= •autocmd= •callback-line •callback-rotary •cmd-arg= •cmd= http://www.cisco.com/c/en/us/td/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4-2-1/User_Guide/acs421ug/A_TACAtr.htmlwp977782
BIG-IP : iControl API failure to retrieve system configuration file
BIG-IP 11.4.1 Build 635.0 Hotfix HF2 We have a C service that on a schedule performs a "health ping" of our BIG-IP devices by calling iControl API to retrieve the system configuration file : SystemConfigSync.download_file("/config/bigip.conf", ... ) If exception is thrown (or blank config retrieved), the service will trigger an alert. Once a subsequent retrieve sys config succeeds, the alert is cancelled. This service has been operational in production for over one year -- with no alerts. However, over the past 4 days we've seen alerts firing frequently. Day 1 was the peak of a period of extraordinary site traffic that placed record load on our devices, however the peak dropped off drastically near end of day 1 and days 2,3,4 were normal traffic. Logs reveal three distinct types of errors : ERROR : SystemConfigSync.download_file() threw exception [Client found response content type of 'text/html; charset=iso-8859-1', but expected 'text/xml'.] ERROR : SystemConfigSync.download_file() threw exception [The underlying connection was closed: An unexpected error occurred on a receive.] ERROR : SystemConfigSync.download_file() threw exception [The request failed with HTTP status 401: F5 Authorization Required.] The text/html errors are by far the most common, followed by connection-closed : both of these types of errors are ongoing. The auth errors occurred infrequently over the initial two days and then stopped completely. What are some possible BIG-IP factors that could be contributing to iControl API failures to retrieve sys config file ? Could it be load related ( even though that doesn't match-up with day 2,3,4 ) ? Are there any config settings that could be contributing ? Also, what determines the text format returned by SystemConfigSync.download_file() ?