Hardening Infrastructure Security Against SSO Identity Provider Compromise

In an era where Identity Providers (IdPs) have become prime targets for cyber attackers, relying solely on single sign-on (SSO) authentication can leave organizations vulnerable to various sophisticated threats such as social engineering, credential stuffing, and session hijacking. Join us for an in-depth webinar to explore how Teleport is redefining infrastructure security strategies that protect infrastructure even in the event of identity provider compromise.

Learn about the strategies that defend infrastructure from IdP compromise. Teleport and security research firm 

 will review research and key findings that show how to defend against common threat vectors faced by identity providers.

Get an exclusive look at the new features in Teleport 16 that support infrastructure security hardening strategies:

 Understand how Teleport 16 enforces multi-factor authentication (MFA) for each session, significantly reducing the risk of unauthorized access.

 Learn about the new trusted hardware checks for web applications and Windows desktops, ensuring access is granted only from known and secure devices.

 Explore how Teleport VNet offers zero trust access to applications without the need for VPNs, using ephemeral mutually authenticated tunnels to simplify secure connectivity.

Infrastructure and IT Security professionals

 Equip your organization with advanced strategies to fortify your infrastructure against IdP breaches. Gain actionable insights into leveraging Teleport 16's features to create a more resilient and secure environment.

Key topics on Hardening Infrastructure Security Against SSO Identity Provider Compromise

Identity Provider (IdP) compromises are a significant threat, as demonstrated by recent high-profile breaches like Okta's in 2023.

Relying solely on Single Sign-On (SSO) authentication leaves organizations vulnerable to various attacks.

Identity is only one component of access control; hardware identity and authorization are also crucial aspects.

Key security principles to protect against IdP compromise include ephemeral admin access, additional identity confirmation layers, and access management security.

Teleport 16 features that support these principles include:

Machine ID for authenticating automated tools

It's important to have a proper authorization setup across apps and systems to limit the impact of a compromise.

Teleport's design philosophy emphasizes eliminating secrets where possible, using short-lived certificates instead.

Organizations should leverage a combination of hardware identity (Device Trust), network Security (IP pinning), ephemeral access, and in-session multi-factor authentication.

Balancing security with usability and productivity is vital for effective implementation.

Expanding your knowledge on Hardening Infrastructure Security Against SSO Identity Provider Compromise


Transcript - Hardening Infrastructure Security Against SSO Identity Provider Compromise

Ev: All right. Good morning, everyone. Also, good afternoon or good evening because we understand that folks are joining us from different parts of the world. It's great to have you all here. And today we are going to be talking about what to do to harden your infrastructure against a compromised identity provider. Every company uses some kind of IdP for single sign-on. And recently there have been some examples of breaches on the SSO side. So what do you actually do when your IdP is compromised? That is what we're going to be talking about.

Ev: And first of all, before we dive kind of deep into the topic, let me cover a little bit of logistics. So first of all, at the end of this webinar, you will be given a very, very short survey. Please let us know how we're doing, asking you to fill that out. Again, it will be really, really short. Additionally, all the information that you will be hearing today will also be shared with you via email. You will get a PDF copy of the deck we will be showing. We're also recording this podcast and the recording will be shared with you via email as well. And we'll also be publishing it on our website. Additionally, we only have 30 minutes today to cover this topic. But again, it's a complicated technical topic so there are going to be some additional white papers that we will be sharing with you as well.

Ev: So now back to — what do you actually do to harden your infrastructure against an SSO provider compromise? We will have two security experts joining us today, Luca and Francesco from a company called Doyensec, who will be showing you what you do in this case. And the reason why we decided to do a webinar on this topic — first of all, because there's been some recent breaches. Some extremely visible companies got compromised exactly through a compromised IdP. So we're going to talk about — so naturally, because we are in a cybersecurity industry, our customers at Teleport — they came to us with questions. Some of them were extremely confused. And they thought, "Well, it's probably game over. If my identity platform is compromised, what hope do I have to stay secure?" So the answer is don't worry. Your identity platform is only one pillar of several. Access — and it's a very good thing — is more complicated and much more nuanced aspect of it. So I'm going to pass it on to Luca, who will give you an example of what actually happened with some of the kind of famous breaches recently, and then we'll dive deeper into what do you actually do to defend against it. Luca?

