Episode Transcript:
Hello PANCasters. Today we talk about SAML. We’ll start with an introduction and then look at how it is used with Palo Alto Networks products.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
First of all, what does SAML stand for? It stands for Security Assertion Markup Language. Basically SAML is an open standard authentication protocol.
With SAML, we have a number of systems involved. First, we have the user. That’s me, as I want to access some applications. We also have a service provider and an identity provider. So let’s say I want to access Zoom. This will be the service provider but I am not set up as a user on Zoom. This is where the identity provider comes in. Let’s say my company uses Azure AD which is a cloud based Active Directory service and that’s where I am listed as a user. Zoom and Azure AD are configured to know about each other so when I try to log in to Zoom, I get redirected to authenticate to Azure AD. Once I have successfully done this, Azure AD sends back a response called an assertion which is forwarded to the service provider. Assuming I have authenticated successfully, this allows me access to Zoom. Now one thing to note is that the service provider (Zoom) and the identity provider (Azure AD) do know about each other and have to be configured but they never communicate directly with each other. It is all done via the user.
So why is SAML becoming so common? Well obviously it is widely accepted as an authentication protocol for cloud applications and more and more we see organisations moving their directory services to the cloud as well. It also allows users to access multiple applications using the same authentication service and therefore the same credentials. This also provides additional security as your details are not stored on every service provider you access, just with the identity provider. It makes sense that we are seeing it used more and more.
Before we move onto SAML uses with Palo Alto Networks I want to discuss a couple of other terms often used with SAML. Let’s start with SSO. SSO stands for Single Sign On and gets back to the fact you can use the same credentials with multiple applications but even better. Once you authenticate to your identity provider, tokens are used. So even though you try to access a different application, but one which is also using SAML with the same identity provider, you won’t be asked for your credentials again, the token will be used to authenticate you.
SLO is somewhat related and stands for Single Log Out. This needs to be configured on the service provider and what it means is that if I am authenticated to the identity provider, I can now access all the applications assuming SSO is configured and working. If I log out of application x and SLO is not configured, the SAML tokens will still let me authenticate to other applications without providing my credentials again. If SLO is configured, when I log out of application x, I get logged out from the identity provider. Next time I try to access an application, I need to provide my credentials again.
OK, so that’s SAML. Next let’s look at how we use it with Palo Alto Networks. As an authentication protocol there are a number of places we can use SAML. The obvious first one is accessing the management of our products, so when you login to a firewall, or Panorama, you can use SAML as the authentication method.
Probably the most common one used now is for GlobalProtect. GlobalProtect client is used to set up a VPN to either an on-prem gateway or to Prisma Access. The GlobalProtect client needs to authenticate to the portal and/or gateway and we see SAML being widely used these days, especially for Prisma Access. It again gets back to a shift to using cloud provider authentication and directory services.
The final use is for captive portal. Firstly a quick recap. We can use captive portal on a Palo Alto Networks firewall to request a user to authenticate before being able to access services through the firewall. There are different use cases for this. Let’s say you are using userID to only allow certain users to access the Internet. If any traffic reaches the firewall that is from an IP that does not have a user associated, captive portal can be triggered to ask the user to authenticate. As this happens on the firewall, we now know the user to ip mapping. Another common use case is not just for Internet access but say accessing sensitive internal applications through the firewall. Captive portal can be used in this case as well to request the user to authenticate and also provide multi factor authentication for additional security.
OK, so that sums up the introduction to SAML and how it can be used with Palo Alto Networks products. One last thing regarding configuration. As we now know the service provider and the identity provider need to know about, and trust each other so this needs configuration. SAML configuration is made even easier because generally both service providers and identity providers can export the SAML metadata. This is simply the config required by the other side, which can then be imported rather than manually having to configure the various options.
I normally like to throw in some troubleshooting tips but to be honest SAML should normally just work — and if it doesn’t, it can require some specific captures to see why it is not working. Probably the main thing to remember is the use of tokens, so a user may not always have to provide credentials when authenticating. This is not so much for troubleshooting but just understanding it is there. When it comes to using SAML for GlobalProtect, it is even more important to know because with GlobalProtect, we also use cookies for authentication. This means both GlobalProtect and SAML can use their own tokens/cookies to authenticate a user without prompting for credentials.
There we have it: a brief intro to SAML and its uses with Palo Alto Networks. We are seeing this used more and more, and luckily issues are pretty uncommon, other than a few config tweaks or understanding the protocol. Hopefully this has helped.
Remember to head to live.paloaltonetworks.com for the transcript and related articles.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
