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.




Lightboard Lessons: Connecting Cars with BIG-IP

Posted in f5, big-ip, availability, cloud computing, silva, video, lightboard, control, devcentral, mqtt, connected cars by psilva on October 4th, 2017

I light up how BIG-IP and Solace work together in a MQTT connected car infrastructure.

 

 

 

Watch Now:



DevCentral’s Featured Member for October – Jad Tabbara

Posted in security, f5, big-ip, devcentral, featured member by psilva on October 3rd, 2017

Technical Articles | F5 DevCentral

 




Add a Data Collection Device to your BIG-IQ Cluster

Posted in f5, big-ip, silva, application delivery, management, devcentral, big-iq by psilva on September 26th, 2017

big-iq-200-5000.pngGathering and analyzing data helps organizations make intelligent decisions about their IT infrastructure. You may need a data collection device (DCD) to collect BIG-IP data so you can manage that device with BIG-IQ. BIG-IQ is a platform that manages your devices and the services they deliver. Let’s look at how to discover and add a data collection device in BIG-IQ v5.2. You can add a new data collection device to your BIG-IQ cluster so that you can start managing it using the BIG-IP device data.

In addition to Event and Alert Log data, you can view and manage statistical data for your devices. From licensing to policies, traffic to security, you’ll see it all from a single pane of glass.

But you need a DCD to do that.

So, we start by logging in to a BIG-IQ.

iq1.jpg

Then, under the System tab, go to BIG-IQ Data Collection and under that, click BIG-IQ Data Collection Devices.

iq2.jpg

The current DCD screen shows no devices in this cluster. To add a DCD, click Add.

iq3.jpg

This brings us to the DCD Properties screen. For Management Address field, we add the management IP address of the BIG-IP/DCD we want to manage. We’ll then add the Admin username and password for the device. For Data Collection IP Address, we put the transport address which is usually the internal Self-IP address of the DCD and click Add.

iq4.jpg

The process can take a little while as the BIG-IQ authenticates with the BIG-IQ DCD and adds it to the BIG-IQ configuration. But once complete, you can see the devices has been added successfully.

iq6.jpg

Now you’ll notice that the DCD has been added but there are no Services at this point. To add Services, click Add Services.

iq7.jpg

In this instance, we’re managing a BIG-IP with multiple services including Access Policies so we’re going to activate the Access services. The listener address already has the management address of the DCD populated so we’ll simply click Activate. Once activated, you can see that it is Active.

iq89.jpg

When we go back to the Data Collection Devices page, we can see that the Access Services have been added and the activation worked.

iq9a.jpg

Congrats! You’ve added a Data Collection Device! You can also watch a video demo of How to Add a data collection device to your BIG-IQ cluster.

ps




Lightboard Lessons: What is HTTP?

Posted in f5, big-ip, application delivery, lightboard, http, devcentral by psilva on September 20th, 2017

In this Lightboard Lesson, I light up some #basics about HTTP. HTTP defines the structure of messages between web components such as browser or command line clients, servers like Apache or Nginx, and proxies like the BIG-IP.

 

 

Watch Now:



Automatically Update your BIG-IP Pool Using the Service Discovery iApp

Posted in f5, big-ip, cloud computing, iApps, aws, azure by psilva on September 12th, 2017

Let’s look at how to automatically add members to your BIG-IP pool by using the Service Discovery iApp. Whenever you deploy a BIG-IP Virtual Edition by using one of the templates on the F5 Github site, this iApp is installed on the BIG-IP.

The idea behind this iApp is you assign a tag to a virtual machine in the cloud and then BIG-IP automatically discovers it and adds it to the pool. By tagging instances in AWS and Azure, and configuring the iApp, the pool is updated based on an interval you specify. This is especially helpful if you auto-scale your application servers because they are then automatically added and removed.

sdi1.jpg

Today, we’ll look how to do this in Azure but you can also do this in AWS.

First, we’re going to add a tag to the application sever in Azure. You can assign the tag to either the virtual machine or to the NIC. For auto-scaling you’d tag the scale set. This can we’ll simply add it to the virtual machine.

sdi2.jpg

When you click through the virtual machine, on the left you’ll get the ‘Tags’ option.

sdi3.jpg

This entry can be any name/value pair you want and for this we’ll use ‘mytag’ and ‘addme.’

sdi4.jpg

And we’ll click Save.

sdi5.jpg

For this exercise, we have two application servers in the resource group and already added the tags for that one. So at this point, we’re ready to get into the BIG-IP and configure the iApp.

Once in, go to Application Services>Applications>Create.

sdi6.jpg

Next, we give it a name and choose f5_service_discovery from the list.

sdi7.jpg

