The Consolidation of point devices and services in your datacenter or cloud can help with cost, complexity, efficiency, management, provisioning and troubleshooting your infrastructure and systems.
In this Lightboard Lesson, I light up many of the services you can consolidate on BIG-IP.
ps
Wednesday, March 29, 2017
Tuesday, March 28, 2017
What is a Proxy?
The term ‘Proxy’ is a contraction that comes from the middle English word procuracy, a legal term meaning to act on behalf of another. You may have heard of a proxy vote. Where you submit your choice and someone else votes the ballot on your behalf.
In networking and web traffic, a proxy is a device or server that acts on behalf of other devices. It sits between two entities and performs a service. Proxies are hardware or software solutions that sit between the client and the server and does something to requests and sometimes responses.
The first kind of proxy we’ll discuss is a half proxy. With a Half-Proxy, a client will connect to the proxy and the proxy will establish the session with the servers. The proxy will then respond back to the client with the information. After that initial connection is set up, the rest of the traffic with go right through the proxy to the back-end resources. The proxy may do things like L4 port switching, routing or NAT’ing but at this point it is not doing anything intelligent other than passing traffic.
Basically, the half-proxy sets up a call and then the client and server does their thing. Half-proxies are also good for Direct Server Return (DSR). For protocols like streaming protocols, you’ll have the initial set up but instead of going through the proxy for the rest of the connections, the server will bypass the proxy and go straight to the client. This is so you don’t waste resources on the proxy for something that can be done directly server to client.
A Full Proxy on the other hand, handles all the traffic. A full proxy creates a client connection along with a separate server connection with a little gap in the middle. The client connects to the proxy on one end and the proxy establishes a separate, independent connection to the server. This is bi-directionally on both sides. There is never any blending of connections from the client side to the server side – the connections are independent. This is what we mean when we say BIG-IP is a full proxy architecture.
The full proxy intelligence is in that OSI Gap. With a half-proxy, it is mostly client side traffic on the way in during a request and then does what it needs…with a full proxy you can manipulate, inspect, drop, do what you need to the traffic on both sides and in both directions. Whether a request or response, you can manipulate traffic on the client side request, the server side request, the server side response or client side response. You get a lot more power with a full proxy than you would with a half proxy.
With BIG-IP (a full proxy) on the server side it can be used as a reverse proxy. When clients make a request from the internet, they terminate on the reverse proxy sitting in front of application servers. Reverse proxies are good for traditional load balancing, optimization, server side caching, and security functionality. If you know certain clients or IP spaces are acceptable, you can whitelist them. Same with known malicious sources or bad ranges/clients, you can blacklist them. You can do it at the IP layer (L4) or you can go up the stack to Layer 7 and control an http/s request. Or add a BIG-IP ASM policy on there. As it inspects the protocol traffic if it sees some anomaly that is not native to the application like a SQL injection, you can block it.
On the client side, BIG-IP can also be a forward proxy. In this case, the client connects to the BIG-IP on an outbound request and the proxy acts on behalf of the client to the outside world. This is perfect for things like client side caching (grabbing a video and storing locally), filtering (blocking certain time-wasting sites or malicious content) along with privacy (masking internal resources) along with security.
You can also have a services layer, like an ICAP server, where you can pass traffic to an inspection engine prior to hitting the internet. You can manipulate client side traffic out to the internet, server side in from the internet, handle locally on the platform or or pass off to a third party services entity. A full proxy is your friend in an application delivery environment.
If you'd like to learn more about Proxies, check out the resources below including the Lightboard Lesson: What is a Proxy?
ps
Related:
Tuesday, March 21, 2017
Protecting API Access with BIG-IP using OAuth
As more organizations use APIs in their systems, they've become targets for
the not-so-good-doers so API Security is something you need to take seriously.
Most APIs today use the HTTP protocol so organizations should protect them as
they would ordinary web properties.
Starting in v13, BIG-IP APM is able to act as an OAuth Client, OAuth Resource Server and OAuth Authorization Server. In this example, we will show how to use BIG-IP APM to act as an OAuth Resource Server protecting the API.
In our environment, we’ve published an API (api.f5se.com) and we’re trying to get a list of departments in the HR database. The API is not natively protected and we want APM to enable OAuth protection to this API.
First, let’s try an unauthenticated request.
You can see we get the 401 Unauthorized response which is coming from the BIG-IP. In this instance we’re only sending 3 headers, Connection (close), Content Length (0) and WWW Authenticate (Bearer), indicating to the client that it wants Bearer Token authentication.
So we’ll get that authorization and a new access token.
Here the Getpostman.com (Postman toolchain for API developers) is preconfigured to get a new access token from the OAuth authorization server, which is a BIG-IP.
We will request the OAuth token and will need to authenticate to the BIG-IP.
After that, we get an authorization request. In this case, BIG-IP is acting as an Authorization server and is indicating to the resource owner (us) that there is a HR API application that wants to use certain information (about us) that the authorization server is going to provide.
In this case, it is telling us that the resource server wants to get scope api-email.
We’ll click Authorize and now we have our auth token and is saved in the Postman client.
Within the token properties we see that it expires in 300 seconds, it is a Bearer token and the scope is api-email and we get a refresh token as well.
Now we can add this token to the header and try to make a request again. And this time, we get a much better response.
We get a 200 OK, along with the headers of the application server. We’ll click on the Body tab within Postman, we’ll see the XML that the API has returned in response to the query for the list of departments that are available. There were no cookies being returned by the server if you were wondering about that tab. In the Headers tab we see the Authorization header that was being sent and the content of the Bearer token.
A simple way to easily protect your APIs leveraging OAuth 2.0 Resource Server capabilities in BIG-IP.
Special thanks to Michael Koyfman for the basis of the content and check out his full demo here.
ps
Related:
Starting in v13, BIG-IP APM is able to act as an OAuth Client, OAuth Resource Server and OAuth Authorization Server. In this example, we will show how to use BIG-IP APM to act as an OAuth Resource Server protecting the API.
In our environment, we’ve published an API (api.f5se.com) and we’re trying to get a list of departments in the HR database. The API is not natively protected and we want APM to enable OAuth protection to this API.
First, let’s try an unauthenticated request.
You can see we get the 401 Unauthorized response which is coming from the BIG-IP. In this instance we’re only sending 3 headers, Connection (close), Content Length (0) and WWW Authenticate (Bearer), indicating to the client that it wants Bearer Token authentication.
So we’ll get that authorization and a new access token.
Here the Getpostman.com (Postman toolchain for API developers) is preconfigured to get a new access token from the OAuth authorization server, which is a BIG-IP.
We will request the OAuth token and will need to authenticate to the BIG-IP.
After that, we get an authorization request. In this case, BIG-IP is acting as an Authorization server and is indicating to the resource owner (us) that there is a HR API application that wants to use certain information (about us) that the authorization server is going to provide.
In this case, it is telling us that the resource server wants to get scope api-email.
We’ll click Authorize and now we have our auth token and is saved in the Postman client.
Within the token properties we see that it expires in 300 seconds, it is a Bearer token and the scope is api-email and we get a refresh token as well.
Now we can add this token to the header and try to make a request again. And this time, we get a much better response.
We get a 200 OK, along with the headers of the application server. We’ll click on the Body tab within Postman, we’ll see the XML that the API has returned in response to the query for the list of departments that are available. There were no cookies being returned by the server if you were wondering about that tab. In the Headers tab we see the Authorization header that was being sent and the content of the Bearer token.
A simple way to easily protect your APIs leveraging OAuth 2.0 Resource Server capabilities in BIG-IP.
Special thanks to Michael Koyfman for the basis of the content and check out his full demo here.
ps
Related:
Wednesday, March 15, 2017
Lightboard Lessons: What is a Proxy?
The term ‘Proxy’ is a contraction that comes from the middle English word procuracy, a legal term meaning to act on behalf of another.
In networking and web traffic, a proxy is a device or server that acts on behalf of other devices. It sits between two entities and performs a service. Proxies are hardware or software solutions that sit between the client and the server and do something to requests and sometimes responses.
In this Lightboard Lesson, I light up the various types of proxies.
ps
Related:
In networking and web traffic, a proxy is a device or server that acts on behalf of other devices. It sits between two entities and performs a service. Proxies are hardware or software solutions that sit between the client and the server and do something to requests and sometimes responses.
In this Lightboard Lesson, I light up the various types of proxies.
ps
Related:
- Encrypted malware vs. F5's full proxy architecture
- The Concise Guide to Proxies
- The Full-Proxy Data Center Architecture
- Three things your proxy can't do unless it's a full-proxy
- Back to Basics: The Many Modes of Proxies
Tuesday, March 14, 2017
Social Login to Enterprise Apps using BIG-IP & OAuth 2.0
Password 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
Tuesday, March 7, 2017
What is Virtual Desktop Infrastructure (VDI)
What is VDI?
Imagine not having to carry around a laptop or be sitting in a cubicle to access your work desktop applications. Virtual desktop infrastructure (VDI) is appealing to many different constituencies because it combines the benefits of anywhere access with desktop support improvements.Employees typically use a wide range of mobile devices from laptops to tablets and from desktops to smartphones are being used. The diversity of these mobile devices and the sheer number of them in the workplace can overwhelm IT and strain your resources.
Desktop Virtualization centralizes sets of desktops, usually in a data center or cloud environment, and then provide access to your employees whether they are in the office, at home or mobile. VDI deployments virtualize user desktops by delivering them to distinctive endpoint devices over the network from a central location. There are many reasons why organizations deploy VDI solutions – it’s easier for IT to manage, it can reduce capital expenditures, improve security and helps companies run a ‘greener’ business.
Since users’ primary work tools are now located in a data center rather than on their own local machines, VDI can strain network resources, and the user experience can be negatively affected. Desktop virtualization is a bit more complex than server virtualization since it requires more network infrastructure, servers, server administrators, authentication systems, and storage. VDI’s effect on the network is significant; it may necessitate infrastructure changes to accommodate the large volume of client information that will be traversing the network. When a user’s desktop moves from a physical machine under the desk to the data center, the user experience becomes paramount; a poor VDI deployment will result in IT being flooded with “My desktop is too slow” calls.
Why VDI?
Mobile devices and bring your own computing are popular drivers for VDI deployments. It enables employees to work from anywhere and simplifies/unifies desktop management, especially updating operating systems and applications. It can lower costs, provide flexible remote access; improve security and compliance along with potentially offering organizations disaster recovery options. It also enables employee flexibility and reduced IT risk of employee owned devices. VDI allows employees work with a wide range of devices from laptops to tablets to smartphones. Employees can sign on from wherever they are, whenever they like and with whichever device they choose.Deploying virtual desktops can also increase IT efficiency and reduce IT workload since the desktops are centralized. It also benefits IT with greater access and compliance control, while at the same time, allowing employees the freedom to use their mobile device of choice. IT departments can remove obsolete versions of application software or perhaps enhance the security policy. Either way, the employee always has the most up to date desktop image.
Things to Consider
Desktop virtualization is no longer about the desktop, it’s about allowing employees desktop access from wherever they are. So things like availability, access, security, DR, authentication, storage, network latency and SSO are all areas to keep in mind when deploying a VDI solution.VDI Providers
Some VDI solutions include VMware View, Citrix XenDesktop, and Microsoft RDS.Next Steps
If you'd like to learn more or dig deeper into VDI, here are some additional resources:Wednesday, March 1, 2017
Q/A with Admiral Group's Jinshu Peethambaran - DevCentral's Featured Member for March
Jinshu Peethambaran is a security architect
currently working with Admiral
Insurance. He started his career 9 years ago, managing network security
operations and started working on F5 products about 5 years ago.
He is also a 2017 DevCentral MVP and DevCentral’s Featured Member for March! DevCentral got a chance to talk with Jinshu about his work, life and his dream of being 100 million miles in space.
DevCentral: Hi Jinshu, thanks for you time. You’ve been a very active contributor to the DevCentral community. What keeps you involved?
Related:
He is also a 2017 DevCentral MVP and DevCentral’s Featured Member for March! DevCentral got a chance to talk with Jinshu about his work, life and his dream of being 100 million miles in space.
DevCentral: Hi Jinshu, thanks for you time. You’ve been a very active contributor to the DevCentral community. What keeps you involved?
Jinshu: DevCentral has helped me greatly over the years as I’ve worked with F5 products, so I feel like it’s worth spending some of my time both reading posts and helping others in the community. Searching DevCentral, I found another approaches to solving issues, helping me to solve challenges. Just checking the most recent questions is a great way to learn things.DC: Tell us a little about your areas of BIG-IP expertise.
JP: At earliest stage in my career, I was involved on basic BIG-IP LTM projects. After some successful experiences, I started working on another level and learn different BIG-IP modules.
Now, I think I’m pretty comfortable with all F5 BIG-IP modules but I’m clearly specialized in security. Now I’m pretty confident on BIG-IP LTM, DNS (formerly GTM), ASM, APM and AFM modules. I have implemented multiple solutions using these combinations for different customers, all these years.DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.
JP: iRules are great tool to solve unique BIG-IP challenges, but iRules are nothing without the developer’s community. DevCentral experts share experience not only about tcl coding but protocol knowledge, iRule events orders, and working iRules. And on the other side, some IT admins ask about new needs that I may answer for the next customer.DC: Can you tell us a little about your blog, Secure Leaves and why it is important to Know your network before a hacker does?
Security is a vast area and we get new requirements and challenges every time. Each time I get a new challenge, I first search on DevCentral to see if someone already solved it. If not, I’ll create my own iRule.
JP: Since I started working on security domain, I through to give a helping hand for others as well. So I started this blog explaining small technical challenges and solutions for that. This blog focus on security products and hence the title “Know your network before a hacker does”.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?
JP: I’d probably be an Astronaut or a professional space traveler searching for external life and doing experiments in Mars. J When I was a kid I always dreamt about being an Astronaut, staring at the stars.Thanks Jinshu! Check out all of Jinshu’s DevCentral contributions, check out his blog, or connect on LinkedIn. And visit Admiral Group plc on the web and LinkedIn
Related:
Subscribe to:
Posts (Atom)