Episode 293: Michael Epping from Microsoft on the Single Sign On Extension

Meter is the easiest way for businesses to get internet, networking, and WiFi. Our full-stack approach combines hardware, software, and operations so that any company can seamlessly run on a reliable and modern network.

• Streamlined installation: We take on the complexities to make designing and deployments easy, fast, and stress-free. We manage the entire installation process, and provide ongoing maintenance and support.
• Network hardware, security & management: We design and build our own controllers, switches, and wireless access points. After the network is deployed, review your speed, usage, and security in one unified dashboard. No need to hire vendors in every location or have IT teams fiddle with manual configurations — everything is automated with our software.
• Simple pricing: Pay one monthly rate with no up-front costs for installation, configuration, or hardware.

---

James Smith:
This week’s episode of the Mac Admins Podcast is brought to you by Kandji. Automation in IT is a hot topic and for good reason. Automating repetitive tasks frees you to focus your skills on more strategic projects that move the needle for your organization. Kandji, the Apple device management and security platform, features over 150 pre-built automations to multiply your effectiveness and impact daily. To see how to take the repetition out of your to-do list, visit kandji.io. That’s K-A-N-D-J-I.io.

Tom Bridge:
Hello and welcome to the Mac Admins Podcast. I’m your host, Tom Bridge. Charles, how goes your eternal battle against the leaves?

Charles Edge:
Oh, it is over. The permafrost started to set in this last week. It was pretty much below freezing the whole week. So, even if it didn’t snow yet, that morning precipitation would then freeze. So, anything that’s not off the lawn will be on the lawn until spring, period, until the thaw.

Tom Bridge:
We’re expecting the hard freeze tonight. So, we pulled the last of the stuff out of the garden this afternoon. My neighbor came and dropped off a bunch of hot peppers that he had grown because he was like, “I’ve got too many of these.” So I’m very excited about that. That’s going to be salsa later this week because I brought in the last of the cherry tomatoes as well. So, totally wild. I’m getting cherry tomatoes off the plant. That’ll still be functional here on the 13th of November, but that is neither here nor there. I’m sure global warming is not at all a thing and certainly not impacting our growing seasons. But Marcus, how are things down there? You must be getting into the good part of spring.

Marcus Ransom:
Well, we did for a while. We had some really nice weather. It was 28, 29, really letting us know winter’s done. So, on the weekend, I was out trimming all of the early spring growth off the hedge we have that has a bit of a squabble with the footpath as to whose territory it really is.

Tom Bridge:
Who owns that?

Marcus Ransom:
Exactly. But of course then being Melbourne, it was raining sideways rather heavily about an hour ago and now the sun is just starting to poke through again. So, yeah, rather than leaves falling on the ground, it’s now leaves just growing everywhere. Really looking forward to getting a decent crop of vegetables we started. I know my father-in-law’s got an amazing vegetable garden that we always benefit from. So, he’s been madly propagating seeds and it’s all about to happen.

Charles Edge:
It’s amazing how much more work seasonal change has in the seasons like the spring, the fall. There’s so much to do. Bust out the hedge tremors, clean up the leaves, all the other things. But then once summer sets in, just mow the grass every few weeks and you’re golden. Or in Minnesota, shovel the snow whenever it snows.

Marcus Ransom:
The big transition challenge I had this weekend was that the temperature sensor on my pool solar heater I’m hoping has gone if that’s why it’s now clicking and flashing 88 on the LCD reader, which is apparently, it’s either temperature sensor, which is like 100 buck or 15 cents of parts if I want to build my own. Or like anything to do with a swimming pool, it’s going to be horrendously expensive and there’ll be multiple components broken, but that can work until the weekend.

Tom Bridge:
What’s amazing is it’s 28 or 29 here and you said it’s 28 or 29 there, but your pool’s now frozen over, but the lake in front of the window that I record at is frozen over. How does that work?

Marcus Ransom:
Well, it’s because our water goes down the plug hole in a different direction and we’re upside down. So, I don’t know, something like that. That’s how physics works, isn’t it?

Charles Edge:
Tom, we’ve got a great guest.

Tom Bridge:
We do have a great guest. Michael and I happen to cross paths at Objective by the Sea this year and you’d been talking with him prior to that, Charles. So, welcome to the Mac Admins Podcast, Michael Epping. It’s great to talk with you.

Michael Epping:
Thanks for having me.

Tom Bridge:
So when guests join us for the very first time, we love to do a little bit of an origin story. Before we get into what we’re going to talk about tonight, which is all sorts of awesome stuff, do you mind telling us how you ended up at Microsoft and how you ended up working in technology?

Michael Epping:
Yeah. So, I have been at Microsoft for a little over three years now. So, I’m a senior product manager in our customer experience team. So, basically, what I do is I work with large Microsoft customers to help them deploy the features that they own in their identity licensing. So, typically, Azure AD features or what is now the Microsoft Entra product family, which I know can be a little confusing sometimes, but we did recently released a new brand family. But the way that I got into this is actually that I grew up in Wisconsin and I went to college at UW-Madison for history and sociology. I did not know what I was going to do after school and I also needed to make a little bit of money while I was in college.
So, I ended up working for the IT help desk out of campus and that’s where I got my introduction to doing Mac administration. So, we had an EXERF back in the day and we used that for doing Mac Imaging using DeployStudio. We had big lab environments with lots of iMacs. I got to play around with a lot of that and help the admins who were full-time employees build out some of these lab environments. I just fell in love with using a Mac as my daily machine, doing some administration for it in the environment or in the college environment. And then after I graduated, I was like, “Well, I could try to get a job in history,” and that sounded pretty bleak.
So, I ended up getting a job as an IT consultant for a Microsoft partner back in the Milwaukee area. I did that for about eight years before I ended up making the switch from being in the Microsoft partner ecosystem to actually working at Microsoft in the identity division. Once I landed in the identity division, there was a need for somebody from our group to basically spearhead efforts to work with customers who are deploying with Macs and with Linux devices. So, basically, the way things work in our division is that there’s a developer as well as a feature PM who own a particular feature.
So, developing say the SSO extension for Macs, for Azure AD, or developing the Azure AD support for Linux that just came out in early October. I basically partner with those feature teams that are building those features and I help customers adopt them as well as help them provide feedback on those features so that we can make improvements to them.

Tom Bridge:
That’s awesome. I feel like one of my favorite times working with Microsoft, I was on a call with a developer and the PM was on the call. They wrote a graph API extension for me by the next morning and it was public. I’ve never been so impressed with… We can use a lot of buzzwords like velocity, but almost instantaneous, does this do what you want? I’m like, “Yes. Oh, my goodness.” Not only that, but deriving this state of this device is for such a large company was such mature business and technical processes, it was just amazing to see. There was a light bulb with the PM who said, “Yeah, we should do that.” And then the next morning, it was there.
So, I feel like if there’s one organization who’s got it handled and not just from that one qualitative moment in time but repeatedly, a lot of qualitative moments become quantitative. So, I’ve been pretty impressed by that and what a great place to end up a PM especially on the Mac side having come from working on that. I too worked at the help desk in college, although we weren’t big enough to have it centralized yet. So, it was one school or one building, I guess. But these days one of the biggest challenges of the era is how to securely sign people onto work devices from anywhere in the world. So, being a PM in identity at one of the biggest companies doing that is a great gig, I would say.
Apple has had Kerberos and Active Directory Support for some time and they’ve recently released frameworks and APIs for modern identity support and payloads for MDM, for extensible single sign-on. Today, we’re going to cover the SSOE extension with you hopefully to see what we can do and how we factor this into our plans for the future. Microsoft has a lot of products. For the purposes of this episode, we’re going to try to stick to Azure AD and Intune and probably the most important ones to think about in this regard because Azure itself is so expansive. Do you mind taking us through what Azure AD is?

Michael Epping:
Yeah, so this is a common topic that comes up with organizations that are just starting to dip their toes into what our capabilities are.

Tom Bridge:
That’s how you brand.

Michael Epping:
Yeah, and the branding changes can make it confusing as well, but Azure AD fundamentally is a modern cloud-based IDP. The main source of confusion I think is that a lot of times, people think that it is active directory in the cloud, which is not the case. We’re not running domain controllers on your behalf out there. We’re not operating group policies and Kerberos and all those types of things. It’s really a standards-based IDP. What that really means is our primary focus is getting applications integrated with us or getting applications integrated with us that use modern authentication, meaning SAML or OpenID Connect or OAuth.
And then protecting those applications with policies that we can construct that do things like require multifactor authentication or passwordless with technologies like FIDO is a really big initiative for us or putting policies in place that let organizations move from the more traditional network perimeter based security towards a device posture and a risk posture when evaluating whether or not someone should get access to a particular resource. So, for example, is your Mac managed by an MDM or is your Windows device managed by your organization?
If not, maybe we should block access for those things. So, most commonly, people get started with Office 365, like Exchange Online, SharePoint Online. But really, we’re a modern IDP for pretty much any SaaS application out there. On-premise applications, we have lots of tooling for. We have a partner ecosystem for integrating applications with us. So, it’s a much more modern construct than the more traditional on-premise active directory.

Charles Edge:
So something I’ve never searched for out there in the wide world of my research is how many people have migrated to an IDP at this point? My guess would be 40%. Before you tell us, because I have a feeling, you know. Marcus, what’s your guess?

Marcus Ransom:
Yeah, it’s a hard one. I would like to think it would be 60, but I think you’re probably right in it being more like 40.

Charles Edge:
Tom, if you don’t know, then you can have a guess. But if you know, then let’s point it back to Mike.

Tom Bridge:
I don’t know off the top of my head because I was just going to say there’s differing variances out there in the space, but I think it’s lower than 40%.

Michael Epping:
So I actually don’t know an official answer on that, because it is a surprisingly complicated topic. What we find is that there are a lot of organizations that have some combination of on-prem active directory and the cloud. We do have customers that are starting to do things like look towards deprecating their on-prem active directories and go fully cloud native, but that’s probably a little bit more on the rare side. What is starting to become common is customers really trying to reduce on-prem dependencies wherever possible and going really cloud first and using Azure AD or similar tools like Intune and some of the other capabilities we might have or other vendors might have and starting to break as many of those on-prem dependencies as they might have. That’s getting to be surprisingly common.

Charles Edge:
Fair enough.

Marcus Ransom:
Did you see lockdown, work from home, hybrid working result in a big uptick in people moving to that hybrid identity or just pure Azure?

Michael Epping:
Yeah, we saw both flavors. So, there were definitely organizations that needed to do something very quick tactically when COVID lockdown started. So, things like starting to move from on-premise phone systems to Microsoft teams for example. There was a huge growth in Teams usage. On the identity and the security side, there was a really big trend towards organizations shifting from assuming that all their workers are going to be in the office or 90% of their workers are going to be in the office and 10% on the VPN to realizing I’m about to have 100% of my workers remote, I better do something. So, for example, a lot of those organizations that are on Windows would do this thing called hybrid Azure AD join.
And then in their cloud policies, they could say instead of requiring my worker to come from a corporate workplace, I’m going to require that they’re on a hybrid Azure AD join workstation and then I don’t need to have 100% of my org on the VPN because most VPNs aren’t sized to handle that. As time went on and COVID continued to linger and we realized this isn’t going to be like a one-month or a two-month thing, we started to see customers transition towards cloud native or cloud first. So, again, on the Windows side, I know of at least a couple organizations that decided to switch all of their Windows machines from being hybrid Azure AD join to just being purely Azure AD join and Intune managed for example.

Charles Edge:
So when you look at the motivators that are out there, I mean we just talked about a big one, but what are some of the other big motivators for folks to slide away from legacy on-prem identity towards more cloud IDP?

Michael Epping:
There’s a couple big things. One is that on-prem does not offer the types of security controls that you really need in the modern threat environment, for lack of a better word. There’s a big industry push towards zero trust, which is often seen as a industry buzzword that a lot of vendors use, but it is starting to become industry standard like NIST has a zero trust framework now and a lot of vendors are trying to see how they align to it. So, from the Microsoft perspective, the way we look at doing security in the modern world is you need to do a couple things. One is you need to strongly authenticate your end users. So, that’s doing things like requiring MFA.
You need to make sure that their access is coming from a trusted device, and that typically, it means getting those devices enrolled into an MDM and then validating with the MDM that the device is happy and healthy. And then you also need to assume breach, which means least privilege and making sure that if someone is compromised or their device devices compromised, that that breach doesn’t spread everywhere. It’s very difficult to do for most organizations in an on-prem environment, because if devices are compromised in an on-prem network, it’s very common for attackers to be able to pivot to other systems or compromise additional internal resources. Whereas the cloud has tooling that’s built for a more comprehensive security framework for the modern world.

Charles Edge:
So part of the identity picture for any platform, let’s call it, is the client that makes it work. Speaking of the traditional active directory type of environment, that would’ve been the DS config AD type of framework or the active directory framework on the Mac. But as we get into Safari, they’ve had SAML support for a while speaking of modern identities, but I don’t feel like we had the localized resources to act as that IDP client.
But I do feel like while they’re building frameworks, whether it’s an IDP or any other method of getting that configuration set on a device, it becomes up to getting that. So, I feel like part of this story is the Microsoft Authenticator app, which can be used for a few different things. So, it’s almost a misnomer to say it’s a directory service client or an IDP type client, but I guess how do you see the Microsoft Authenticator app playing into this story?

Michael Epping:
So the Authenticator app has a number of different capabilities. So, for anybody who’s not aware, we have the Authenticator app for both iOS and Android. There’s a few things it can do on iOS that it cannot do on Android because of some of these frameworks we talk about that Apple’s built. So, most fundamentally, the Authenticator app is a second-factor app. We can do push notification based MFA or we can do OTP code based MFA with the rolling six digit codes. Beyond that, it can also be a passwordless authenticator, where instead of it being used for just second factor, we can actually use it as both a first and second factor authentication method. So, that’s something we try to push customers to do.
Beyond that, it actually has some additional capabilities as well, one of which is helping facilitate SSO on iOS devices. So, for apps that are using Microsoft’s authentication libraries, which would typically be things like Outlook, Teams. If you build your own applications and you want to use our auth libraries that are open source, you can do this as well. Those apps can hook into the Authenticator app directly and it can provide SSO capabilities for those apps, where basically like a directory services client in the past would’ve held Kerberos TGT and used that to do SSO and get tickets for on-prem active directory. The Authenticator app can do the same thing with a different resource than a TGT called a primary refresh token, which is basically just a cloud TGT fundamentally.
There’s a lot of differences, but the core concept is very similar. Beyond that, the really special thing that Apple’s done on their platforms is they’ve actually given us the ability at the OS level to hook other applications that don’t use Microsoft’s auth libraries into that Authenticator app PRT as well and get SSO for things that are not using Microsoft’s libraries. That’s a really important capability for us on both iOS and Mac OS.

Marcus Ransom:
That’s what they call extensible single sign-on.

Michael Epping:
Yeah. So, the Apple feature is extensible single sign-on. The way that this works is you can basically deploy a profile through your MDM. If it’s an iOS device, you’re going to basically create a profile that says for Microsoft’s authentication URLs, which are login.microsoftonline.com, sts.windows.net. There’s a couple other ones from our docs, but those are probably the most important ones.
You basically say anytime an app tries to go to these URLs to get a token, like a modern auth token, instead of actually loading a webpage, redirect that authentication to the Microsoft Authenticator app, which will use its PRT on your behalf to go get you that token. It just hands it right back to the app. This makes it so that apps like Safari or the Salesforce app or the Workday app or anything that’s using Apple’s native system frameworks, they can do SSO as well. So, this is basically how it works on the iOS side. On the Mac side, we can do the exact same thing, but we use the Intune company portal app instead.

Tom Bridge:
So in those circumstances, that’s actually a place where as soon as you get redirected to that URL and no matter where you are, as long as it’s done through a URL session, so we’re not necessarily talking about Chrome browser, we’ll set aside Chrome and put it in a little box for right now. But when you do this in Safari or whether you do this in a native app or an app with a native browser capability that uses Apple’s web kit technologies, that’s a place where as soon as that URL is called, the code is just handed off directly to either the authenticator application or the company portal app for processing. That’s when Microsoft’s code runs to essentially validate your identity.

Michael Epping:
Correct. We basically use that primary refresh token on behalf of the user on that device to say, “John Doe wants to sign in to Exchange Online and they have this valid PRT. Let’s get them their access token for Exchange Online and then hand it back to the browser so they can go to Outlook web app.” The user never gets prompted.

Tom Bridge:
Which is the best part of all of this, right? It’s a seamless process where you can go in and it almost feels a little bit like magic or cheating or cheating magic. I mean magic cheating. I don’t know. But I think that there’s a lot of functionality that’s in these moments that can feel good for the user because the admin knows that they’re going through this authentication cycle. So, that primary refresh token is used to get not just an auth token, but a new primary refresh token. So, those processes, they’re cyclical and so that you can essentially use those actions to create good cycles of authentication and authorization without having to do a lot more extra work.

Michael Epping:
One of the big challenges that a lot of our customers have had is that especially on the Macs, they tend to see their users get prompted for authentication a lot. A lot of security teams look at that and say, “Authentication prompts are good. If I’m making my users do MFA a lot, that’s good.” We would actually argue that that’s not the case and we have a lot of data to back that up from running these massive cloud services. But if you overprompt your users, they’re going to become trained to do things like just approve MFA prompts without thinking about it or providing codes like OTP codes to websites that are malicious. There’s a lot of negative downsides to not actually having single sign on.

Charles Edge:
Apple makes it so easy to provide that because if you get it in iMessage, you just tap one button and you’ve now submitted that code. I have to admit, having not looked at it at times, I mean I know I always sent it, so if I got something it was like I didn’t send that, I’d be weirded out by it. But if I log into the Apple developer portal, I don’t think I ever actually look at that. I think I just get it and hit the button. So, it’s like, “Well, why not just put hit yes here and not actually have any atomic operation underneath it other than just hitting the yes button?”
One thing about the Microsoft Authenticator app, I feel like I first used it with a completely different… I think it was a bank that I was logging into and I had already used the Salesforce authenticator app, so I knew this motion that I was going through, but I think at first, I just thought it was another authenticator app, but it’s used for consumer authentication and authorization as well as that enterprise piece. What other uses did the SSOE extension, which I guess I shouldn’t call it SSOE extension. Never mind, I’m not going to get lost in the words behind the acronym.

Marcus Ransom:
It’s a whole other episode.

Charles Edge:
Yeah, we should do that for New Year’s Eve, just have a bunch of shots and try to go through acronyms that make no sense.

Tom Bridge:
How many times we can make it through the platform deployment guide without…

Charles Edge:
Right. So, I guess, you mentioned the refresh token. Apple does deal with refresh tokens a little differently than any other vendor that I’ve worked with and I do have a little code level experience with this luckily or regrettably, but what other uses did Apple’s SSOE give your developers and/or third-party developers vis-a-vis the APIs that you guys then expose to them?

Michael Epping:
Yeah, the big thing that Apple provided was the ability for that SSO experience for things that we don’t have under our control. We can do all sorts of magic with our apps like Outlook and Teams. We can build integrations between those and the Microsoft Authenticator app, but only Apple has the power to give us that same capability for things that don’t have Microsoft code running in them, which is all sorts of stuff for lots of legitimate reasons. We make code libraries that we think people should use for authentication, but not everybody’s going to adopt those and that’s totally okay.
So, Apple, because they own the system itself, can give us those same sorts of capabilities to provide SSO with things that don’t use our code. That’s really the power that they have that they’ve enabled for this entire ecosystem, where now, the administrator on a corporate device or a school device, some environment where the device is under management, you can say, “I want SSO for everything that’s capable of doing SSO.” We can get into Chrome on Mac because that’s a hot topic, why that doesn’t do SSO. But for everything that’s capable of doing SSO, I want it to participate in this SSO scheme regardless of whether or not it’s a Microsoft app or something else.

Tom Bridge:
Yeah, I do feel like maybe 80% of apps that I’ve noticed that provide, whether it’s a consumer login experience, login with Apple, login with whatever, a federated login experience or a federated login experience masked almost as a consumer login experience like login with Apple when you’re actually logging in to an Azure AD client, I feel like most use something like Auth0 and developers wouldn’t need to pay that Auth0 tax to get identity for freeish as an API I guess if everyone was standards compliant, but they definitely don’t seem to be.
Even if they helped write the standards, they’re still not standards compliant, which is always amusing even though that developer probably left a decade ago, whatever. So, there are two types of transactions here. The redirect where the request is redirected directly to the extension and the credential where it can use a variety of authentication types since Redirect is OIDC, SAML, and other modern auth types. Can we assume that that’s used here?

Marcus Ransom:
Yeah, the Azure AD flavor of the SSO extension is the redirect type. We’ve never built a credential one, which typically you would use like cert based auth or something for that. The way that we’ve done this is we’ve always used Redirect and so the way that it works for an application, if you take a Safari again as an example. If the user tries to go to Salesforce and that Salesforce instance is integrated with Azure AD, they try to go to Salesforce. Salesforce says you need a token from Azure AD, and so their browser gets redirected to login.microsoftonline.com.
At that point, the network stack on the Mac or the iOS device actually intervenes and redirects that web call to our broker application, which again uses that PRT, gets a token and hands it back. That’s why it’s called the Redirect type.

