Archive for authentication

Legacy Application SSO with BIG-IP and Okta

Posted in security, f5, big-ip, silva, authentication, kerberos, devcentral, saml, access by psilva on October 10th, 2017

IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way.

Today we’ll take you through BIG-IP APM’s integration with Okta, a cloud-based identity-as-a-service provider.

The primary use case for this scenario is providing the user authentication through Okta and then Okta providing BIG-IP APM a SAML assertion so that BIG-IP can perform legacy SSO using either Kerberos Constrained Delegation (KCD) or Header Authentication. BIG-IP is the Service Provider (SP) in this SAML transaction.

As we log on to a BIG-IP, you’ll see that we have two policies/application examples.

ok1.jpg

Let’s click on the Edit button under Access Policy for app1-saml-sp-okta. This takes us to the Visual Policy Editor (VPE) for the first application. As the chart flows, BIG-IP is consuming the SAML authentication, then storing the SSO credentials and doing a Variable Assign so we know who the user is.

ok2.jpg

The next entry, app3-saml-sp-okta, looks very similar.

ok3.jpg

One of the things that is different however is for Header Authentication, we’re using a Per Request Policy. You can view/configure this by going to Access Policy>Per Request Policy.

ok45.jpg

We click Edit (under Access Policy) and here via the flow, the user enters and on every request, we’re going to remove the Okta header name, which is arbitrary and doesn’t need to be that value – could be any value you choose. But we want to make sure that no one is able to pad that header into a request. So, we’ll remove it and insert the variables BIG-IP receives from Okta. This way the application can consume it and we know who that user is.

ok67.jpg

So, what does it look like.

First, we’ll log into Okta and in the portal, we see two applications – the Header Auth and Kerberos Auth.

ok89.jpg

We’ll test the Header authentication first and see that we’re logged into App1 using Header authentication. Tuser@f5demo.com was the account we logged into with Okta and we see the application has been single-signed into using that credential.

ok9a.jpg

Now let’s hit that Kerberos auth application. Here again, we’ve been SSO’d into the application. You may notice that the user looks a bit different here as F5DEMO user since this time we used Kerberos Constrained Delegation. So, we’ve obtained a Kerberos ticket from the domain controller for F5DEMO as the user to use. So the username can look a little different but it’s mainly about formatting.

ok9b.jpg

BIG-IP is able to consume that SAML assertion from Okta and then use SSO capabilities via Header or Kerberos for legacy applications. Watch Cody Green’s excellent demo of this integration.




Social Login to Enterprise Apps using BIG-IP & OAuth 2.0

Posted in security, f5, big-ip, cloud, silva, authentication, social media, devcentral by psilva on March 14th, 2017

 

social_login_gigya.jpgPassword fatigue is something we’ve all experienced at some point. Whether it’s due to breaches and the ever present, ‘update password’ warnings, the corporate policy of a 90-day rotation or simply registering for a website with yet another unique username and password. Social login or social sign-in allows people to use their existing Google, Twitter, Facebook, LinkedIn or other social credentials to enter a web property, rather than creating a whole new account for the site. These can be used to authenticate, verify identity or to allow posting of content to social networks and the main advantage is convenience and speed.

With v13, BIG-IP APM offers a rich set of OAuth capabilities allowing organizations to implement OAuth Client, OAuth Resource Server and OAuth Authorization Server roles to implement social logins.

Let's look at BIG-IP’s capabilities (from the user's perspective) as an OAuth Client, OAuth Resource Server. We’ll navigate to our BIG-IP login screen and immediately you’ll notice it looks slightly different than your typical APM login.

sl1.jpg

Here, you now have a choice and can authenticate using any one of the 4 external resources. Azure AD Enterprise and AD B2C along with Google and Facebook. Google and Facebook are very popular social login choices - as shown in the initial image above - where organizations are looking to authenticate the users and allow them to authorize the sharing of information that Google and Facebook already have, with the application.

In this case, we have an application behind BIG-IP that is relying on getting such information from an external third party. For this, we’ll select Facebook. When we click logon, BIG-IP will redirect to the Facebook log into screen.

sl23.jpg

Now we’ll need to log into Facebook using our own personal information. And with that, Facebook has authenticated us and has sent BIG-IP critical info like name, email and other parameters.

sl4.jpg

BIG-IP has accepted the OAuth token passed to it from Facebook, extracted the info from the OAuth scope and now the application knows my identity and what resources I’m authorized to access.

We can do the same with Google. Select the option, click logon and here we’re redirected to the Google authentication page. Here again, we enter our personal credentials and arrive at the same work top.

sl564.jpg

Like Facebook, Google sent an authorization code to BIG-IP, BIG-IP validated it, extracted the username from the OAuth scope, passed it to the backend application so the application knows who I am and what I can access.

Let's look at Microsoft. For Microsoft, we can authenticate using a couple editions of Azure AD – Enterprise and B2C. Let’s see how Enterprise works. Like the others, we get redirected to Microsoftonline.com to enter our MS Enterprise credentials.

