Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Implement MSC3356 to support additional fields in the OpenID user info #10384

Open
wants to merge 37 commits into
base: develop
Choose a base branch
from

Conversation

jkanefendt
Copy link
Contributor

@jkanefendt jkanefendt commented Jul 13, 2021

Add option to include additional fields in the OpenID user info (currently the user's display name an effective power levels).
This should simplify room-based access control in third-party widgets. Currently, joined rooms and power levels can only be determined via Admin-API.

See MSC3356.

Signed-off-by: Johannes Kanefendt johannes.kanefendt@krzn.de

@erikjohnston erikjohnston requested a review from a team July 23, 2021 16:17
@clokep
Copy link
Member

clokep commented Jul 30, 2021

I believe that this would need an MSC to accompany it since it is a specified endpoint? (In which case we wouldn't need to have any config options and could just include them, most likely.)

Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that this would need an MSC to accompany it since it is a specified endpoint? (In which case we wouldn't need to have any config options and could just include them, most likely.)

Yeah, there's not much point in supporting extra fields for Synapses deployed on the open federation unless the spec is extended to document the additional fields.

That said, there's probably a usecase for custom fields in private federations - but in that case, I'd expect the extension to happen via a Synapse module (see https://matrix-org.github.io/synapse/latest/modules.html) rather than an eclectic mix of configuration options.

@jkanefendt: could describe your usecase here, so we can suggest how to proceed?

@richvdh richvdh added the X-Awaiting-Changes A contributed PR which needs changes and re-review before it can be merged label Aug 3, 2021
@jkanefendt
Copy link
Contributor Author

I believe that this would need an MSC to accompany it since it is a specified endpoint? (In which case we wouldn't need to have any config options and could just include them, most likely.)

Yeah, there's not much point in supporting extra fields for Synapses deployed on the open federation unless the spec is extended to document the additional fields.

That said, there's probably a usecase for custom fields in private federations - but in that case, I'd expect the extension to happen via a Synapse module (see https://matrix-org.github.io/synapse/latest/modules.html) rather than an eclectic mix of configuration options.

@jkanefendt: could describe your usecase here, so we can suggest how to proceed?

I finally found the time to create a MSC with a brief description and usecase - see https://github.com/matrix-org/matrix-doc/blob/4c415fb7bc2d991a4515820d8c4fda75e98ce94e/proposals/3356-add-openid-userinfo-fields.md

@anoadragon453
Copy link
Member

@jkanefendt That MSC will need some unstable prefixes defined (or the MSC otherwise needs to be merged) before we can implement it in Synapse. See here for an example of defining unstable prefixes. You would need to add an unstable prefix to each of the new key names in the OpenID response.

It also appears that there are some unaddressed comments on the MSC, which addressing will help move the MSC forwards 🙂

@anoadragon453 anoadragon453 added the z-blocked (Deprecated Label) label Sep 14, 2021
@jkanefendt
Copy link
Contributor Author

jkanefendt commented Sep 16, 2021

@jkanefendt That MSC will need some unstable prefixes defined (or the MSC otherwise needs to be merged) before we can implement it in Synapse. See here for an example of defining unstable prefixes. You would need to add an unstable prefix to each of the new key names in the OpenID response.

It also appears that there are some unaddressed comments on the MSC, which addressing will help move the MSC forwards

Thanks for your feedback @anoadragon453 . I'm going to add the unstable prefixes ASAP.
In the meantime, i found some time for some security considerations regarding MSC3356. My proposal for releasing fields on a per-token basis is implemented in jkanefendt@92e663c.

@anoadragon453
Copy link
Member

In the meantime, i found some time for some security considerations regarding MSC3356.

I think that's an excellent addition. And since we're on the topic of implementing additional features as they come into the MSC, don't be afraid to break up the feature into multiple PRs, especially for self-contained changes like specifying which fields to return. It can help make review easier and get your code merged quicker.

Looking forward to the unstable prefixes. Do poke on the MSC PR if you need any further clarifications on how to add them.

@jkanefendt jkanefendt changed the title Add option to include additional fields in the OpenID user info Implement MSC3356 to support additional fields in the OpenID user info Dec 3, 2021
@DMRobertson DMRobertson requested a review from a team December 9, 2021 16:16
@jkanefendt
Copy link
Contributor Author

Yeah, there's not much point in supporting extra fields for Synapses deployed on the open federation unless the spec is extended to document the additional fields.

That said, there's probably a usecase for custom fields in private federations - but in that case, I'd expect the extension to happen via a Synapse module (see https://matrix-org.github.io/synapse/latest/modules.html) rather than an eclectic mix of configuration options.

@jkanefendt: could describe your usecase here, so we can suggest how to proceed?

All these points have been covered in MSC3356 by now.

@jkanefendt jkanefendt closed this Dec 14, 2021
@jkanefendt jkanefendt reopened this Dec 14, 2021
@DMRobertson
Copy link
Contributor

DMRobertson commented Dec 14, 2021

@jkanefendt I think that number is already in use: https://github.com/matrix-org/matrix-doc/issues/3556. If you make a pull request to that repo from the branch you linked, you should be assigned a unique number. cc @matrix-org/spec-core-team .

Sorry, I got my numbers mixed up. 3356 versus 3556.

@DMRobertson DMRobertson changed the title Implement MSC3356 to support additional fields in the OpenID user info Implement [MSC3356](https://github.com/matrix-org/matrix-doc/issues/3356) to support additional fields in the OpenID user info Dec 14, 2021
@richvdh richvdh self-assigned this Apr 14, 2022
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally this looks great to me, though I have a few nits it would be nice to clean up.

changelog.d/10384.misc Outdated Show resolved Hide resolved
synapse/api/constants.py Show resolved Hide resolved
Comment on lines 975 to 977
async def on_openid_userinfo(
self, token: str
) -> Optional[Tuple[str, Optional[List[str]]]]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please could you add a docstring documenting what this returns?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 42 to 44
async def get_user_id_and_userinfo_fields_for_open_id_token(
self, token: str, ts_now_ms: int
) -> Optional[str]:
def get_user_id_for_token_txn(txn: LoggingTransaction) -> Optional[str]:
) -> Optional[Tuple[str, Optional[List[str]]]]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, please can you give this a docstring.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1 @@
ALTER TABLE open_id_tokens ADD COLUMN userinfo_fields TEXT;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please could you add a sql comment describing what this column contains.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

synapse/storage/databases/main/openid.py Outdated Show resolved Hide resolved
Comment on lines 323 to 325
room_state = await self.hs.get_state_handler().get_current_state(
room.room_id
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please can you give this event_type and state_key arguments. Pulling out the entire room state for a large room is quite expensive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solved in 29664b1

Comment on lines +323 to +327
stripped_content = copy.deepcopy(room_power_levels.content)
stripped_content["users"] = {
k: v for k, v in stripped_content["users"].items() if k == user_id
}
power_levels[room.room_id] = stripped_content
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I have strong feelings on this. I think the current behaviour is probably fine. It would be nice if the MSC made the behaviour here explicit though.

@richvdh
Copy link
Member

richvdh commented Apr 14, 2022

One other thing: it would be really nice to see some tests for this stuff, especially the power-levels stuff which looks fiddly. It might be best to wait for more progress on the MSC before putting in too much work in that direction though.

@anoadragon453
Copy link
Member

Hi again @jkanefendt. Just checking in to see if you're able to continue with the suggested changes? It'd be good to see this PR finished up :)

@jkanefendt
Copy link
Contributor Author

Hi again @jkanefendt. Just checking in to see if you're able to continue with the suggested changes? It'd be good to see this PR finished up :)

Hi @anoadragon453. I'm quite busy right now, i hope i'll find the time to add the requested changes and documentation in June!

@jkanefendt jkanefendt requested a review from richvdh June 2, 2022 09:11
@richvdh richvdh requested a review from a team June 6, 2022 12:12
@richvdh richvdh removed the X-Awaiting-Changes A contributed PR which needs changes and re-review before it can be merged label Jun 6, 2022
@richvdh richvdh removed their request for review June 6, 2022 12:12
@anoadragon453
Copy link
Member

anoadragon453 commented Jun 8, 2022

Hi @jkanefendt, thank you for updating this PR.

Looking at MSC3356, there have been concerns raised about whether the design is the right approach. I'm a little hesitant to merge this PR before that opinion in engaged, even behind an experimental flag. Could you respond with your thoughts on the MSC?

@DMRobertson DMRobertson removed the request for review from a team June 14, 2022 11:14
@DMRobertson
Copy link
Contributor

Taking this out of the review queue until the discussions on the MSC are resolved.

@reivilibre reivilibre added the X-Needs-Info This issue is blocked awaiting information from the reporter label Aug 5, 2022
@clokep clokep added the Z-Spec-Blocked This change is blocked on specification (e.g. an MSC). label Sep 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
X-Needs-Info This issue is blocked awaiting information from the reporter Z-Spec-Blocked This change is blocked on specification (e.g. an MSC).
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants