Feature request: start broker on-demand during operation

[fmoessbauer]

Currently, the broker is started during the initial startup of the extension and via org.freedesktop.DBus->StartServiceByName. Later on, we just observe if it is running / not running and inform the browser component about the current status. However, this only works in case the broker is always running.

In [1] I got informed, that some people only run the broker temporarily and use the DBus activation feature to activate it whenever it is needed. With the current implementation of the extension, this is not supported, as we simply disable the extension once the service disappears (and re-enable once it is back). We also cannot easily change that, as the NativeMessaging backend uses introspection to create the DBus RPC wrapper on-demand. This introspection approach seems to be incompatible with DBus based activation [2]. At least I did not manage to make that work in either pydbus or dasbus. I further tried manually starting the service via dbus.StartServiceByName(), but this is not atomic, i.e. the call returns before the service can be introspected.

What I don't understand is why the introspection calls are not buffered until the service is running. Is this just a quirk in the pydbus / dasbus libraries, or is it a more fundamental issue? Probably we need to completely avoid the online introspection and use more low-level libraries to perform the dbus communication.

• [1] https://fosstodon.org/@bluca/113146514151871076
• [2] https://stackoverflow.com/questions/51841342/dbus-service-activating-method-call-lost

[fmoessbauer]

I debugged this a bit further and actually the problem is a different one:

The microsoft-identity-broker.service is indeed DBus activated, however it exposes the object / path com/microsoft/identity/broker1 only after a couple of seconds. By that, showing up on DBus and being usable is not atomic. The DBus activation however only guarantees that the method call is delayed until the name shows up on the bus and then performs the call - which is too early for the broker.

IMHO this is a flaw in the implementation of the broker. This also explains, why the extension sometimes does not work on initial startup of the OS. I can try to implement a workaround, but nonetheless this should be fixed in the broker.

[nsballmann]

:grimacing:

[nsballmann]

@bovi The identity broker come from the Entra ID product group and are "just" a dependency by Intune (from the Intune product group). The identity brokers are, in my assumption, used by more Microsoft products than Intune, for example Edge (by probably a third product group).

~If~ When Microsoft releases an RDP client for their Azure Virtual Desktop (new name Windows App, by another product group) that client will probably also depend on those brokers being present for device trust based SSO.

To get to the point: They aren't part of the endpoint management service.

They are just identity brokers talking with Entra ID for you. It might even be possible to write a PAM for Entra ID based device login interacting with the device broker.

[nsballmann]

@bovi jup.

[bluca]

To get to the point: They aren't part of the endpoint management service.

They are just identity brokers talking with Entra ID for you.

Yes, this is correct, and it can be verified by simply installing the publicly available packages and running them through strace, and you'll see what they do. Even the Intune agent runs periodically, as you can see it is ran by a systemd timer once an hour. And to be clear: this is a good design. Run when needed transparently, and recover any state at any moment if they aren't. There's no need for any persistent service for any of this, consuming CPU and battery. Now the fact that 2 of the 3 components are Java program doesn't help with resource consumption, but that's due to historical reasons. I am happy enough that there is a supported solution at all for Linux, and I am grateful to the teams that delivered it. And I am also grateful to Siemens folks for implementing these extensions, as they make life a lot easier. Thanks!

What I noticed is that when the extension is enabled, the brokers get started even if I am not opening any website that goes through login.microsoft.com, so they are effectively always running again, hence my comment.

I debugged this a bit further and actually the problem is a different one:

The microsoft-identity-broker.service is indeed DBus activated, however it exposes the object / path com/microsoft/identity/broker1 only after a couple of seconds. By that, showing up on DBus and being usable is not atomic. The DBus activation however only guarantees that the method call is delayed until the name shows up on the bus and then performs the call - which is too early for the broker.

IMHO this is a flaw in the implementation of the broker. This also explains, why the extension sometimes does not work on initial startup of the OS. I can try to implement a workaround, but nonetheless this should be fixed in the broker.

Yeah that does sound like an issue in the broker, I can try and look into it after I am back from conferencing.

[bluca]

I'm sorry but I think there is a misunderstanding what the concept of an endpoint management service is suppose to do.

Sorry, but I am afraid there is some misunderstood going on about what this is, what it does and what it is for. Unfortunately they are closed source components, so I cannot comment further. It is wildly off topic anyway, so let's stop this here. I will check what can be done about publishing the object on the bus as soon as I can and report back.

[fmoessbauer]

Yeah that does sound like an issue in the broker, I can try and look into it after I am back from conferencing.

@bluca That would be much appreciated. It also would be great if you could give #34 a try. This should add support for your use-case.

[nsballmann]

And to be clear: this is a good design.

I wholeheartedly agree. I just have my problems with some implementation choices (especially the Java part) but I absolutely get why and how these choices were made and I also appreciate that the whole thing was made in the first place.

Yeah that does sound like an issue in the broker, I can try and look into it after I am back from conferencing.

@bluca If you need help with these MS internal efforts by backing them up with a support request from outside, please don't hesitate to ask. I can do this. If you think an SR would hurt these efforts (at this point in time), please tell me as well, then I'll back off.

[bluca]

I debugged this a bit further and actually the problem is a different one:

The microsoft-identity-broker.service is indeed DBus activated, however it exposes the object / path com/microsoft/identity/broker1 only after a couple of seconds. By that, showing up on DBus and being usable is not atomic. The DBus activation however only guarantees that the method call is delayed until the name shows up on the bus and then performs the call - which is too early for the broker.

IMHO this is a flaw in the implementation of the broker. This also explains, why the extension sometimes does not work on initial startup of the OS. I can try to implement a workaround, but nonetheless this should be fixed in the broker.

I found the cause of this issue in the broker and fixed it, the fix has just been merged in the dev branch, so it should be part of the next release, whenever that happens

[fmoessbauer]

I found the cause of this issue in the broker and fixed it

That's great news. Many thanks for fixing. The workaround #34 is included in v1.1.0 and can be reverted once the next version of Intune is released.