The burden of federated authentication

"When it comes to Web access management there is a distinct difference between authentication and authorisation. Authentication is the process of verifying a user's identity while authorisation is the process of determining the level of access the user possesses for any given application and/ or resource," says Alexa Gerber, product manager for F5 solutions throughout Africa at Networks Unlimited, a value-added distributor.

Although the authentication/ authorisation topic has been discussed at length on various forums on the Internet, it is still one that raises confusion when it comes to "federated authentication", an arrangement that can be made among multiple enterprises that lets subscribers use the same identification data to obtain access to the networks of all enterprises in the group.

"In my years as a developer and system administrator it was commonplace 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," says Cody Green, field systems engineer at cyber-security company F5 Networks.

This scenario ultimately led to security issues, such as phishing attacks, because the end-user had too many usernames/ passwords and several application login points. The result was that the user could no longer (or 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 the applications.

"In early 2005 we started to use Shibboleth and Jasig Central Authentication Services (CAS) for federated authentication and single sign-on. Shibboleth and CAS addressed my issues by, for example, reducing the number of username/ password combinations as well as login entry points to only one, and allowed non-employees access to our Web sites without the need to maintain their identity in our authentication database - commonly known as federated authentication," says Green.

Although the paradigm of federated authentication caught on in higher education over a decade ago, it was enterprise environments that were slow to adopt - until now. Points out Green: "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 identity and access management vendor (IAM) has sold them. Too often, I sit in meetings regarding issues a customer is having with their IAM solution because of two issues: the customer did not understand the difference between authentication and authorisation, and the IAM vendor promised that multi-factor authentication capabilities would integrate easily."

When looking at these issues, it could be concluded that federated authentication protocols, like SAML (security assertion mark-up language), have made it easier for users to consume and/or modify data inside Web applications without the need to maintain a local persona of a user. However, Green highlights that 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. "While federated authentication reduces the risk of managing and maintaining a user's persona it does not alleviate the risk of unauthorised access. This is because authentication in a federated world does not imply authorisation," he says.

Ideally, the initial authorisation functionality from a Web application should be removed, maintains Green. This can be achieved by leveraging a web access management (WAM) solution that also operates as an authentication proxy. A WAM is a proxy that controls access to Web applications based upon contextual authentication and provides a least privilege model for authorisation.

"We are seeing a growing adoption of federated authentication in enterprises across our region, but the reliance on identity providers to secure access to applications is too heavy," says Gerber. "Only a handful of identity vendors operating in Africa provide both authentication and Web access management capabilities. The vendors that do not possess WAM functionality leave the authorisation to the application, which is very risky."

Green advocates F5's Access Policy Manager (APM) as his go-to tool to help customers resolve their federated authentication burdens. Adds Gerber: "Networks Unlimited distribute F5's APM tool throughout the continent as it works with every major MFA vendor on the market, which means that a customer can easily add second factor authentication to services such as Office 365 and free solutions such as Google Authenticator."

For more information please contact Alexa Gerber at (+27) 11 202 8400 or alexa.gerber@nu.co.za.