Scroll down the same page and fill out the open fields. Under Cloud Provider, we select Azure. Depending on your provider, there are additional questions. Add the Azure resource group and the Subscription ID. The next 3 fields (for the Azure selection) are security related: Tenant ID, Client ID and Service Principal Secret. Rather than using your own credentials to create and modify resources in Azure, you can create an Azure Active Directory application and assign permissions to that. Details are included on the Github ReadMe or the Azure documentation about service Principal.

Under the Pool area, is where you enter the name/value pair that we used for the tags in Azure. We leave the rest default. In this instance, you may notice the update interval at 60 seconds. By default, 60 seconds is the interval that BIG-IP will query Azure to see if there is a resource with the tags you specified. Under Application Health, select ‘http’ as the health monitor. Click Finished.

sdi8.jpg

When complete, we can see we got a pool with two active members in it.

sdi9.jpg

If you take the tags off one of the instances, it’ll leave the pool. Of note however, there must be two members in the pool before you remove tags from an instance. If you remove the tags from all the application servers, the pool will not be updated. BIG-IP must see at least one set of tags to update the pool because it doesn’t want to leave you with an empty pool.

Here’s the before and after of removing a tag.

sdi9ab.jpg

One final note. This example configuration has the BIG-IP in one resource group and the application servers in another resource group but they are all on the same Vnet. If you have separate networks in Azure, you’ll need to create a peering so they can communicate. Similarly, in AWS, you need to make sure the networking is set up so the BIG-IP can see the application servers. But, once the initial set up is working, there’s no manual intervention required.

You can use the Service Discovery method to add and remove application servers all day long without having to manually update the BIG-IP. Again, and as always, thanks to our Technical Communications team for the great material and watch the video demo here.

ps

Related:




DevCentral’s Featured Member for September – Rob Carr

Posted in f5, big-ip, devcentral by psilva on September 11th, 2017

robcarr.jpgRob Carr is a Senior Trainer/Professional Services Consultant with Red Education Pty in Australia, covering the Oceania and Asia markets. He has done training and engagements from New Zealand to Taiwan and points in between. About 60% of his time is running F5 courses, ranging from the from the introductory Admin course through the high-level courses like AFM, ASM or iRules. He enjoys the mix of work, where teaching allows him to be social and PS work lets him delve into the technical nitty-gritty. Rob is also DevCentral's Featured Member for September!

DevCentral: You were an F5er (ProServ Consultant) from 2013-15 and continue to be a very active contributor in the DevCentral community since then. What keeps you involved?

Rob: Long before I did PS Consulting for F5, I worked for F5 in Seattle, first as a Network Support Engineer and then as Software Test Engineer, and I always found DC to be extremely useful. While F5 puts considerable energy into its product documentation and knowledge base articles, there are times when you need an ‘outside’ perspective to really understand what a feature is and how to use it. I always exhort my students to use DC as a resource, and not just for iRules.

I stay active because I use the site to answer my own questions and because I appreciate it when someone knowledgeable contributes a write-up or a really solid comment. I try and give back by commenting when the subject of a question is one in which I have experience.

DC: Tell us a little about the areas of BIG-IP expertise you have.

RC: I’ve been working with BIG-IP since 2005, when there were only two products, BIG-IP and 3DNS (FirePass joined F5 a few months after I did), and those two (well, the current iterations of LTM and DNS) are my strongest products. I’ve also worked with BIG-IP ASM, APM and AFM over my career. Today, I’m most comfortable with BIG-IP ASM and general Application Delivery more generally at this point.

DC: You are a Consultant & Trainer at Red Education. Can you describe your typical workday?

RC: If I’m training then I try to be onsite about an hour before the students. I need the time to setup the room, settle my thoughts and flip through the material we need to cover that day. Generally, training is a nine-to-five experience, although that can be modified by where the training is being done – in some countries, courses start later, then run into the early evening. Regardless of the specific hours, my tasks for the day are pretty much the same: cover the material, answer student questions and redirect where needed, proctor the labs and troubleshoot course and student issues. It’s almost like being on stage for an eight-hour show.

reded.jpgConsulting, on the other hand, is generally quite a bit more solitary. I do most of my work remotely, so once I’ve met with the client and we’ve had our kickoff activities, I’m back in Melbourne working from my home office. It’s not unusual to have a conference call once a day with the customer and technical staff and there is always email communication about the design and documentation tasks.

In the background, there is always communication with the constellation of trainers and consultants that I work with, sharing ideas, running questions past one another or bantering.

DC: You have a number of F5 Certifications including most of the Technology Specialist (LTM, GTM, APM, ASM) certifications. Why are these important to you and how have they helped with your career?

RC: I have all the F5 Certifications at this point, including the 401 Security Solution Expert exam and I suppose I’m a bit proud of that fact. I think F5’s certification exams are pretty good at covering what you need to know to be successful working on F5 systems in the enterprise, certainly more so than some of the other vendor exams.

In Australia, engagements often come with a requirement that you have certification for the product or products, so in that sense having the certifications has been good for my career. More generally, having the certifications has given me more confidence in representing my skills to prospective clients.

DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.

RC: Recently, I was on an engagement where the customer was migrating internal architectures for some highly fragmented legacy applications, as part of a PCI compliance project. We needed to replace many mod_proxy implementations and to mitigate application issues that came up during this transition, all on a short timeline. We ended up using multiple iRules with each service, providing routing and forwarding and fixing issues like improperly set cookie attributes. iRules is such a powerful and flexible solution that in the near term, given our timeline, it was the best and fastest way to manage the application issues.

DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

RC: I’ve always enjoyed gardening and I’m fond of zoos and animal parks, so if I wasn’t working in IT, I think I would like to be a gardener at the zoo.

Thanks Rob! Check out all of Rob's DevCentral contributions, connect with him on LinkedIn and visit Red Education.

 




Lightboard Lessons: What is BIG-IQ?

Posted in f5, big-ip, lightboard, devcentral, big-iq by psilva on August 31st, 2017

In this Lightboard Lesson, I light up many of the tasks you can do with BIG-IQ, BIG-IQ centralizes management, licensing, monitoring, and analytics for your dispersed BIG-IP infrastructure. If you have more than a few F5 BIG-IP's within your organization, managing devices as separate entities will become an administrative bottleneck and slow application deployments.  Deploying cloud applications, you're potentially managing thousands of systems and having to deal with traditionally monolithic administrative functions is a simple no-go. 

Enter BIG-IQ.

ps

Related:

 

 

 

Watch Now:



Is 2017 Half Empty or Half Full?

Posted in big-ip, availability, cloud, application delivery, mobile, cybercrime, breach, dns, iot, 2017 by psilva on August 30th, 2017

Ransomware seems to be this year’s huge trend

aug17.jpgWith 2017 crossing the half way point, let's look at some technology trends thus far.

Breaches: Many personal records are half empty due to the continued rash of intrusions while the crooks are half full of our personal information along with some ransom payments. According to the Identity Theft Resource Center (ITRC), there have been 7,689 breaches since 2005 (when they started tracking) compromising – get this – 900,315,392 records. Almost 3 times the U.S. population. In 2016, 56% of all Data Breaches began with a user clicking on a phishing email. The big story for 2017 I think, is the rise of ransomware. Kaspersky reports a 250% increase in ransomware for the first few months of 2017. From WannaCry to Petya to Fusob, criminals are holding systems hostage until a ransom is paid…or not. Ransomware seems to be this year’s big trend with backups saving some from total embarrassment.

Cloud Computing: RightScale 2017 State of the Cloud Report notes that Hybrid Cloud Is the preferred enterprise strategy, with 85 percent of enterprises have a multi-cloud strategy (up from 82 percent in 2016) and Cloud Users Are Running Applications in Multiple Clouds. An interesting stat from the report says, cloud users are running applications in an average of 1.8 public clouds and 2.3 private clouds. We got hybrid cars, hybrid corn, hybrid cats and hybrid clouds but The Cloud is Still just a Datacenter Somewhere so no need to freak out. Cloud seems to be more than half full as the security and expertise challenges decline.

DNS: I’ve said it before and I’ll say it again, DNS is one of the most important components of a functioning internet. With that, it presents unique challenges to organizations. 2016 saw record-breaking DNS-based attacks and outages, which thrust DNS management into the spotlight as both a vulnerability and a critical asset. In 2016 DNS provider Dyn experienced a huge DDoS attack taking out many popular websites and internet cameras. And a new attack uncovered this year, DNSMessenger, uses DNS queries to conduct malicious PowerShell commands on compromised computers – a technique that makes the remote access trojan difficult to detect on targeted systems. The need for DNS continues to be half-full with the influx of IoT devices so it’ll continue to be a valuable target for riff-raff.

IoT: What can I say? The cup runneth over…again. Gartner has identified the Top 10 IoT technologies that should be on every organization's radar for 2017 and 2018. They include things like new security risks and challenges to the IoT devices themselves, their platforms and operating systems, their communications, and even the systems to which they're connected. Analytics to understand customer behavior, to deliver services and improve products. Device management, device processors, operating systems, platforms, standards and even the networks IoT devices use are all areas of attention. IoT is really three-quarters full both with the opportunities and potential risks. And the risks can be deadly when monitoring vital information like human vital signs.

Mobile: We are mobile, our devices are mobile and the applications we access are mobile. Mobility, in all its iterations, is a huge enabler and concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. 5G is still a couple years away but AT&T and Verizon have already lined up trials of their 5G networks for 2017. Mobile is certainly half full and there is no emptying it now.