Tom Bridge:
I love that you said that you made the correlation and obviously the technology is wildly, although not as wildly as some people might stipulate different than Kerberos, but I love that you mentioned, “Oh, it’s a lot like a Kerberos TGT.” I mean programmatically, it philosophically was based on that. The cert based auth that you mentioned derives back to X-500 and X-509 credentialing in these type of environments way back in the days. So, I guess one thing that is wildly different though is MDM is required for this, if I’m not mistaken, correct?

Michael Epping:
Yes. That’s a requirement from Apple and I think there’s a really good reason for it, which is intercepting network traffic is an incredibly dangerous capability. So, if you think about signing into your bank for example, you probably don’t want any application on the system to be able to say, “Hey, I’m going to intervene at the network layer and intercept that traffic and read your bank statements or do a post call to your bank and do some transaction that way.”
So, Apple requires that this is done by an MDM, which means an administrator needs to deploy this policy. The assumption there is that the administrator knows how to configure this and they’re not going to do something malicious like define URLs that they shouldn’t be doing this with. So, our documentation has the full list of URLs that you should do this redirection for and you really should not go beyond those. At no point should you be putting in mybank.com into the list and trying to do that redirection. That would be very bad.

Marcus Ransom:
Those are known good endpoints type of-

Michael Epping:
Yup.

Marcus Ransom:
Got it.

Tom Bridge:
So if I can pause for one quick second and just basically ask the question, what would happen in that case? If I put mybank.com into that link, what’s the end result in that case?

Charles Edge:
Well, you don’t have the certs.

Tom Bridge:
I don’t have certs or anything else to do those things.

Michael Epping:
So our extension’s not designed to filter people’s bank accounts.

Charles Edge:
Well, I’m glad that got clarified.

Michael Epping:
If you did it with our extension, nothing, you’re probably just going to see something horrifically broken. Your sign-in into your bank will fail or something like that. The real danger is if your administrator is a malicious admin. They could write their own application that does the same brokering thing as our extension and they could redirect that traffic to their application and then all bets are off. It’s whatever their application’s capable of doing. So, it’s very important that your administrators are careful and consider it when they configure these things.

Charles Edge:
One thing I love about this technology is I’ve seen circumstances where a developer putting some bad codes somewhere and allowing a cookie to be used or using a cookie somewhere that it shouldn’t have been, that a token should have been used or something like that or not refreshing tokens causes the ability to just swap that link like Tom just mentioned. Meanwhile, when you get into the code behind whether it’s logging with Apple or the way that the claims work with Azure AD, it takes away the ability for a developer to fat finger something and give access to the wrong thing.
Going back to that Kerberos example, it’s like, “Oh, I tried to access that file server but I don’t have a TGT,” or “I tried to access that file server but I’m the wrong username who doesn’t have that TGT associated with my username.” You could have tapped into where that KNT store was to continue using the TGT, but I’m going to blame Michael for that analogy. You could have done that but you didn’t have access to all the right information. I might not trust some of the third-party web developers to do some of this stuff, but I trust the IDPs to force them to do it right in order to process the transaction, if that makes sense.

Michael Epping:
The IDP from our perspective and I work for an IDP vendor so maybe we’re biased, but the IDP is the right place to make that decision in the modern world. It knows who the user is, who the device is, what the application is, whether or not that user is supposed to have access to that application. If they do have access, what role are they supposed to have in the application?
When you send that PRT to the cloud saying I want to get a token for whatever the app is, Azure AD, you can configure policy to say in this particular circumstance I’m going to block access or I’m going to give the user a limited session or I’m going to give the user a token that tells the app only give this user read capabilities. All that decision making should be done on the IDP side. The PRT just like ATGT is really just an authentication artifact that you’re using to go talk to the IDP and see if the IDP will grant you that access. But all the configuration of security policy should really be done in Azure AD if that’s what you’re going to be integrating your applications and devices with.

Tom Bridge:
Well, and that’s one of the things that I think gets lost a lot of the time is that I feel like that what we don’t talk enough about is that there are two separate actions that happen here. One is an authentication which says, “This is Tom Bridge.” The other one is an authorization, which is where the IDP says that this point, “Oh, yeah, that is Tom Bridge. That is Tom Bridge coming from Tom Bridge’s work laptop whose shape and size I know and whose state I understand in such a way that allows me to make the authorization decision.” So, authentication and authorization are two things that are frequently used it interchangeably when they are definitely not the same thing.
And then there’s other layers like, “Oh, I can give certain metadata about the attributes for that user to this third-party app,” which anyone who’s logged into a web app that hasn’t figured out how to deal with login with Apple yet and sees their private Apple email address as a string in their login window is amusing. Yeah, I very much trust because there’s half a dozen real IDPs out there that are granting access to most of corporate America/world and let them do what they’re especially good at and let crappy web developers like me integrate with them.

Marcus Ransom:
But I think the comment that you made, Tom, is really important as well in that authorization should not be all and end all, because it may be that today, you have access to this application but congratulations you get promoted and so you no longer need to deal with a particular application. The organization can save money on licensing or they just don’t want you poking around and seeing what that team is doing now. So, you can still be an authenticated user but no longer be authorized to do things.
I think so many legacy ways of doing things were just a single point in time where once you were given the keys, you could have at it. AD binding in Mac OS was very much like that. We see people saying, “We have to bind into AD because security. Okay, now the person’s in. They disconnect their Wi-Fi or they’re at home and they’re not on the network. You can no longer validate are they really who they said they were or you can’t decide to lock things down a little bit or minimize the blast radius if something’s going wrong. I think that as we see lots of high profile examples of data loss, realizing how many holes there are in the old ways of doing things.

Tom Bridge:
I don’t know that any authentication and authorization from a modern IDP really protects against… I mean I’m a huge proponent by the way, but I don’t know that of the last few dozen big security issues that switching and making sure that only the people that are allowed to have access to insert vendor name here does a ton.

Marcus Ransom:
If you’ve got an unsecured API available publicly on the web, it doesn’t matter how good your identity management is on your clients, if you’ve just got a massive hole somewhere.

Charles Edge:
Yeah.

Speaker 6:
Deploying, managing, and protecting Apple devices at work shouldn’t be difficult to require several solutions. Mosyle is the only Apple unified platform for business. By combining enhanced device management, endpoint security, internet privacy and security, single sign-on and enhanced and apps management into a single apple only platform, businesses can now easily and automatically deploy, manage, and protect their Apple devices with one solution and add an affordable price. With a solution for every business size and the best support in the market, request your free account today and see firsthand why Mosyle is more than an Apple MDM. Mosyle is everything you need to work with Apple. To learn more, visit business.mosyle.com. That’s business.M-O-S-Y-L-E.com.

Charles Edge:
Speaking of authorizing an action, the MDM uses team IDs to allow apps to load the extension and then manage app config to push managed information into the app, correct?