In this instance, we’re using an account that’s been Federated to Azure AD from another BIG-IP and we’ll authenticate to that BIG-IP. At this point that BIG-IP will issue a SAML assertion to Azure AD to authenticate me to Azure AD. After that, Azure AD will issue an OAuth token to that BIG-IP. BIG-IP will accept it, extract the user information and pass it to the application.

sl7894.jpg

Finally, let’s see how Azure AD B2C works. B2C is something that companies can use to store their non-corporate user base. Folks like partners, suppliers, contractors, etc. B2C allows users to maintain their own accounts and personal information. In addition, they can login using a typical Microsoft account or a Google account. In this case, we’ll simply use a Microsoft account and are directed to the Microsoft authentication page.

slb2c_all.jpg

We’ll enter our personal info, the servers communicate and we’re dropped into our WebTop of resources.

Social logins can not only help enterprises offer access to certain resources, it also improves the overall customer experience with speed and convenience and allows organizations to capture essential information about their online customers.

ps

Related:

 




Shared Authentication Domains on BIG-IP APM

Posted in security, f5, big-ip, application delivery, authentication, AAA, devcentral, access by psilva on February 14th, 2017

How to share an APM session across multiple access profiles.

A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once.

By default, BIG-IP APM requires authentication for each access profile.

domain_value.jpg

 

This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu.

Let’s walk through how to configure App1 and App2 to only require authentication once.

We’ll start with App1’s Access Profile.

dv1.jpg

 

Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains.

dv2.jpg

 

We’re prompted for authentication and enter our credentials and luckily, we have a successful login.

dv4.jpg

 

And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts.

dv5.jpg

Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here.

ps

 

 

 

 

 

 

 

 

 

 




Lightboard Lessons: SSO to Legacy Web Applications

IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way.

In this Lightboard Lesson, I draw out how VMware and F5 helps remove these complexities and enable productive, any-device app access. By enabling secure SSO to Kerberos constrained delegation (KCD) and header-based authentication apps, VMware Workspace ONE and F5 BIG-IP APM help workers securely access all the apps they need—mobile, cloud and legacy—on any device anywhere.

 

 

Watch Now:



Lock Down Your Login

Posted in Uncategorized, security, f5, big-ip, application security, silva, authentication, banking, malware, devcentral by psilva on September 27th, 2016

login.png

Last week we talked about WebSafe and how it can help protect against phishing attacks with a little piece of code. This is important since malware can steal credentials from every visited web application from an infected machine. This time we’re going to look at how to protect against credential grabbing on a BIG-IP APM login page with WebSafe encryption layer.

You’ll needtwo modules for this, BIG-IP APM andof course, WebSafe FraudProtection Service. The goal is to protect the laptop from any malware thatgrabs sensitive login credentials. In this case, the malware would beconfigured to grab the login page along with the username and passwordparameter fields. Command and control could also be set to retrieve anycredentials from the infected machine at certain intervals, like every 5minutes.

The first goal would be to encrypt the password. Within your BIG-IP admin GUI, you would navigate to Security>Fraud Protection Service> Anti-Fraud Profiles>URL List. APM’s logon page usually ends with ‘/my.policy’.

mfraudurl.jpg

Create then click that URL to open the configuration page and enable Application Layer Encryption.

mapplayerencrypt.jpg

And select the Parameters tab to configure the fields you want to protect. In this case it is password and username.

mparameters.jpg

In the screen grab, you can see ‘Obfuscate’ is selected and to both ‘Encrypt’ and‘Substitute Value’ for the password field.

Now when the user goes to the page, a bit a JavaScript is injected in the page to protect the specified fields. If you run a httpwatch or wire shark on the page, you’ll see that the values for those parameters are obfuscated. This makes it incredibly difficult for the bad actor to determine the correct value.

mobfuscape.jpg

And if the malware also grabs the password, since we set that to encrypt, all they get is useless information.

mpwuseless.jpg

At this point, the BIG-IP will decrypt the password and pass on the traffic to appropriate domain controller for verification. This is a great way to protect your login credentials with BIG-IP. If you’d like to see a demonstration of this, check out F5’s Security Specialist Matthieu Dierick’s demo video. Pretty cool.

ps




Time It Takes the Fingers to Remember a New Password? About 3 days

Posted in security, silva, authentication, cybercrime, identity theft, human behavior, access by psilva on March 18th, 2016

unpw.jpg

Recently I changed some of my passwords. Some due to typical rotation time and a couple due to potential breaches and encouragement from the affected site. No, I’m not going to tell you which ones or how I go about it but I noticed that it took about 3 days for my fingers to key the correct combination.

This has probably happened to you too, where after changing a password, you inadvertently enter the old password a number of times since that is what the fingers and hands remember. Yes, I’m sure many of you have password keepers (which have also been breached) locked by a master and I use one too, but for many of my highly sensitive passwords, I keep those in my head.