Luca: Thank you so much, and thanks for having us. So I guess it would be good to kick off the discussion with a couple of examples of IdP compromises. So I guess you all remember Okta compromised in September of 2023. The attacker basically got access to an unauthorized — they got unauthorized access to a customer support system. That was actually associated with over 130 Okta customers. This is clearly an internal system that is not meant to be accessed by external people. Interestingly, in this case, the compromise was reported by 1Password that noted some suspicious activity on the Okta support. And after the investigation, it was discovered that the compromise was possible through the compromise of a personal account of an employee that used an Okta-managed laptop to log-in to the personal Gmail profile. The Gmail profile had access to the credential for the customer support portal. And so this was kind of the entry point.

Luca: It's also interesting that just the access to the support portal then led to the compromise of the customer Okta instances. And this was due to the use of HTTP archive. So a file that was used for debugging purposes. So whenever a client would have a problem, could basically get a dump of the browser session, which would also include session tokens. And that was used to impersonate a valid user. So, at the end, the attacker was able to hijack the session of five users, and as a result, logging in to their tenants. So I think what's interesting here — is not just the fact that an IdP was compromised, but also what led to the compromise. And we'll touch base on that towards the end of the presentation — is some of the mitigation that we put in place by Okta, which I would say they are generic best practices, secure engineering practices, such as, for example, ephemeral access. So Okta has implemented, since then, ephemeral access for admins. The idea is to basically give the minimum set of permissions for a smaller window opportunity so that the attacker is limited in what can be done.

Luca: Additionally, MFA required for specific protected action for admins was also introduced. And so again, having a multi-factor authentication that can act as a showstopper in case of important actions. And then finally, things like IP binding and other techniques that are basically trying to identify a device and as a result, limit session tracking. So this is kind of the gist of the Okta compromise.


Ev: Yeah. Thank you for this. And I do think maybe it's worth mentioning why is it exactly the customers are coming to us? For those of you who are not familiar with Teleport or Doyensec, what our companies do is infrastructure protection. So Teleport is an infrastructure access platform. So when engineers are accessing AWS accounts, Azure accounts, Linux servers via SSH or Windows machines via RDP or Kubernetes clusters, databases, list goes on and on and on — there are many different workloads that live in computing environments. So access to all of those things is controlled by Teleport. And Teleport can act as an IdP itself, but most frequently it's deployed in an integration mode with an IdP like Okta or maybe Active Directory. So naturally, engineers or engineering leaders responsible for protecting infrastructure and protecting data were curious what do we do when our IdP is compromised?

Ev: TLDR, very short answer of what we're telling them, is that identity is only one component of the variables that are involved into granting access. So first of all, IdP is platforms that are responsible for managing identities of humans, not identities of hardware. But hardware also matters. The laptop that is being used to access a production environment — it also has an identity. So that needs to be leveraged. And the question of identity is closely tied to authentication. And authentication is, again, just one component of granting access because there is also authorization. And this is something that we're going to be talking with the Doyensec guys in a moment. So that is why we've been involved in these conversations and why we felt that doing a webinar on this topic will just benefit everyone because we've been repeating exact same stuff over and over and over again. So now I want to pass the mic to you guys again. So let's dive deeper into what organizations are actually supposed to do to effectively defend against a compromised identity.

Luca: Yeah. And let's start this section by saying that it's interesting how, for example, password managers are generally considered very good practices for information security, but they are also the single point of failure, right? And so in case of infrastructure, we kind of see a similar pattern here with an IdP compromise. The research and the details you will see illustrated by Francesco in a second are actually, from a technical standpoint, very interesting because if you would ask any practitioner about an IdP compromise, as you mentioned at the beginning, it feels like a game over. And so what can we even do from a technical standpoint? Can we mitigate blast of such a compromise? And how is it affecting the usability, and how is basically the IdP compromise playing a role in the overall — limiting the lateral movement for an attacker.

Luca: So that's basically where we started when we were approached by Teleport to study the topic. Just a 10-second presentation about Doyensec. We are a security engineering company. And so we really focus on the security engineering aspect. And this was a very interesting technical challenge for us because it requires to combine what are the elements normally of an IdP and a service provider relationship with security element that you would normally find in infrastructure. And so that's basically what we did. Went into dissecting the threat model, which will be quickly soon illustrated. And then trying to understand what can be done to limit the access to the services that are protected by IdP. I guess we can jump into the IdP and then threat model.