Michael Epping:
Yeah, so there’s a MDM profile that’s required and it has a few required configuration parameters that have to be in it. So, one is the list of URLs. Another one is the team ID of the application that is the broker. So, again, on iOS, it’s the Microsoft Authenticator app. On Mac, it’s the Intune company portal application. Again, you don’t have to be using Intune as an MDM. You have to be using an MDM. Intune company portal just happens to be the thing that knows how to do PRT stuff on a Mac. And then you also have to define the bundle identifiers of the applications themselves that are allowed to participate in the SSO framework. So, if you wanted to, you could say Safari’s not going to do SSO. I wouldn’t recommend that, but you could.
You could say Outlook and Teams will and the OneDrive client and whatever else, but you have to configure all these things. And then we also have a couple other parameters that we recommend configuring, like one that says that if you are using Safari or another application that’s not one of Microsoft’s that you can bootstrap and get the PRT from inside of that application.
That one’s really important for customers that are using non-Intune MDMs, because your users probably don’t know what the Intune company portal is and you never need them to open it. So, this facilitates that. There’s a couple other things like this, but you have to define all of these things and it’s all laid out in our documentation. But if you don’t get this quite right, things generally will not work.

Marcus Ransom:
So you raised an important point there, which is something that I’ve seen lots of people going down this path getting a little bit confused by. So, just to be clear, the single sign-on extension piggybacks along with the install of authenticator and company portal. The users aren’t really interacting with those applications to be able to use this functionality, are they?

Michael Epping:
Correct. It’s optional. You can have them use those applications if you want. That’s fairly common if you’re using Intune as your MDM. But I talk to customers all the time that are using Jamf Pro as their MDM for example. It’s very, very common for them to say, “My users don’t know what Intune is. We don’t use Intune. I don’t want them to have to open the Intune company portal.” It just needs to be installed and that’s it. If you follow our recommended guidance and we have a doc that’s specific to how to do this with Jam Pro, the engine company portal will have to be installed so that it can deliver the SSO capabilities that it has the code for.
But if you configure things correctly, the first time the user opens Safari and tries to sign into something or the Outlook app or the Mac Mail app, they’ll be asked to bootstrap the SSO extension in a little web frame. That will get the PRT and they never need to open the Intune company portal application.

Charles Edge:
So when we think about shared devices, because this is a very interesting opportunity here. So, when there’s a device function for an iOS device, a shared iPad, those situations, is there the ability to use the single sign-on extension and authenticator in that case?

Michael Epping:
Yeah, so the Authenticator app uses the single sign-on framework for what we call shared device mode on iOS devices. You can do this on either phones or iPads. It works in both cases. Basically, if the user opens an application like Safari or again like Outlook, Teams is a really popular one with some of our retail customers where they use teams for communication, the user can sign into their account there and that will bootstrap their PRT and they go to their next application. They’re already signed in and this provides a nice smooth SSO user experience. And then if they sign out of one of these applications, it’ll dump that PRT and the device is ready to get picked up by the next person and they can continue on from there.

Marcus Ransom:
So you mentioned before putting the Chrome browser to one side. So, I know initially the SSO extension only worked with the Safari browser. So, what’s the current state of browser compatibility with other browsers we see out there and what’s the challenges with the ways different browsers work?

Michael Epping:
So it’s actually pretty simple on iOS because only Apple’s browser code can really run on iOS. There is a Chrome browser on iOS, but it’s using Apple’s web technology under the hood. So, the SSO extension from the testing I’ve done actually does work in Chrome on iOS, but the scenario is quite a bit more complicated on Mac OS, where the browsers have much more free rein to be implemented in different ways. So, on Mac OS, Safari is the only browser that uses Apple’s native web frameworks as you would expect, because other browsers want to have their own rendering engines. So, Chromium-based browsers are using Chromium rendering engine. Only Safari is really using the WebKit one in most cases.
So, Safari works out of the box. Apple ensured that was all well and good. Chrome and Edge are the other two really popular ones that we hear people bringing up, especially in enterprise spaces. The Edge browser today has some limited integration with the SSO extension and we achieved that by putting our auth library into Edge. So, that’s a special case where because we control the code that goes into Edge, we can work with the Edge feature team to do some of that implementation. We are working on further enhancements for Edge to integrate it even more tightly with the broker. So, that’ll be coming in the next couple months hopefully. I don’t have exact dates quite yet. Chrome is the other really, really popular one that I hear from customers all the time.
I need SSO and Chrome. I totally feel their pain, but the limitation today is due to the fact that Chrome uses their own web rendering engine. They don’t use Apple’s network stack really for their web calls. So, the OS can’t do that thing where it intercepts the traffic and redirects it to the broker. So, either Google will have to find some way to snap to using Apple’s system APIs for web calls, which I don’t know if that’s super likely, or maybe Microsoft has to build a browser extension for Chrome to integrate it with our broker. But as of today, there is no Chrome support, there’s no Firefox support. Other browsers like Brave I believe have some of the same limitations.

Tom Bridge:
I think this is an important dividing line between modern auth and archaic or legacy or whatever we want to call it auth. It was built for web technologies in the beginning. I mean the OAuth guy was at Twitter. The SAML stuff was XML and Built Web first. Here we are bastardizing it to work inside apps, but it’s working inside apps because they have remnants of WebKit in them or as you mentioned with Edge, you guys control the entire code base for both. So, you can put that authentication in.
If you were using, heaven forbid, the Salesforce or some of the other IDPs that are out there that maybe people don’t know are IDPs but really totally are for certain types of environments, then they would have to put their code in there because it’s not all RFC compliant at that point because it’s routing or brokering through that SSO extension. Or if it’s a consumer IDP experience through one of those login with GitHub login, with Apple login, with insert thing here.

Michael Epping:
Yeah, it’s becoming increasingly common for desktop and mobile applications to use web technology for authentication and authorization. So, again, for example on Mac and Windows, we do see VPN clients trending towards supporting SAML rather than doing older forms of authentication like Radius and things like that. As they start to adopt SAML technology, we can do these types of SSO things with them. We can have that VPN client spin up and load a Safari web frame and do the whole SSO song and dance on behalf of that VPN client. So, these things are starting to happen in the industry, but there are lots and lots of complexities here when things are not using the native web frameworks on a platform, like is the case with Chrome on Mac OS.

Marcus Ransom:
I know I had one customer I was working with where I think, fortunately and conveniently, everything they were doing was using SAML and it was one of the first times I got a really nice implementation of the SSO extension into the world. It was just like, “Oh, yeah, it works with that. Yup, works with that. Yup, that’s fine. That’s fine.” A few edge cases with Chrome that they managed to work around just fine because it just meant they needed to authenticate in there, which worked beautifully.
But it was understanding what it looks like when and why there is the transition towards using these new authentication flows and realizing just how easy it was to get on with working on these machines and how easy it was to apply security and certainty and knowledge of what was going on in the machine, certainly compared to some of the old legacy ways that so many organizations is still rusted onto.

Tom Bridge:
So one of the interesting side effects of using a single sign-on extension is that it doesn’t matter whether or not you’re in Cognito mode or you’re in a Safari private browser window. So, are there any suggested workflows for users who need to authenticate to multiple domains with multiple accounts? Thinking here about Dev and Sandbox, I always think that when I was at private practice, we would frequently have multiple domain control or multiple IDP logins depending upon what framework did I need to be in. Did I need to be in super admin mode or did I need to just be Tom Bridge? So this is one of the challenges that’s there with SSO or SSOE rather.

Michael Epping:
Yeah, and it’s a problem with SSO across platforms in general. We hear this from admins all the time where they’re like, “I have multiple identities. I don’t want SSO. I want to be prompted to sign in with the right account.” So it’s the reverse problem that the average end user has, which is I don’t want to get prompted. So, in the case of admins, what I typically recommend for people is use Edge if you can. The reason for that is because Safari SSO actually works a little too good for admin scenarios. So, it’s typically going to try to sign you in very aggressively as the account that you’ve set up for SSO. One of the nice things about Edge or Chrome is a good use case as well is they have the capability of doing different profiles in the browser.
In the case of Edge, only the one that’s signed in with the same account that you provisioned the SSO broker with will use the broker. On my Microsoft Mac that I’m on, I have my Edge profile that I’m signed into with my Microsoft account and that one talks to the broker. And then I have another one that I use for my lab account and it’s just a whole separate browser window with separate picture in the upper right corner. Chrome has a similar construct, but in the case of Edge, you can have at least one browser window that’s doing SSO, and all the other ones, you can have it just not participate.

Marcus Ransom:
It’s pretty easy to brand those browser windows as well. So, you can easily work out which thing you actually need to click into to be Sandbox or Dev as well.

Michael Epping:
Yeah, I have mine with different colors. On my work one, the tabs go on the left side. On my lab one, the tabs go across the top and that way it’s very easily distinguishable at a glance.

Charles Edge:
My production environment is red and my non-production environment is whatever other color that’s dark and dreary like my soul that I want.

Marcus Ransom:
If I scoot up in this window, it’s going to hurt is what you’re trying to tell us.

Tom Bridge:
I think some of the stuff that we’ve been hitting at the edges of is this telemetry versus privacy space where it’s up to the IDPs to… I don’t want to say cloak because we’re getting close to Keycloak, which is a broker, but to mask some of that information that they have about the personal identifiable stuff about people and keep it just to them and not hand that information off to someone who shouldn’t be allowed to have it, a third party who you may have just clicked in a field and said, “Yes, log in with Facebook and give all of my information to whomever’s app that is,” but instead let’s hold some of that back.
I think one of the things that’s really interesting using a tool like Keycloak as your own broker in the middle to look at some of these transactions and see, “Oh, what am I allowed to see that any app that’s hitting this thing with whatever authorization capabilities that that app’s been given can then see about my users, if that makes sense?” If let’s say 40 or 60 or however many percent of organizations haven’t moved into the IDP space, this is one of those places where I think as a savvy Mac admin, that’s potentially the next career step for some, because again, I think in the Mac space, we have to know more. You mentioned logging in, if you’re using the full Microsoft stack. If you’re a Windows admin, you don’t need to know a whole lot of this stuff.
But if you’re a Mac admin, all of a sudden, you need to know how to put that team ID and that exact place in your Jamf Pro or whatever environment in order to now give this thing access. And then potentially how to dig under the hood and troubleshoot some of these transactions that maybe the developers hadn’t anticipated because Apple does it differently than Chromium or whatever insert operating system here. So, I think the most important thing for listeners would be here’s some of these new things to think about for your environment.
But as an ancillary, like 5, 10 years ago, a lot of people moved into InfoSec out of the Apple space or before that maybe into managing other platforms or directory servers. This is another one of those places where every company over a certain size is going to need one or three or five people who are doing DevOps type work on these systems to automate the transactions between various systems. Because if all of your authentication and authorization is going through one tool, then that’s job security, I guess.

Michael Epping:
Really large customers, we do see dedicated identity teams and they’re thinking about these types of problems. When you integrate applications with Azure AD, again, one of the things we try to get people to think about is some of those zero trust principles like least privilege and assume breach. So, in the case of a SAML application, you might integrate it with Azure AD. And then when you configure the claims that you’re going to put in the token that the user’s going to provide to the application, they only need to have a small set of claims like what’s the user’s name, what’s their email address, what’s their employee ID, that type of stuff. You wouldn’t send Salesforce’s users like salary information if you were storing that in the directory.
So, having teams that are thinking about these types of problems when they’re doing application integration with an IDP like Azure idea is really important. And then being really considered on our side when we create features is also really important. We don’t want to create features that make it very easy for people to do the wrong thing. A good example is in the Microsoft Authenticator app, again, one of the features that we actually have is you can do geolocation based policies where you can say a user has to be in Switzerland in order to access this application where they do bank transactions. The reason you might want that is because the user’s licensed to do banking transactions in Switzerland.
We use GPS signal from the phone using Microsoft Authenticator app to do that. When we built that feature, one of the things we had to think about is, “Are we going to show GPS coordinates to the administrator?” The answer to that turns out is no, absolutely not, because we don’t want to enable administrators to stalk their employees. So, when we show you log, we throw away the GPS information once we just make a decision about if you’re authorized or not. The reason for that is because the only thing the administrator should really care about is, “Did the user satisfy the policy that says are they in Switzerland or not?” The administrator should not know exact geolocation for that particular user, so we didn’t put it in the product.

Charles Edge:
Thank you on behalf of everybody out there, because there are so many times where we get those requests as product managers where it’s just like, “Hey, I want to know X, Y, and Z about my user.” We don’t stop to think, I mean, many people don’t stop to think, “Is that okay to know? What’s the possible negative consequence of an admin, maybe somebody who’s not scrupulous knowing this information?”

Michael Epping:
And then you have a customer say, “Well, we’re trying to recover employees who have been abducted, so we need the GPS coordinates.” You’re like, “Oh, man, this just broke my brain.”

Charles Edge:
I mean, that’s the weighing, right? You’re weighing the positive and negative use cases.

Marcus Ransom:
As long as the default isn’t assuming they’re recovering employees who have been abducted when really all they’re trying to do is sell someone tickets to a sporting event or something like that.

Michael Epping:
Oh, when someone asks me about it, they were literally the outsourced agency that recovered the employees. So, I was like, “Okay, I can believe you.”

Speaker 7:
Here at the Mac Admins Podcast, we want to say a special thank you to all of our Patreon backers. The following people are to be recognized for their incredible generosity. Stubacka, thank you. Adam Selby, thank you. Nate Walk, thank you. Michael Side, thank you. Rick Goody, thank you. Mike Boylan, you know it. Thank you. Melvin Vives, thank you. Bill Stites, thank you. Anush Storebill, thank you. Jeffrey Compton, M.Marsh, Stew McDonald, Hamlin Crusin, Adam Berg, thank you. AJ Petrosca, thank you. James Tracy, Tim Perfet of two canoes, thank you.
Nate Sonal, Will O’Neill, Seb Nash, the folks at Command Control Power, Stephen Weinstein, Chad Swarthout, Daniel McLaughlin, Justin Holt, Bill Smith, and Weldon Dodd, thank you all so much. Remember that you can back us if you just saw head out to patreon.com/macadm podcast. Thanks everybody.

Marcus Ransom:
So the current SSO extension has been around for a little bit, but it is in preview. So, what does this mean to organizations who are using it or who are wanting to use it?

