Custom email for specific client

[lvaroqui]

Hello,

I'm currently using Authentik on a little VPS for my non-profit. However, it uses close to 500MB of RAM to handle ~10 users which eats up precious RAM space.

The reason I use Authentik for now is that it supports SAML, which is required for Google Workspace SSO. However, Google should deploy OIDC soon, the rollout is delayed for now but I hope it won't be too long...

Therefore, I'd like to migrate to rauthy once Google rolls out OIDC SSO, however the email claim should be set to a Google Workspace address, which does not match the email used by my users on IDP. With Authentik I can create a custom mapping and map a user attribute to the email claim.

From what I read on rauthy doc here and my testing with local test, I don't think that using an email coming from a custom field is possible, but maybe I'm mistaken?

[sebadob]

Hey.

However, it uses close to 500MB of RAM to handle ~10 users

That was exactly one of the reasons I started Rauthy back then, yeah.

(...) however the email claim should be set to a Google Workspace address, which does not match the email used by my users on IDP.

This is an issue right now. You can create custom attributes like shown in the linked docs (btw I saw I need to update the screenshots there). The catch with these is, that all of them will be grouped in custom.<attr_name> in the claims, no not interfere with default claims and creating issues there.

However, if it really will be an issue in the end, depends a bit on googles implementation. Many clients support custom mappings. For instance, if you set it up in google then (maybe) you can say it should grab the email from somewhere else than the email claim directly.

I currently think about making it possible that custom attributes can be modified by users themselves, if allowed by an admin, but I am not 100% sure about it yet, if it's worth the extra work.

Re-mapping certain values, especially like the email is not too straight forward, if you want to do it right. Especially the email claim comes in combination with email_verified, which will only be set to true after a user has actually verified the email by clicking a link or something like that.
Right now, you can do this. Set a custom email per user, after you created a custom attribute, map the attribute to a scope, and then either request that scope during login, or set it as a default. The only "issue" in the situation you describe is, that .email will contain the email used for logging into Rauthy, while the custom one that google should parse would be under .custom.email for instance.

Replacing the .email with a custom value is not possible right now and not planned for the near future, since no one needed something like that so far. You are the first one asking for this and es explained, especially the email contains a few footguns, if you want to do it properly. If there is enough interest, something like custom mapping may be implemented at some point in the future.

[lvaroqui]

Hello again @sebadob, so Google just released their OIDC third party support as beta and doc indeed says:

The email claim from your IdP must match the user’s primary email address on the Google side.

(see https://support.google.com/a/answer/12032922?hl=en)

I'll try to setup rauthy with this and see if I can set up something with a custom mapping for email and send a PR to see if it makes sense.

[sebadob]

Hey,

yeah then a custom mapping option would be necessary to make it work.

But, that's quite straight forward. What I would do:

• add 2 new columns to user_attr_config: is_email + user_editable
  The is_email should be true if special email validation and handling should be applied. The user_editable makes sense in a case that Rauthy could allow end users to edit these values themselves.
• Then, since the is_email values are very special and it's probably the only data type that ever needs custom mapping (since roles and groups are done by default, which a lot of apps need), I would add a column to clients with something like cust_email_mapping, which is a cascading FK to the user_attr_config table which then will take care of the mapping during token creation.

And then, it's just a bit of frontend work and optionally fetching the additional user_attr_values.<key> if the client has a custom mapping. These I would cache as well, because they would be needed for every token creation.

For the is_email values, Rauthy could do the email verification on change, that is already implemented. So it would probably just be sending out almost the same email, maybe with slight adjustments or a url param to indicate, that it's not the primary email.

[sebadob]

I created an issue out of this: #872

[lvaroqui]

Sounds like a plan, I'll start working on this next week!

One thing I'm not sure about is doing email verification for the extra field. For instance, in the case of Google Workspace, the way to access the custom mail box is via SSO so it's kind of a chicken egg problem, how the user is gonna validate the email if he can't connect to his mailbox?

[sebadob]

Hmm, good question.

In that case it makes no sense to request any validation because it's impossible to solve. However, doing no validation at all would enable a user to take over someone else's account by just specifiying another email.

To fix this, we could "trust" a Rauthy admin. I would say that, as long as user_editable is true, we must request validation. This will not work in this scenario of course, but maybe for others. We could specify that, as long as the custom attribute is NOT user_editable and therefore only a Rauthy admin can edit this field, that we don't need to request validation and will always set email_verified: true for that value and have the Admin as our "trust anchor".

To not run into security issues down the road, the user_editable should only be possible to set during creation for an attribute, but it MUST NOT be modifiable later on. Because, let's assume the custom attribute starts with being user_editable and user's would enter random data (which may or may not be verifiable), and then afterward, it's changed to being non-user_editable. At that point, the logic would simply set everything as email_verified: true with the values that users have entered before.

To not shoot ourselves in the foot, this option must only be set during the very first creation and never modified. Then we should be good, as long a the Rauthy admin is trustworthy, which I would take for granted.