What is an Identity Provider (IdP)?: Definition and Service Providers (SP) relationships

Francesco: Yes. Hi, everyone. I wanted to start by setting the frame. So let's start with the definition of IdP in general. From a high perspective, an IdP is a service meant to manage a user pool and also to authenticate this user pool against a set of service providers, which are basically applications. You can see here in the slide a very high-level scheme defining the basic relationship between the IdP, the user, and the service providers. And yeah, you might notice that there is a trust relationship, an implicit trust relationship between the IdP and the service providers. So what that means is that basically once set up, the IdP and the service providers, which are the applications like Teleport as an example, will trust the authentication proof that will be relayed from the user side to them to authenticate the users. So once verified that the authentication proof is coming from the correct IdP, they will completely trust the data in them. And then starts what's the actual critical part of the trust relationship, which is basically the translation of the user object from what's the user for the IdP to what actually the user is in the service provider.

Francesco: To give you a brief example, you will have, as an example, in the IdP, maybe a group will be converted to a role, a specific role within the service provider, and so on. So we have all this logic with the authorization conversion, which starts since the first validation of the proof of authentication. And that was exactly the starting point of our research. I said at the beginning, the main question was: what can a service provider do in order to protect its own service when the IdP, the trusted IdP, is compromised? And so I will go now for the next slide, please.


Evaluation strategy: IdP levels of compromise & threats against the SP

Francesco: So where we started, we started from the definition of our threat model. And you can clearly see here two parts of the slide. On the left, we have the different compromise levels that you might have on the IdP. And on the right, you can see some buckets containing the high-level threat vectors that might happen. And where we have multiple compromise levels on the IdP side on the left, it's because generally speaking, we usually hear an IdP admin is compromised in the news, and then it's game over. But in reality, you don't always need an IdP admin, the super admin, to do harm against the service provider trusting it. So this is what the compromise level is about. And you can see the three buckets in there.

Francesco: The first one on the bottom is the fully compromised IdP, which is less likely to happen because for that one, we mean that the IdP was fully compromised and the attacker had a vulnerability on it, and can arbitrarily decide what's given to the service provider in terms of user objects. And then we have in the center the privileged account compromise, which is a bucket that contains the complexity, actually, of what authorization means at the IdP level. Because in an IdP like Okta, Azure, etc., you don't only have super admins. You have super admins, you have group admins managing the mapping of their own users to some specific tasks and applications. You might have also application admins, which are those managing the actual service providers. So when we hear account in the IdP, it might have a wide range of opportunities depending on which one.

Francesco: And yeah, the last one is the non-privileged account compromise. You might think that why adding this one? Because it's the least — the last one, basically, having just access to specific applications, and it can just do a single sign-on authentication to the apps. But actually, we had to add it because it truly depends on the connector security. If the end user will be able, as an example, to edit some attributes in his own profile at the IdP, while not being an admin, they can still change some profile attributes. That might also cause a privileged escalation in the service provider depending on the configs. So that's why we added in there.

Francesco: And speaking about the threat vectors, they are very generic because we wanted to incorporate and generalize the service provider problems. And you can see that there are a couple of entries about impersonation of privileged, non-privileged users in the service provider. Then we had also information disclosure. And in my opinion, the most important one is the downgrade of the application security of the service provider, which is a technique that was observed many times around where basically attackers want to target the service provider since the beginning, but they use the trust of the IdP to downgrade the security level of the service provider through user impersonation, basically.

Francesco: So [inaudible] this model, what we did was using Teleport as a service provider, and we went down and configured multiple IdPs of the ones supported by Teleport as an identity source against our cluster. And what we did was practically simulating those attacks on the different levels of compromise for each IdP. Then basically, we started a loop where we would try to harden the Teleport cluster with the available features, [inaudible] was not working as expected, and then work in pair with the Teleport to fix and continue again the iteration until we reached a point where we were very satisfied, actually, in terms of protections. And this process is well described in our full white paper, which is 48 pages long. So today we don't have enough time, unfortunately, to go through all the details.