That's what I got so far and I'm sure 2017's second half will bring more amazement, questions and wonders. We'll do our year-end reviews and predictions for 2018 as we all lament, where did the Year of the Rooster go?

There's that old notion that if you see a glass half full, you're an optimist and if you see it half empty you are a pessimist. I think you need to understand what state the glass itself was before the question. Was it empty and filled half way or was it full and poured out? There's your answer!

ps

This article originally appeared on F5.com.

 

 

 




Deploy an Auto-Scaled BIG-IP VE WAF in AWS

Posted in security, f5, big-ip, application security, cloud, privacy, waf, aws by psilva on August 29th, 2017

Today let’s look at how to create and deploy an auto-scaled BIG-IP Virtual Edition Web Application Firewall by using a Cloud Formation Template (CFT) in AWS. CFTs are simply a quick way to spin up solutions that otherwise, you may have to create manually. The idea behind this CFT is it is going to create BIG-IP VE instances for you. These instances function as a firewall in front of your application. Depending on the limits you specify, when more traffic is going to your application, new instances will launch…and when there is less traffic, instances will terminate.

awaf1.jpg

This solution has a few prerequisites:

  • A Virtual Private Cloud (VPC) with at least two subnets, each in its own availability zone
  • An AWS Elastic Load Balancer (ELB), which serves traffic to the BIG-IP VE instances
  • An SSH key pair which you need to access the instances.

I have these already created, so we’ll proceed to deploying the template.

You have two choices on how you want to deploy. You can go to the AWS Marketplace and search ‘f5 waf’ or you can go to the F5 Networks GitHub site. GitHub usually has the latest and greatest, so we’ll use that.

Click on the f5-aws-cloudformation spot.

awaf2.jpg

And then click Supported.

awaf3.jpg

And then click solutions/autoscale.

awaf4.jpg

Then waf.

awaf5.jpg

We scroll down a little bit and click Launch Stack.

awaf6.jpg

We click Next at the Select Template screen and fill out the template.

awaf7.jpg

When you get to the template, the Deployment Name will be appended to all the instances so you can tell which ones are yours. Since we already set up a VPC with two subnets in two zones (not regions), we’ll select those in the VPC ID field. The Restricted Source Address is available if you only want to allow specific IP addresses to your BIG-IP VE instances.

awaf8.jpg

Next is the AWS Elastic Load Balancer name, then choose your SSH key – which is needed to connect to the instances. And we’ll leave the defaults for the rest.

awaf9.jpg

Then you’ll get to the Auto Scaling Configuration section which is where you’ll determine when to create the new WAF instances. You’ll want to configure the Scale Up & Scale Down Bytes Threshold which will, obviously, determine when one gets launched/added and when it is removed.

awaf9a.jpg

Under WAF Virtual Service Configuration, is where you’ll enter the application’s Service Port and DNS. In addition, if you wanted to automatically add application servers to the pool to have traffic will go to those without having to manually configure the BIG-IP, you can also add the Application Pool Tag Values which works great. Next choose your WAF Policy Level (low, medium, high) and click Next and Next.

awaf9b.jpg

Also, click the check box with indicates that you have the appropriate credentials to set some IAM roles and create a S3 Bucket. Click Create and the CFT will start creating resources.

awaf9c.jpg

This process can take about 15 minutes to complete and when it is done, you’ll get the CREATE_COMPLETE on your dashboard. The resources might be available right away but it is recommended to wait at least 30 minutes before digging into things.

awaf9d.jpg

To see what the CFT created and confirm completion, go to: Services>EC2>Auto Scaling Groups. You can see that there is a BIG-IP VE instance created and added to the group. Also, be aware that the default for Scaling Policies is to wait 40 minutes to launch a new instance. You may want to adjust that to your preference. However, to be clear, AWS is always monitoring the traffic and want to know if you are exceeding the limits you’ve set. The Scaling Policies setting simply means that after one instance is launched – you hit the limit and one is up – AWS should wait 40 minutes (or whatever your value is) to launch another. It’ll keep going until you’ve hit the max number of instances specified. We put three.

awaf9e.jpg

While in Services>EC2, you can also inspect the ELB and see that the BIG-IP VE instance is there and in service. Traffic is going through the Load Balancer and then to the BIG-IP VE, then to the application server.

awaf9f.jpg

Lastly, let’s look at the list of instances in Services>EC2>Instances and the instances are there and ready to go!

awaf9g.jpg

And then when there is too much traffic, another is added. Since the limit was exceeded, AWS has launched new instances, up to three.

awaf9h.jpg

And when the traffic falls, the instance shuts down.

awaf9i.jpg

That’s it! Easily scale your BIG-IP application security on AWS. Thanks to our TechPubs group and watch the video demo here.

ps

 





« Older episodes · Newer episodes »