Feature Request: Privilege revocation/granting through IdP

[codeceptsDE]

Thank you for creating this integration, and also for your advocacy for upstream adoption!
I'm successfully running v0.7.0-alpha-rc3. It works great, including the frontend injection for the login page. I do have one feature request, though:

User roles are set in accordance to group membership on initial user creation. Changing group memberships after the fact does not update home assistant roles for the user:

• a user with role system-users cannot be granted system-admin privileges
• system-admin privileges cannot be revoked, downgrading the user to system-users role
• access cannot be revoked again, downgrading the user to invalid role

Roles seem to be set once, at initial credential creation, by an external call from home assistant to async_user_meta_for_credentials.
I feel like roles should be updated again somewhere around here, line 58:

hass-oidc-auth/custom_components/auth_oidc/endpoints/callback.py

Lines 46 to 70 in 04a693c

	user_details = await self.oidc_client.async_complete_token_flow(
	redirect_uri, code, state
	)
	if user_details is None:
	view_html = await get_view(
	"error",
	{
	"error": "Failed to get user details, "
	+ "see Home Assistant logs for more information.",
	},
	)
	return web.Response(text=view_html, content_type="text/html")
	if user_details.get("role") == "invalid":
	view_html = await get_view(
	"error",
	{
	"error": "User is not in the correct group to access Home Assistant, "
	+ "contact your administrator!",
	},
	)
	return web.Response(text=view_html, content_type="text/html")
	code = await self.oidc_provider.async_save_user_info(user_details)
	raise web.HTTPFound(get_url("/auth/oidc/finish?code=" + code, self.force_https))

That is, after fetching user_details, but just before potentially rejecting access for users where role==invalid.
Alternatively, it could be updated (saved to database) in async_save_user_info, with a separate error code being raised in case privileges were just revoked.

Upgrading users from invalid (i.e. access prohibited) to either system-users or system-admin already works as it is.
I know the other grants/revocations can be done manually through the home assistant UI, but I would prefer to be able to manage this through my IdP.

Keep up the good work! :)

[christiaangoossens]

This was considered before, but HA doesn't like it if you change permissions on login. It only gives you an option to do so (in the public API's) whenever you are creating a user. Because for role invalid, no user is created, upgrading works as intended as the full code is ran in the next iteration as well.

Theoretically you are right and I could implement checking the permissions on every callback, but I am not quite sure if we should do that. OIDC integration using a custom integration is always going to be limited. I can hack in more features by playing with HA, but that makes it more likely that the integration will break in the future. Currently, you also aren't automatically logged out, so this integration effectively provides a very consistent 'onboard-only' home-use experience. It's not usable in a business setting in any way and I don't promote that.

I feel that implementing this feature to check upon login by using internal HA API's (instead of the more public auth provider methods I am using now) already crosses the 'no-messing' boundary while not providing a reliable business experience anyway because of the missing logout and lifecycle features.

What's your opinion on this?

[codeceptsDE]

I see you point about the fragility of an implementation of this feature. And the lack of "Single Sign-Out" would have been the next thing I'd have mentioned, as I would ideally like to see this, too.
Nonetheless, if only for the use case of "upgrading" some user to the admin role, this check at login would be useful.

I'm not that familiar with HA auth, so I had to dig a bit. So take this with a grain of salt, but these would by my suggestions:

Granting/Revoking Admin Rights

Updating a user seems to be possible via async_update_user (auth module), as it can be done via the UI. That function is not much more or less hidden or internal than the async_get_user, async_link_user (auth module) or async_create_person (person component) functions, which this integration already calls. By calling this function, it should be possible to grant or revoke admin group membership.

This would be my main feature request, I would love to see this!

Granting/Revoking Access Rights

Granting works, as you rightly point out.
Revoking also works, contrary to my initial post, to an extent: A logged-out user cannot obtain a new access token through OIDC if they are no longer in at least the users role/group. Of course, as long as a user holds on to their HA access_token, they get in without reauthenticating. One way to "kick them out" is to set their account to inactive (momentarly) throuth the HA UI, as this invalidates their refresh tokens (since home-assistant/core@4a464f6). Ideally, with OIDC as a "first-class citizen", this wouldn't be necessary and we wouldn't have two separate tokens with their own lifetimes. But while we do, maybe this helps:

HA Session Invalidation / Single Sign-Out

This one's a bit tricky, I think that's just how it is. But it is also less essential than updating roles/groups, imo. One fairly straightforward way to make this work anyhow would be to implement OIDC back-channel logout.
In the back-channel logout mechanism, the IdP issues a logout token to the Relying Party. So this integration would need to implement a callback that, upon reception, kills the users access_token/refresh_token, effectively kicking them out of their current session.
It would need to do something similar to calling this API endpoint:
https://github.com/home-assistant/core/blob/ce234d69a72a2df8a6826ab3308513d48d7a8890/homeassistant/components/auth/__init__.py#L209-L235
or maybe similar to this, where all refresh tokens are invalidated:
https://github.com/home-assistant/core/blob/ce234d69a72a2df8a6826ab3308513d48d7a8890/homeassistant/auth/__init__.py#L405-L406

Another option would be to globally deactivate the user (e.g. through async_deactivate_user). But in a world of multiple auth providers, that would be overstepping, I think. We only want to disable our login (OIDC).

---

It's not usable in a business setting in any way and I don't promote that.

HA is not usable in a mixed-trust, let alone business setting anyway, as it provides nothing in the way of functional ACLs/permissions as it stands currently... Tbh I'm bummed out that HA is dragging their feet on something this essential since 2019 :/