Francesco: So now I will jump to the next slide for the wrap-up actually of what we learned. And what we learned in the end is the necessity to define, as set by Luca at the beginning in the Okta case, the importance to define some core security principles that are needed when we want to protect the SP when there is an IdP compromise. And here in the slide, you can see on the left, the general security principles that we came up with during our test. And on the right, you can see that we have tried to map those principles to actual security features in Teleport that you can configure to be compliant with this, to follow the principles, actually.

Francesco: And yeah, to quickly describe them, we have ephemeral admins which are meant to access the request to specific resources and roles instead of granting SSO users directly the roles. And you can see that in Teleport in the list, there is also dual authorization, which adds security on top of that because it's allowing you to define multiple reviewers required for critical resources. An example could be a super admin in Teleport role should require, as an example, multiple reviewers to be granted. And that's a very cool feature from the solution. And in the center, we can see the additional identity confirmation layer, which is a set of security features about multi-factor. And each of them, in my opinion, should be required to protect against all the potential threats.

Francesco: And we can see as an example, the mandatory MFA enrollment for newcomers, for new users. You can see also the new feature, the MFA for administrative actions, which is the key to further protect the admins. Because with that on, the admins will be required to take an extra verification step before doing and performing state-changing actions in Teleport like adding roles, removing applications, or doing harmful administrative operations. And with the last group of features, actually, we need to go on the real conclusion of this research, because the last group is about access management security, and it contains basically what you should know about your authorization in Teleport and your IdP, because you might be configuring the authorization through access list rather than roles. And you might have a different mapping depending on the authentication connector.

Francesco: And if we can have the next slide, please. What we learned about when reviewing and trying those features is that unlike some of the other cases like MFA, there are some configurations which are not an on/off switch. You can turn it on and be secure. You actually need to configure them in the proper way while being conscious of your IdP to be protected. And all of that actually about these features is summarized in our hardening checklist that you can find in the link. I don't know if it was added to the resources for that in this, but the slides will be shared actually. And yeah, you can find the full white paper from Doyensec, the checklist, and also the wrap-up that was made by Teleport. And they did a beautiful job in summarizing the work.


Ev: Yes. All of this information will be shared, both white papers and these slides. And so the summary of these recommendations is to realize that an IdP is just authentication of a user. So compromised IdP means that you might have potentially a user who is not who they claim they are. So you need to leverage capabilities like hardware identity via Device Trust, as well as network security with IP pinning, and also heavily leverage ephemeral access, meaning doing things like access requests with access approvals and in-session multi-factor authentication. So now we have David here from Teleport, who will do a quick demo of some of these capabilities and how easy they actually are to use. Because as we all know, security oftentimes comes as a trade-off to productivity. It's actually not that hard to make a completely secure system. You just basically don't give access to anyone, but then nothing will be possible. The engineers actually need to be using all these powerful computing resources. So usability, and speed, and convenience — they're often just as important as security. So David, please show us how all of this works.


Dave: Yeah. Thanks, Ev. So I'm going to show off a couple of things. Just a quick overview of some of these things in action. The first thing is just Device Trust. Built into Teleport for a long time now. You're going to have to trust me that this device is enrolled. It's this top one here. Showing the serial number of the Mac does not come across well on a screen share. So I've got this device enrolled and we have Device Trust enabled for this cluster. And to Ev's point, I think there are different levels of need. So for this cluster, we actually have Device Trust required at the cluster level. So every single person taking an action inside of this cluster needs to have Device Trust set up. They can only be using a registered device. And so for the most secure environments, if you want to make sure that nobody is doing anything not from an organizational device, you can do that.

Dave: The other thing we have set up at the cluster level is requiring per-session multi-factor authentication. And you can see that here also set up at the cluster level. But you can also do it at the role level. So if there are just particular teams, like for production access, you just need the operations team to have one or both of these. But maybe for dev, it's fine if people are coming in, or for your level of comfort, then you can set it up at the role level as well. We try to make sure with Teleport that you can configure things to your level of need. Although, of course, the more secure you can be, the better.