As I continued to enter the old password for a couple days only to correct myself, I started thinking about habits and muscle memory. Some adages talk about it taking about 30 days (66 days in this study) to either pick up or drop a habit if done daily. Want to keep an exercise routine? Do it daily for a month and you are more than likely to continue...barring any unforeseen circumstances.

And then there’s muscle memory. Things like riding a bike, signing your name, catching a ball or any repetitious, manual activity that you complete often. Your muscles already know how to do it since they’ve been trained over time. You do not need to think about, ‘OK, as it gets closer, bring your hands together to snag it from the air,’ it just happens. This is one of the reasons why people change or update certain exercise or resistance routines – the muscles get used to it and need a different approach to reach the next plateau.

I wondered if anyone else had thought of this and a quick search proved that it is a bona fide technique for password memory. Artists like musicians use repetitive practice for scale patterns, chords, and melodic riffs and this trains the muscles in the fingers to 'remember' those patterns. It is the same notion with passwords. Choose a password that alternates between left and right hands that have some rhythm to it. After a bit, the hands remember the cadence on the keyboard and you really do not need to remember the random, committed numbers, letters or Shift keys pounced while typing your secret. This is ideal since only your fingers remember not necessarily your mind.

Granted, depending on how your head works this technique might not work for everyone but it is still an interesting way to secure your secrets. And you can brag, 'If you break my fingers, it'll wipe the device.'

ps

Related:




Internet 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?

ciscoiot.png

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

Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]



Ask the Expert – Why Identity and Access Management?

Posted in security, f5, big-ip, cloud computing, silva, video, authentication, AAA by psilva on November 4th, 2015

Michael Koyfman, Sr. Global Security Solution Architect, shares the access challenges organizations face when deploying SaaS cloud applications. Syncing data stores to the cloud can be risky so organizations need to utilize their local directories and assert the user identity to the cloud. SAML is a standardized way of asserting trust and Michael explains how BIG-IP can act either as an identity provider or a service provider so users can securely access their workplace tools. Integration is key to solve common problems for successful and secure deployments.

ps

Related:

Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]
Watch Now:



RSA2015 Partner Spotlight - RSA Risk Based Authentication

Posted in security, f5, silva, authentication, rsa, access by psilva on April 21st, 2015

RSA Technology Consultant Josh Waterloo talks about the evolution of two-factor authentication and how risk based auth is starting to take hold. He also shows us a demo of the integration between RSA SecurID and BIG-IP APM to provide risk based, strong authentication for corporate access to sensitive information.

ps

Related

Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]
Watch Now:



The Weekend of Discontent

This past weekend, like many of you, I started getting the blood curdling password resets from a bunch of OpenSSL affected sites. I also got a few emails from sites indicating that I had nothing to worry about. Bad news, good news. Probably the biggest security story thus far for 2014 is Heartbleed, the OpenSSL vulnerability which potentially allows attackers to extract 64 kilobyte batches of memory at random without being noticed and leaving no trace. Sounds like the perfect crime.

It also got me thinking.

First, I wondered if this was a new era of security by force. The vulnerability and the totality of the hole forced many of us to change passwords on many sites. What a pain. It was a huge reminder that no matter how many 'experts' urge regular password rotation, it is a real time consuming, frustrating task. It's no wonder that so many keep the same password for years or use the same password across multiple sites. With so many sites requiring some authentication or verification for either resources or customization, people can have hundreds username/password combinations. Sure there are password keepers but part of me is reluctant to put all my web identities with one entity. What if that gets hit? There are just some sites that I chose not to save and auto-fill but enter it every time. Then, of course, I'm susceptible to key loggers. Great.

Then there are the developers. I imagine that this past weekend was the most worked ever by the entire coding community. Administrators across many sectors were working to patch vulnerable systems all over the globe to reduce the security threat. A massive undertaking to help fix over two-thirds of the internet. The weekend work of many fingers plugging dikes was probably only surpassed by the marketers and PR folks maneuvering their stories around what it is, what's at risk, what you should do and other FAQs surrounding this security superstar. @LanceUlanoff speculated on twitter, 'Is Heartbleed the first Internet bug with its own Web site? http://t.co/M9u976X9ui'

With so many sites and so many people affected along with the massive media coverage, will things change? Or will this be like Y2K with a bunch of dire warnings only to have nothing major occur? Is this a wake up call or will it dissolve into yesterday's news as new 'breaking' stories grab our attention? I think (and hope) that this is so critical that many organizations will be taking a more detailed look at their security infrastructure even if they are not vulnerable to Heartbleed. It forces many, if not all internet users, including the administrators themselves, to take a look at how we are protecting ourselves. It'll be interesting to see if '12345678' or 'qwertyui' or even 'password' continues to be the most popular pass codes after this massive reset.

If you need assistance with your Heartbleed crisis, click here to learn how F5 can help.

ps

Related

 

Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]




« Older episodes ·