Using an mTLS Identity Provider to achieve Password-less auth, Device Health Attestation, and low Earth orbit

hello everyone welcome to b-sides SF 2023 my next presenter is Armin today slido is not working we will be doing cute live q a at the end if we have time if not we will be doing it in the lobby go ahead and take it away so this is a 10 000 foot view of what was happening in the in those previous slides so first a user attempted to access something behind OCTA then OCTA recognized that the user needed to authenticate against our custom identity provider and OCTA routes to our custom identity provider using IDP routing or IDP discovery our identity provider valid validates the device and then indicates to OCTA that authentication was successful and from

there OCTA proceeds with the authentication flow prompting the user for for their 502 key and an OCTA session gets established apologies in advance as this slide is going to be pretty octa-specific for those that are trying to implement something device trust related within OCTA there are three options you can consider first you can use the native OCTA device trust Solutions there's a variety of options in classic and in oie you can purchase a third-party vendor for a device trust solution and you can build your own and so when exploring the different vendor-centric options one thing that became really apparent was most vendors try to integrate with OCTA using an external identity provider and this was a little

confusing at first but after doing a little bit of research it became really apparent as to why this was it's because there's no real other way of integrating with OCTA to be able to do something like this and so if you're trying to do something interesting if you're trying to modify the authentication flow in some capacity you're really left with no other choice but to build your own identity provider literally take the user out of the ecosystem do your interesting thing like device trust and send the user back to OCTA and so once you have that identity provider there's two different ways of integrating with OCTA you have idps MFA which allows for a customer to replace

their existing form of MFA with the device trust identity provider and you have idps SSO which allows customers to replace your OCTA password with the device trust identity provider however at the expense of introducing multiple methods of bypassing the external IDP so for Pinterest because we have this more complicated MFA policy if you will because of our 502 deployment using the IDP as MFA approach was never an option for us and so what we've done is basically use the IDP as SSO approach and if you're interested in how we mitigate all of these bypasses that I'm referencing I I'll be linking to a blog post at the end of the presentation so feel free to

check it out all right so we have basically concluded that in order to do that interesting thing we need to build our own identity provider and so now the question becomes what do we do with that identity provider how do we determine whether or not a managed device is being used to authenticate and so there were three things that were top of mind when we were figuring out how to do this first we wanted to have an intuitive user experience for for our end users we didn't want to dramatically change how authentication looked or felt we didn't want applications to or users to have to switch between apps or something like that to to determine if a managed device

was being used we wanted something that was platform agnostic we wanted to support all of the the existing platforms that we support at Pinterest today which includes Mac OS Windows Android and iOS and we wanted to do this in a way that didn't require the use of any new agents we didn't want to write our own iOS or Android apps to support this and so what we what we landed on was a certificate Centric approach to do device attestation so we use certificates that are only provisioned to managed Pinterest devices as a means of authenticating devices that are being used to authenticate to our identity provider so let's go a little bit deeper into the

actual authentication flows that we support within our identity provider so we have a passwordless flow which most of our employees use to authenticate to OCTA and we have a 3fa flow which is used when authentication is necessary from a shared device so for the passwordless flow you'll notice that once the user is in our identity provider the user presents a certificate that includes both the user and device context we validate whether the certificate itself was valid and then we extract the device metadata from that certificate and ensure that the device associated with the certificate is in a compliance State and if all of that is true we give OCTA the thumbs up and basically say proceed with

the authentication I have authenticated the user and that's where OCTA takes over the authentication flow prompts the user for their 502 key and an AUX session gets established for the 3fa flow it's a little bit more complicated um we for this particular flow we you might notice that there's an authentication flow within an authentication and that's why we call it the exhibit flow um so the reason why this is necessary is because we want to be able to support um shared devices and we also want a pathway for uh having a higher bar for authentication think of admin accounts or something like that and so there was a desire to introduce three factors and the way that we go about doing that is

essentially triggering another authentication flow when the user is in our identity provider and so if you think of it in the context of an outer authentication flow and an inner authentication flow for the outer authentication flow it resembles what you see above really closely and the inner authentication flow happens and needs to be successful in order to complete that outer authentication flow and so this is how we can get around one of the limitations within OCTA which is that you can only enforce two forms of Authentication

I may have lied a little bit when I alluded to the fact that Mutual TLS or certificate off results in a positive user experience uh in fact browser-based Mutual TLS often leads to a horrendous experience for end users as demonstrated in this slide so notice that within a native application on Android after canceling the certificate prompt there's no intuitive way for the user to recover from that mistake even going as far as restarting the application or refreshing the page you're not able to be re-prompted for that certificate prompt and so in order for us to move forward with a custom identity provider that uses certificate-based authentication as its primary form of auth we had to solve

this problem and I'll explain how we mitigated this issue in the next few slides so the thing responsible for this behavior is a chromium cache called the SSL client auth cache this is responsible for caching the decision that a user makes when they're greeted with that certificate prompt and so the the most notable thing to take away from this is the entries in this cache are based on the host Port pair associated with the server or hostname that you're trying to interact with and so if we keep that in mind and we you know make some server-side changes to maybe abuse that functionality or or how that cache Works um we're able to trick the browser into