Ev: David, before you continue, I do want to make a comment for folks who are not familiar with Teleport. You probably heard the word cluster being used several times. So in Teleport terminology, cluster means an environment. So companies usually have many different environments, different cloud providers. Some are production. Others are used for development. So Teleport allows you to kind of partition all of your infrastructure into these environments. And in Teleport they're called clusters. I guess we got inspired by Kubernetes language back in the day.

Dave: Thank you for that clarification. Yeah. We didn't do a, "Hey, how familiar are you?" So I'll try to level it as much as I can. One of the things we introduced in Teleport 15 was mandatory MFA for admin actions, as the Doyensec folks were talking about. So here I'm editing a user. I want to try to debug something, so I'm going to add the ability for this user to issue SPIFFE IDs. And when I hit Save here, it's going to come up with a requirement for a passkey because you cannot take admin actions in Teleport now without having multi-factor auth. In this case, again, in this cluster, in this environment, we're enforcing that with a hardware key, not just an OTP. One of the things we've been trying to move towards in Teleport is making sure that everywhere that you can enforce multi-factor authentication, you can do it with phishing-resistant multi-factor authentication. Used to be that 30-second codes seemed like enough. And as attackers get more and more clever and find more and more ways to beat 30-second OTPs and come up with spoof sites, we're making sure that it's possible for everyone to do this with hardware keys.

Dave: Another thing that Doyensec folks were recommending is that ephemeral access. So here in the browser, I'm logged in as a user that has review capability and a little bit more powerful permissions by default. But I'm going to come into this instance of Teleport Connect, which is our desktop application, with a user that really doesn't have as many permissions at all and really needs to request access to everything. So again, in a realistic situation, you're going to have a bigger balance of these things. But for the purposes of this scenario, I'm having some issues with our GitLab instance. I might need to get on there and change some configurations. I want to be able to go in and see the metrics coming out of that. So I'm going to request access to that SSH server and our Grafana instance so that I can go in and get the information I need. I'm going to do a request here. I don't need it for one day and five hours. I probably only need to do this for — I'm guessing about two hours — and I'm just going to say I'm debugging issues with GitLab instance, and submit my request.

Dave: I'll come over here and see those requests. So back here is the admin user or rather the reviewer user because they don't need to be the same. I can see that that user over here has put in an access request. I can view the details of it. I can reject it. I can approve it. If we had access lists set up, I could do even more long-term submission for it. But all right, two hours seems reasonable. I might reach out to this person on Slack and just get a bit more information, but I'm going to approve the request for now. And again, here, this is an admin action. You can't just go approve an access request like this without your MFA. And so I'm going to just tap my key and see that it's approved. And if I come back over here, I can view this. I can see it was approved. And now as the user, I'm going to assume this role that allows me to access these resources.

Dave: And if I come back here now, instead of request access, we can see that Grafana has a launch option. So I'm going to hit Launch. It's going to bring up a browser. And again, because we have per-session MFA turned on at the Teleport cluster level, every action that we take is going to require MFA. So even for this user just coming into Grafana, if an attacker had come in as this user, had seen that a request was made, whatever, was able to get in and do this. Even just to access the application now, we're making sure that that's locked off to the actual person who can provide a secondary form of authentication. And again, this works in multiple places. So it's not just the browser. I can come to a command line interface. I can say I want to get on to that VNet GitLab instance, and the CLI also requires that I tap my security key to be able to get in and do diagnostics on that server.

Dave: So what we've seen is we have a lot of those things that Doyensec are recommending in place. You've got the ability to use trusted devices and not allow any actions taken without working from an enrolled device. We've got per-admin MFA actions. We've got the ability to request ephemeral access to critical resources and easily and quickly review and approve those requests or deny them. And we have those — and per- session MFA where anything you try to do — whether it's getting into a server, whether it's accessing a web app — you need to make sure that you have your secondary authentication factor to get in. Because all of these really, again, if the IdP was compromised, we're taking it to the next level of, okay, we accept that you should be able to access this account, but to take actions, we still want to make sure at the action level that you are who you are. And that is a quick overview.

Ev: Well, thank you, David. So hopefully for those of you who are with us, now it's pretty clear that when your IdP is compromised and you have a compromised identity trying to access your infrastructure, it's not the end of the world because that person will not be able to actually access anything if Teleport is configured properly and all of these features that David was showing are in fact turned on and available. So now we do have a little bit of time for questions. And as I said earlier, like all of this information, the recording of the webinar and the white papers, it will be distributed to you via email and also published on our website.