Michael Epping:
Yeah, this is one of the topics I unfortunately have to cover an awful lot when I talk to customers is, “What does it mean for this thing to be in preview still?” So it did come out around March of 2020, I believe. So, we’re coming up on three years and I think the first thing that’s important to understand is what does public preview mean for features from Azure AD. The life cycle for features that we build is typically private preview first, where we build it internally, test internally with Microsoft’s IT department and maybe some select customers, and then we release things to public preview. Once something goes to public preview, it is fully supported to use it. So, if you deploy it, you can call Microsoft support through your normal support channels and we will support you.
If there’s issues, we will help you through them as best we can. But when something’s in public preview, we still reserve the right to make changes to it outside of our normal deprecation life cycle. There are some rare cases where we may actually claw a feature back. I don’t think we’re going to do this with the SSO extension, but it’s happened with other features in the past that were ill-conceived. We release them into the marketplace and they’re just not right and we need to go back to the drawing board. That’s happened in the past. So, that’s a reason why we might keep something in public previews. We’re validating, “Is this something that’s actually going to take off in the market?”
And then the other thing that we do when things are in public preview is we iterate on them based on customer feedback. So, with the SSO extension that we have today, the big problem that we’ve had is that it doesn’t behave quite correctly when you use it in combination with a conditional access feature in Azure AD called sign-in frequency, which is a session control you can use in your conditional access policies. You might do this if you wanted to put a policy in place that says, “Users have to do an interactive sign in every 12 hours or every three days or some period of time.” This essentially breaks the SSO extension and makes it not do what we intended, which is provide a nice user experience.
The user basically just goes back to the same user experience as if they didn’t have the SSO extension deployed at all. So, we’re working on trying to resolve that situation so that you can use both sign-in frequency and the SSO extension. Once we do that, then we think we’ll be about ready for GA. So, that’s engineering work that we’re still doing. When I talk to customers, I basically tell them, if you’re deploying sign-in frequency policies to your Macs today, you won’t get much of a value out of this, but most customers don’t do that.
Most don’t use sign-in frequency conditional access controls. So, for those customers, I typically tell them it’s pretty safe for you to do this deployment. I would highly recommend it as long as you’re okay with features that still have that preview tag, which some are and some aren’t.

Marcus Ransom:
So they can still get support for it, because I know that’s one of the things I’ve heard people say, “Oh, no, we can’t use that because there’s no support for it because it’s in preview.” So that’s a misconception, isn’t it?

Michael Epping:
Yes. Some of the complexity there is that it differs by Microsoft Product Group. So, for the identity product group at Microsoft, public preview items are supported to use. We just reserve the right to make changes to them. So, the SSO extension for Mac and iOS is fully supported by Microsoft.

Marcus Ransom:
So you also mentioned conditional access there. So, just to clarify, it’s just the sign-in frequency, if I’m using the right term, of conditional access that causes issues or complexity or canceling out here. Whereas other areas of Azure conditional access are still a really valuable part of your whole security and identity and trust ecosystem, aren’t they?

Michael Epping:
Yes. There’s two other very edge case things that can sometimes cause issues that I’ve seen. One is a very old control that we don’t recommend people really use anymore called Remember MFA. That’s in a really ancient MFA portal that a lot of people don’t know is still around. And then the other one is if you expire user passwords really, really frequently, in short timeframes, if your users have to rotate their passwords on a weekly basis or something like that, that can wreak havoc.
But almost all the customers I’ve seen who had issues with the SSO extension are the ones using the sign-in frequency component in conditional access. But as long as that’s not you, you can use all the other conditional access stuff like the compliant device policies, the location policies, the risk policies. That should all work fine.

Marcus Ransom:
Certainly, from a Jamf, experience I’ve seen the SSO extension improve the experience of doing that conditional access registration as well. So, realizing how easy you can make the onboarding process and the customer experience when you’re chaining together all of these various different pieces of the big behemoth that is Azure AD.

Michael Epping:
Yeah, the Jamf experience and other MDM experiences are generally improved by the use of the SSO extension, especially if you’re integrating Jamf with the Intune configuration or eventually the compliance API that I think Jamf is building support for. It’s going to make the user experience for the end user a little bit smoother when you’re integrating with those things. Our stance is generally, if you’re doing MDM management of your Macs, we think you should deploy this thing. Especially once we get to GA, that’s what we’re going to trumpet is if you’re managing Macs with MDM, you probably don’t have a good reason not to do this if you’re using Azure AD. If you’re using a different IDP, then go talk to them.

Tom Bridge:
We’ve been talking here for now a good long while and we’ve been talking about the single sign on extensions without yet talking about the new feature that Apple released this fall called Platform SSO. Platform SSO builds on top of the single sign on extension that we have been talking about here, but it does some interesting things. How does Platform SSO change the equation here?

Michael Epping:
Yeah, so the biggest challenge with explaining the SSO extension to organizations that I talk to is that they still have to find some other solution for managing the identity that the user actually signs into the Mac. With all the stuff we’ve been talking about where we can provide a nice smooth end user experience that all assumes that the user’s already signed into the device, but if your organization is using LDAP bind to an on-prem actor directory or using the Apple Kerberos integration or you’re using Jamf Connect or whatever it might be, you still need those things because the SSO extension didn’t offer the ability to actually log you into the Mac using a credential from an IDP.
The idea with platform SSO, which is the new capability Apple announced at WWDC for macOS Ventura is that the SSO extension in theory will be usable at the lock screen as well. So, basically, if you extrapolate that, it would be instead of bind to an on-prem LDAP directory and validating the credential against an on-prem active directory, which is not really a modern way to approach things, given that a lot of devices don’t have line of sight to an on-prem active directory anymore, you need to replace that with something which is signing into the device using a cloud credential like Azure AD credential or credential from a different IDP. So, basically, what Apple’s providing with platform SSO is an opportunity for vendors that make these types of SSO extensions to extend them to the Mac lock screen.

Marcus Ransom:
Not just the lock screen but the login screen.

Michael Epping:
Yes, sorry, the login screen, the lock screen. The basic capability will be if I sit down at a Mac and it’s not logged in already, I might be able to use a credential that’s validated by cloud service natively by the OS rather than needing to integrate with an on-prem LDAP directory or just using local credentials. Like my Microsoft Mac, I just use local credentials to sign in. I’m sure MSIT would prefer that I use an Azure ED account to do that.

Tom Bridge:
So platform SSO gives you the opportunity to at that point decorate the local user account with an IDP interaction. So, that when the password changes at your IDP, you can be forced to reauthenticate to the Mac and update the password for example.

Charles Edge:
You can force a second factor to log in or you can there’s at least seven or eight flows that are pretty easy to come to mind off of that integration I guess.

Michael Epping:
The way we look at it is in theory, once this thing is developed, Ventura’s out, but no SSO vendor that I’m aware of actually offers support for Platform SSO yet. But in theory, conceptually, this should be very similar I think to what we can already do on Windows, which is Azure AD joined Windows devices. If you are familiar with those, the user can sign in with their username and password and have it validated by Azure AD. If Azure AD says thumbs up, then we’ll load them onto their profile. And then there’s also passwordless options, like you can sign into Windows with a FIDO key or with Windows Hello for Business, which is a built in platform, FIDO Authenticator on the Windows device.
Those credentials will also be validated by Azure AD. So, no line of sight to an on-prem domain controller, no requirement for always on VPN at the lock screen. Any of those sorts of things go out the window. It’s a more cloud native device that can either be signed into a single factor or if you want with a much stronger credential like a FIDO credential.

