[noodlesUK]

I think it’s not just the security of the platform itself either that’s measurably worse - it’s also way easier to end up with insane security configurations with the hellscape that is Entra. It all just feels like it’s held together with duct tape.

The deep integration with AD (now Entra) was the strongest selling point for Azure, but it’s also by far the biggest issue with the platform IMO.

There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.

[_fat_santa]

> There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.

For all of AWS's faults, one of the reason I really like them is how consistent everything is. There were so many instances where I could correctly guess the right command for the AWS CLI based on how other services worked, I could never do that with GCP or Azure.

I would love to read an article about how AWS ensures this kind of consistency. Given how Azure and GCP both messed this up, it's clearly not a trivial problem (even though it may seem like one)

[dabbz]

They have a governance panel for all AWS services that approves design docs and API contracts (at least this is what I was told by an old manager who worked on AWS back in the day).

[patch_cable]

It isn't quite as formal as that, but there is a group of engineers who review new APIs for following AWS-wide standards.

[dastbe]

there's also a significant amount of automation in place these days to sass you in the right direction, i.e.

* focusing on resources and operations on resources

* using consistent and expected naming schemes, pluralization, etc.

it also helps that the sdks and clis are very raw wrappers around this, such that if you know what it looks like in the sdk then it will look similar in the cli.

[jiggawatts]

My favourite pet peeve is that it uses a bunch of indistinguishable random guids, all of which have two names for no discernible reason whatsoever.

So the doco and the UI ends up littered with things like:

    PrincipalId (ClientId)

There’s at least six of those and I honestly can’t remember which pairs with which or what the difference is… which I’m sure is security-critical… somehow.

[moi2388]

An App registration is the overall object. Think of it like a class in OOP. An enterprise app is an instance of an app registration. Think of it like an object in OOP.

For single tenants this might seem confusing, because you have both for a single app.

But if you were to have multi-tenants apps, each tenant would have their own Enterprise App instance, all referencing the same App Registration.

appId is for App Registrations.

objectId is for Enterprise Application Registrations.

clientId will be same as appId. It is used in the context of authentication, where it is the id of the object as client.

[jiggawatts]

The problem is that those “id” names have nothing to do with what they’re pointing at.

“EnterpriseAppId” and “AppRegistationId” would make sense.

ObjectId is meaningless nonsense. Everything is an object! Everything has an Id! This tells you nothing specific.

[moi2388]

Well, it kind of does. AppId points to an app registration. Object id points to an object. This can be an Enterprise App registration, but also a user object.

ClientId again is the id of the client, which does not have to be an app registration specifically.

I do agree it can be very confusing

[jiggawatts]

That’s the clearest and most concise explanation I’ve heard after years of working with this stuff.

You should make a YouTube channel in the style of 3b1b.

[kidbomb]

Identity management is a mess on Azure! I still cannot understand the difference between app registrations and enterprise applications, and how they tie into service principals.

They also have a lot of different resources, such as Graph API, Entra ID.

Manage identities are simpler, since they are Azure constructions, so they work more or less like a IAM role. But then you try to use them with Entra ID APIs and things fall apart.