Ev: And now if you have any questions for us, you could hit the Q&A button and ask. And I already do see a question. One from Justin. Justin asked, "Does Teleport have some functions to ease the pain of setting up authenticated scans from an approved scanner vendor that needs its own credentials? We found MFA everywhere complicates this scenario." Okay. Let me try to understand what does it mean. Setting up authenticated scans from approved scanner.

Dave: I think a solution here, Ev, is Machine ID. I think really what we're talking about here is some sort of tool that is maybe running in an environment and trying to scan the network, scan containers, some kind of security tool like that. And yes, MFA everywhere for people does complicate that. Teleport has another piece of functionality called Machine ID, which is identity for not devices like a laptop that I'm working on or a person, but for a CI server, for some kind of tooling like Ansible, that sort of thing. And the way that we enforce identity in Machine ID is essentially using metadata about the device that's running. So that can be a TPM. If you're on-prem, it can be metadata from the AWS node, or GCP node, or Azure, or whatever. We have a whole lot of ways to identify a server. And then once Teleport is running in Machine ID mode on a server, tools from that server can run and do that without the need for MFA, because we are able to identify the piece of hardware that it's running on.

Dave: And that, I think, is — the trick with a lot of these services is, yeah, if you're trying to log in as a user, then you run into all the problems you have with not wanting to or being able to automate users logging in, in an automated fashion. We don't want that. That shouldn't be allowed. So we have an entire piece of functionality that allows you to authenticate machines that can run those sorts of tools.

Ev: Thank you. Justin, let us know if we answered your question. Anyone else? Any questions, concerns, random thoughts? Okay. So there is another question. At the infrastructure asset layer, yes, but also at the application layer, such as DST scanner needs to crawl the entire application. So it needs application credentials, but the application has MFA enabled everywhere to meet government requirements.

Ev: Maybe for this one, we may need to — Justin, maybe we should get on a call kind of separately and dive deeper into your particular use case.

Luca: Maybe while we wait for additional questions, I think it's the interesting things that we all kind of touched base on — was how authorization plays a very important role here in limiting the blast of a compromise, right? You generally think about IdP as the authentication component, but then having proper authorization set up across apps and systems is really crucial here. And that's what also allows the flexibility and the power of some of these features. So I mean, we can tell by experience, by looking at a lot of clients, how the investment in role and permissions across the overall authorization really plays an important role to limiting compromises. So it's a really good investment to do independently from the specific feature and particularly with those specific features enabled.

Ev: Yeah. Any other questions? Thoughts to share?

Dave: I think the thing I forgot to say doing the demo coming out of it is just all of that — I think, to your point of our focus on developer productivity — really was fast to do. I think that's the thing — is that we put a lot of effort into the UI and the user experience in general of making it so that you can have all those things in place and you can fly through it. And it doesn't get in your way while still allowing those things to be there.

Ev: So there's another question also that says, "I looked at Teleport in the past and got stuck on evaluation because there was no support for external secrets stores like AWS Secrets Manager. Has this changed?" Before I pass this to David, I do want to mention that Teleport design, like from the beginning, it's extremely opinionated. It's extremely anti-secrets. We essentially believe that if there is a secret anywhere in your organization, you're vulnerable. Whether you encrypt the secret or not, it lowers the probability of you getting hacked. But as your organization grows, as you add more and more engineers, as you add more and more hardware, you deploy more and more technologies into your environment. So secrets begin to multiply. And managing them only lowers the probability of you getting hacked eventually. But we believe if you truly want to be secure, you should not be using any kind of secrets.

Ev: However, with all of that said, of course, there are some secrets that Teleport needs to manage. For example, the private key for certificate authority that is used for issuing certificates. So we do support external storage for that secret, but we do not support kind of secret injection into live sessions like some other security solutions do simply because we believe that there is just not a secure approach to authentication. David, do you have anything to add here?

Dave: Captured pretty much everything I was going to say. Yeah. Our solution is based on short-lived certificates, and it's because we believe that that's the most secure thing we can have. And yeah, I was just going to mention the root key, but that's it.