Charles Edge:
We start to look at things like web credential managers and other things like that that Windows offers as well. Things get very, very interesting in a right quick hurry with the identity stack at that point. So, as much as I want to go down that path, I’m going to hold back for a minute and I feel like that’s another conversation for another day.

Tom Bridge:
Although all of the platforms now pretty much require TPM ship to upgrade to the latest version of their operating system. So, whatever that key manager is, whether it’s like a vault in the Windows world or a key chain or a third party management tool, we should do an episode on that. I’ll get on.

Charles Edge:
I was going to say you’ve just seen a little bit of our editorial process here. It comes a lot.

Marcus Ransom:
Ooh, shiny thing, let’s talk about that.

Charles Edge:
Shiny things.

Tom Bridge:
Squirrel, but we have a bonus question instead of talking about squirrels who ate all the pumpkins on my porch.

Charles Edge:
Yes, those bastards. I was going to say we love the tradition here of a bonus question, something a little bit frivolous and fun. So, this question goes out to all three of you. What’s the worst app you allowed to get access to a login with Facebook or login with Apple Identity Flow?

Michael Epping:
I just signed up for Nextdoor, which I am philosophically against, because it’s mostly people complaining about their neighbors. I live in Seattle and there’s a lot of people struggling in Seattle due to the high cost of living here. Nextdoor is a very hostile place to people like that. So, I did not want to give them my personal information at all, but I did want to go on there to see if a neighborhood cat that I like had died.

Marcus Ransom:
So you weren’t wanting to complain about the neighborhood cat.

Michael Epping:
Correct. There was a neighborhood cat that would come around that we like to feed treats to see if she would let us pet her and she’s very cute. And then she disappeared, so I hopped on Nextdoor and said, “You know what? I’ll sign up with Apple.” I used the sign in with Apple Options so I didn’t have to give them my email address. Unfortunately, the cat is no more. But now I am starting to get emails from Nextdoor where people are being nasty about their neighbors, so it’s probably time to go delete that account.

Charles Edge:
That is one of the nice features of the sign up with Apple methodology at that point is that you could just be like, “No.”

Tom Bridge:
Yeah, so I signed up with one login with Apple for the pizza joint down the road who I think they have four employees and they had Apple Pay and login with Apple. I’m like, “Wow.” But then as soon as I did log in with Apple and I did use private relay, so I didn’t give them my personal identifiable information. Luckily, they did not need to call or email me to say why my pizza was late, although they knew where I lived. But I was like, “How does this two or three-person pizza joint down the road…” I tried to look at the source code to see if they were using some third-party pizza delivery SaaS type service and I couldn’t figure it out. Maybe they have a coder. I don’t know. It was weird. How about you, Marcus?

Marcus Ransom:
I can’t actually remember for the life of me what it was, but it was definitely something where it’s like, “I’m not giving you my email address and my details because I do not trust you at all.” The fact that it was all coming up as whatever random string Apple ID showed that it hadn’t even been built particularly quickly, but almost immediately, my inbox started to fill up with very helpful marketing information from things completely unrelated to what I wanted in the first place, which was probably pizza or something like that. The ability to just go see you later, goodbye.
I really like that approach when we’re talking about the authentication and authorization. I wonder how good the authorization ongoing is with Facebook to be able to go, “You know what? Actually, no, you’re not allowed to access this anymore.” But it’s one of the things we as login with Apple, which is not being Facebook user. I have absolutely no idea how any of that works in there and I’m happy to stay that way.

Tom Bridge:
I think one out of every four or five websites that has that button where I’ve tapped that button has said, “Sorry, this vendor is no longer allowed to…” So they’ve definitely gone through and called out thousands upon thousands of organizations from being able to log in. And they’ve done a lot of work on making that graph API better about what it can show and not show developers, but still the Cambridge Analytica, what type vendors can hop into that developer program and be there for a week and capture whatever… It’s just so much data flowing through that thing.

Charles Edge:
I think it’s also important to recognize that you’re supposed to have some control over these things.

Tom Bridge:
I wouldn’t want to be their product manager.

Charles Edge:
Definitely.

Tom Bridge:
That would be so hard.

Charles Edge:
That would be a hard job, but I do think it’s important to remind people that if you are using a proxy login service like an OAuth or any the OpenID Connect flows that are out there, you may want to make sure that one, everything that you are doing in those environments is hardened properly. Two, that you’re not letting authorization tokens hang out there longer than you need them. So, my wife’s Twitter handle is Tiffany and somebody managed to get her account by going through a multi-login exploit where they chained it through Foursquare.
So, there was a service that she had logged into using her Foursquare ID, which then is also connected to Twitter. That was how they managed to tunnel into her account and get her account pulled and she managed to get it back. I was going to say working in tech has its advantages, but be sure that if you’re using services out there to auth your credentials, make sure that they’re hardened enough pleas. MFA all the things. I am only just saying this, because if you think that there is an account out there that you care about in any way, shape or form, you should have some multifactor on it if it’s possible. So, now it would be a great time. Just go check.

Michael Epping:
I would plug Passkeys as well. Once services start supporting Passkeys, I would highly recommend moving stuff over those.

Charles Edge:
Bring me Passkeys or whatever your flavor of web auth is.

Michael Epping:
Yeah, yeah, that stuff is much stronger than traditional SMS-based MFA.

Charles Edge:
I was going to say, Michael, we’d love to have you join us again if you’d be willing to come back sometime in the springtime perhaps.

Tom Bridge:
We promise not to go 90 minutes. Actually, we don’t promise. We don’t promise that.

Charles Edge:
We might have to go 90 minutes again. But I definitely want to hear more about how Microsoft is approaching Passkeys in specific, because there’s this now big cross cultural, cross platform focus on platform identifiers using FIDO keys and things along those lines that are super exciting. So, we hope you might come back and join us in the future. Well, thanks so much to our wonderful sponsors this week. That is our friends at Kandji and Mosyle. Thanks so much for our amazing Patreon backers who are part of the reason that you get to hear this episode every week. Michael, thank you so much for joining us. So, if folks want to find you on the internet, where should they go looking?

Michael Epping:
I’m on Twitter @_michaelepping, so fairly easy to find me on there. You can always hit me up on LinkedIn and I am publicly findable on GitHub as well, so a couple different paths.

Tom Bridge:
Awesome. Well, thank you so much for joining us this week. It was a great pleasure to talk with you about everything Azure AD and single sign on extension. I think this is a great topic for us to all explore. So, thank you so much for coming to share your knowledge.

Michael Epping:
Thanks for having me.

Tom Bridge:
Awesome. Thanks, everybody, and we will see you next time.

Charles Edge:
See you next time.

Marcus Ransom:
See you later.

Speaker 7:
The Mac Admins Podcast is a production of Mac Admins Podcast LLC. Our producer is Tom Bridge. Our sound editor and mixing engineer is James Smith. Our theme music was produced by Adam Codiga the first time he opened Garage Band. Sponsorship for the Mac Admins Podcast is provided by the macadmins.org/slack, where you can join thousands of Mad Admins in a free Slack instance. Visit macadmins.org. Also, by Tech Evolutionary LLC. Technically, we can help. For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org. Since we’ve converted this podcast to APFS, the funny metadata joke is at the end.