Identity provider

I saw Mark there.

Uh, he asked, "Can rings be based on intra IDP group, intra ID or IDP groups, like an identity provider?" Good question.

I have no idea.

Um, I haven't heard that one.

I actually think that that's a smart thing to add to the platform because it opens things up.

But it also means that Apple has to maintain developer relations with its IDP partners.

And my hope is that we start to see those things roll out as we come into the future here.

Um, I certainly know that, you know, friend of the pod, Joel Renick was talking about it this summer a lot in the, you know, the various beta, you know, forums for this kind of stuff.

mean, this is what's holding me back from doing

it,

right? Like, I mean, I don't have an IDP.

My IDP is Google Workspace because that's all we need right now.

Later on, I as a user logging or I as an approver in that workflow in IG, I log into the IG tenant that always goes via the Cloud Identity Services.

As you can see here on this diagram, In my demo environment, the Cloud Identity Services tenant is configured as a corporate proxy or an IDP proxy that proxies via the OIDC protocol to the Entra tenant.

So when I later on log in as the approver, I'm silently forwarded here through the proxy to Entra and log in as a user here with my credentials.

So provisioning then finally, once the user has successfully or has been approved access in IAG, provisioning then also takes place from IAG all the way through the connectivity service by using a destination that goes all the way to the cloud connector and then finally to the backend system and will assign the the technical role or the PFCG role, in this case, SAP BC EPM demo, which is contained in that business role.

All right.

And again, I'm logging

in through the corporate IDP proxy in IIS.

And I'm always using my credentials in the Android tenant for any user.

So we have to do the best we can.

And in some cases, we'll... piggyback off of the IDP, whether it's Okta or Entra or something like that, and we'll manage the groups.

And ultimately, that's what's managing access into the target systems.

But the best scenario is always where we have a direct connector.

I need access to this customer's database because I'm working on this ticket or incident for them.

The AI will go and look to see, is there a ticket, active ticket for that customer? Is this the engineer that's assigned? Does this level of access that's requested match the incident and, you know, what the incident needs to resolve? And so the AI can go do all that research, you know, fetch all of the context from the ticketing system, messaging apps, everything.

Obviously, look inside the IDP and it will evaluate all that.

So it shows all that reasoning that we do and brings all that context and packages in a very simple to digest format and presents it all in a very consumable manner to the human.

And basically how the attackers got in is they created their own Brevo account and set up single sign-on to a SAML identity provider.

They then invited legitimate Brevo users in other accounts into their tenant.

If those Brevo users accepted the invite, the, uh, the attacker could use SAML single sign-on from their IDP that they controlled to log in as that other user.

Where the issue was is that should have let them log in as that user in their tenant, the attacker's tenant.

But due to some scoping issues, it allowed them to log in as that user in any tenant that that user had access to.

Yep, exactly.

Says Uh, it makes sense.

If you control the IDP, you control being able to log in as that user in the IDP.