thinking that they're continuously seeing a new hostname and so the way that we go about doing this is really simple we just continuously redirect users to random subdomains and so this this is what this looks like in production again in a native application on Android and notice this time around when a user is prompted for that certificate certificate prompt um canceling does not result in that super painful experience and in fact I think this is a pretty intuitive way for the user to recover from that mistake

and this is the actual representation of the routing logic in our Edge infrastructure and so notice up top that if a valid client certificate isn't presented we perform a 302 sending the user to a random subdomain and if at that point a valid certificate isn't presented then we'll present the user with that error message with a button to to try to re-authenticate all right so we have reached the point where we've built our own identity provider we have now also determined which device is trying to authenticate based off of the certificate that was presented now we get to talk about how we do device attestation or device health attestation and so uh the first thing that we do

is ADD authentication time we collect all of the data all of the device data associated with the device trying to authenticate and so we collect data from our log aggregation tool our EDR solution our MDM solution OS query and really anything else in our environment that might contain relevant information regarding the compliance state of a particular device from there we take that raw data and we run the devices through all of the compliance policies that exist and so each one of these compliance policies can result in a pass or fail and if there are no policy failures the authentication flow proceeds transparently the user doesn't know anything um about what happened in the background but if there are some compliance

failures depending on the severity of the issue depending on the the policy itself will either block authentication outright or will present a user with a series of warnings and give the user the ability to proceed with the authentication flow and so this is an example of what an actual uh compliance policy looks like and so what I'll draw your attention to is on the third or fourth line you'll notice that the action configured for this policy is block so if there's a failure we'll block the Authentication and if you notice towards the bottom we're taking some OS query data that indicates whether sip is enabled or disabled on a device and so depending on the data that we get

back from OS query will evaluate this policy as failing or passing a couple of other things that might be relevant here is um there are several different sources that can be incorporated into a comp compliance policy so if you know if we want to create a compliance policy that incorporates data from OS query or MDM solution or EDR solution all within one policy that's that's something that we can do all right my favorite slide um so one of the the issues that we've run into both with our 502 initiative as well as Mutual TLS has been related to compatibility issues with um with Native applications and so what we found is 99 of the time

if we're unable to get uh Mutual TLS to work or we're unable to get 502 to work the root cause has been the use of web views in Native applications and so a webview is incapable of accessing the keychain that contains a certificate on your device and a webview also doesn't have access to the apis necessary to authenticate someone with 502 and so this is uh if you're an app developer the only embedded browsers or libraries that you should be using within a native application are up on the screen here and so on Android you should be using a chrome custom Tab and on iOS you should be using one of the three that are

listed up there and so if there are any app developers in the room I would please ask that you stopped using webviews particularly for Federated auth where you're trying to authenticate a user against an external identity provider like OCTA or One login or Google or something like that and if you're interested in looking at a list of compiled applications that we know are not compatible with 502 in mutual TLS or if you're interested in adding to that list please visit fido.fail and with that I will open it up for questions thank you for your time all right

go ahead okay we have about five minutes for questions coming around uh it's getting recorded So if you could use the microphone thank you hello so uh I guess two questions I also implementing October my company and what is your oidc provider based off of is it like an open framework or did you guys build it from scratch your custom IDP uh so we built it from scratch oh fun so what what is the underlying flow for mtls support uh so there isn't actually any sort of mtls support in the identity provider itself the the way that this works is we handle the TLs termination on our Edge infrastructure within Envoy and the service itself is basically an oidc

provider with no authentication and so this is more of a Pinterest infrastructure specific thing but the the way that this works is the oidc provider is is basically relying on our Edge infrastructure Envoy to validate the Integrity of the certificate before routing to our uh to our service okay so I mean I guess that goes down to my second question how do you distribute a search and make sure that the cert is only tied to a specific device yeah so for certificate provisioning in our environment we only provision certificates to devices that are enrolled in our MDM and so for us MDM enrollment equals manage device have you looked at the proof of possession tokens

no okay yeah do I have any more questions hands

sorry I can't see the front side come in

uh are you doing anything that's in particularly targeted at um shoot uh session hijacking or is that covered by like other um security things that you went over earlier so for session hijacking the way that we address that specifically is is not directly related to device trust and how we're doing this the way that we address that is by requiring a 502 prompt for every application access attempt and so yeah for for 502 yeah yeah okay we have three more minutes for questions have you recorded any metrics of the success of like improving your device compliance since instituting the system and can you share uh so in terms of the the compliance uh the compliance

checking piece uh admittedly that has been deployed not too long ago so I want to say less than six weeks ago and we've started out with only a handful of policies and so there isn't enough data right now to really demonstrate how presenting users with warnings is actually affecting the compliance State there was a moment on the second week where it looked like we had like 40 percent less compliance failures and then it spiked up the next week so I would say at this point it's it's a bit too early for us to say as it relates to like presenting warnings to users for compliance failures um yeah any further questions coming

just a follow-up why OCTA you got your own IDC provider it's just for saml and apps this is a uh this is a spicy question yeah uh I don't know if I should answer that question but I I think at the end of the day it's it's um not entirely in my control and so we don't actually own from the security perspectives the security team doesn't actually own OCTA and um it would be very difficult to move off of OCTA I think um you know okay okay that'll be our last question any further questions can be asked in the lobby but I would like to say on behalf of a b-sides SF and our sponsor gift

sponsor Dorian SEC that we thank you for being here today thank you so much and thank you all yeah thanks everyone [Applause]