KEYCLOAK-17851 change emailVerified User field with UserAttributeMappers (conditional trust email) by cgeorgilakis · Pull Request #8018 · keycloak/keycloak

cgeorgilakis · 2021-05-10T11:53:24Z

Documentation PR : keycloak/keycloak-documentation#1171

cgeorgilakis · 2021-09-03T10:36:51Z

I have rebased into current master taking into account changes in TokenEndpoint.

cgeorgilakis · 2021-10-21T08:56:51Z

GitLab IdP implementation have been added.

stianst · 2021-10-21T09:38:11Z

I think this can already be achieved with protocol mappers if I'm not mistaken. If it can't be done already, then I'd rather see an approach using mappers than adding a specific config option for it.

cgeorgilakis · 2021-10-22T08:05:03Z

I think this can already be achieved with protocol mappers if I'm not mistaken. If it can't be done already, then I'd rather see an approach using mappers than adding a specific config option for it.

Could you provide us how we could achieve conditional email verification with protocol mappers?

I have added a Google Attribute Importer mapper with Social Profile JSON Field Path = email_verified and User Attribute Name= emailVerified. When I logged in with my google account Keycloak did not set emailVerified UserEntity field to true ( requested for email verification). Keycloak only have added an User Attribute emailVerified with value true to my account.

From Keycloak code:
UserAttributeMapper do changes in BrokeredIdentityContext that does not have emailVerified field. emailVerified exists only in Usermodel. See the master branch code below for making emailVerified equal to true:

if (context.getIdpConfig().isTrustEmail() && !Validation.isBlank(federatedUser.getEmail()) && !Boolean.parseBoolean(authSession.getAuthNote(AbstractIdpAuthenticator.UPDATE_PROFILE_EMAIL_CHANGED))) {
logger.debugf("Email verified automatically after registration of user '%s' through Identity provider '%s' ", federatedUser.getUsername(), context.getIdpConfig().getAlias());
federatedUser.setEmailVerified(true);
}

I do not have problem implementing it as a mapper. How do you want to do it?
A solution could be to try adding emailVerified to BrokeredIdentityContext and being able to change it in preprocessFederatedIdentity method of UserAttributeMapper. I am not sure that is correct being able to change emailVerified in updateBrokeredUser method. Is this something acceptable from your side?

stianst · 2021-10-25T07:34:15Z

I think this can already be achieved with protocol mappers if I'm not mistaken. If it can't be done already, then I'd rather see an approach using mappers than adding a specific config option for it.

Could you provide us how we could achieve conditional email verification with protocol mappers?

I have added a Google Attribute Importer mapper with Social Profile JSON Field Path = email_verified and User Attribute Name= emailVerified. When I logged in with my google account Keycloak did not set emailVerified UserEntity field to true ( requested for email verification). Keycloak only have added an User Attribute emailVerified with value true to my account.

From Keycloak code: UserAttributeMapper do changes in BrokeredIdentityContext that does not have emailVerified field. emailVerified exists only in Usermodel. See the master branch code below for making emailVerified equal to true:

if (context.getIdpConfig().isTrustEmail() && !Validation.isBlank(federatedUser.getEmail()) && !Boolean.parseBoolean(authSession.getAuthNote(AbstractIdpAuthenticator.UPDATE_PROFILE_EMAIL_CHANGED))) {
logger.debugf("Email verified automatically after registration of user '%s' through Identity provider '%s' ", federatedUser.getUsername(), context.getIdpConfig().getAlias());
federatedUser.setEmailVerified(true);
}

I do not have problem implementing it as a mapper. How do you want to do it? A solution could be to try adding emailVerified to BrokeredIdentityContext and being able to change it in preprocessFederatedIdentity method of UserAttributeMapper. I am not sure that is correct being able to change emailVerified in updateBrokeredUser method. Is this something acceptable from your side?

I'm not 100% sure how it should be implemented, but in general with a mapper we can allow different sync-modes, and also ability to either hard-code it, or map it to a claim from the incoming token. Those wouldn't be possible if it's a config option.

There's (weirdly) two types of user attribute mappers, one for generic attributes, and a different one for fields. I thought we made some improvements here.

@pedroigor @mposolda could you provide some thoughts on this?

mposolda · 2021-10-25T08:08:05Z

I think this can already be achieved with protocol mappers if I'm not mistaken. If it can't be done already, then I'd rather see an approach using mappers than adding a specific config option for it.

Could you provide us how we could achieve conditional email verification with protocol mappers?
I have added a Google Attribute Importer mapper with Social Profile JSON Field Path = email_verified and User Attribute Name= emailVerified. When I logged in with my google account Keycloak did not set emailVerified UserEntity field to true ( requested for email verification). Keycloak only have added an User Attribute emailVerified with value true to my account.
From Keycloak code: UserAttributeMapper do changes in BrokeredIdentityContext that does not have emailVerified field. emailVerified exists only in Usermodel. See the master branch code below for making emailVerified equal to true:

if (context.getIdpConfig().isTrustEmail() && !Validation.isBlank(federatedUser.getEmail()) && !Boolean.parseBoolean(authSession.getAuthNote(AbstractIdpAuthenticator.UPDATE_PROFILE_EMAIL_CHANGED))) {
logger.debugf("Email verified automatically after registration of user '%s' through Identity provider '%s' ", federatedUser.getUsername(), context.getIdpConfig().getAlias());
federatedUser.setEmailVerified(true);
}

I do not have problem implementing it as a mapper. How do you want to do it? A solution could be to try adding emailVerified to BrokeredIdentityContext and being able to change it in preprocessFederatedIdentity method of UserAttributeMapper. I am not sure that is correct being able to change emailVerified in updateBrokeredUser method. Is this something acceptable from your side?

I'm not 100% sure how it should be implemented, but in general with a mapper we can allow different sync-modes, and also ability to either hard-code it, or map it to a claim from the incoming token. Those wouldn't be possible if it's a config option.

There's (weirdly) two types of user attribute mappers, one for generic attributes, and a different one for fields. I thought we made some improvements here.

@pedroigor @mposolda could you provide some thoughts on this?

+1 to use the mapper. I think that if "emailVerified" is not available in BrokeredIdentityContext, it will be nice to add it there to make sure that propagating "emailVerified" attribute sent from the broker will allow to configure "emailVerified" of the user on Keycloak side. So I agree that this PR may require some changes in BrokeredIdentityContext class and maybe other similar classes to make it possible to implement this.

Also it will be good to decide based on the "sync" mode whether the attribute should be updated during "update" call from broker or not. IMO it will be nice if behaviour for "emailVerified" is same as for all other attributes regarding sync mode.

cgeorgilakis · 2021-10-27T06:38:31Z

I have implemented conditional email verified with mapper in separate branch. Take a look at 70-verified-mapper. I could force push it here.
Implementation is added for all Attribute mappers ( OIDC, SAML , Social). I have tested it successfully with OIDC ( egi OIDC Identity Provider) and Google.
Although I have written a test for OIDC, I am confused especially with SAML. We could discuss it further.

Do you want any change in documentation?
I will change issue description in order to be compliant with final implementation.

cgeorgilakis · 2021-11-26T10:48:48Z

@mposolda @stianst @pedroigor I have force pushed emailVerified with UserAttributeMappers and I have rebased to current master.
Could you review it?

stianst · 2021-12-02T09:05:37Z

I think this can already be achieved with protocol mappers if I'm not mistaken. If it can't be done already, then I'd rather see an approach using mappers than adding a specific config option for it.

Could you provide us how we could achieve conditional email verification with protocol mappers?
I have added a Google Attribute Importer mapper with Social Profile JSON Field Path = email_verified and User Attribute Name= emailVerified. When I logged in with my google account Keycloak did not set emailVerified UserEntity field to true ( requested for email verification). Keycloak only have added an User Attribute emailVerified with value true to my account.
From Keycloak code: UserAttributeMapper do changes in BrokeredIdentityContext that does not have emailVerified field. emailVerified exists only in Usermodel. See the master branch code below for making emailVerified equal to true:

if (context.getIdpConfig().isTrustEmail() && !Validation.isBlank(federatedUser.getEmail()) && !Boolean.parseBoolean(authSession.getAuthNote(AbstractIdpAuthenticator.UPDATE_PROFILE_EMAIL_CHANGED))) {
logger.debugf("Email verified automatically after registration of user '%s' through Identity provider '%s' ", federatedUser.getUsername(), context.getIdpConfig().getAlias());
federatedUser.setEmailVerified(true);
}

I do not have problem implementing it as a mapper. How do you want to do it? A solution could be to try adding emailVerified to BrokeredIdentityContext and being able to change it in preprocessFederatedIdentity method of UserAttributeMapper. I am not sure that is correct being able to change emailVerified in updateBrokeredUser method. Is this something acceptable from your side?

I'm not 100% sure how it should be implemented, but in general with a mapper we can allow different sync-modes, and also ability to either hard-code it, or map it to a claim from the incoming token. Those wouldn't be possible if it's a config option.
There's (weirdly) two types of user attribute mappers, one for generic attributes, and a different one for fields. I thought we made some improvements here.
@pedroigor @mposolda could you provide some thoughts on this?

+1 to use the mapper. I think that if "emailVerified" is not available in BrokeredIdentityContext, it will be nice to add it there to make sure that propagating "emailVerified" attribute sent from the broker will allow to configure "emailVerified" of the user on Keycloak side. So I agree that this PR may require some changes in BrokeredIdentityContext class and maybe other similar classes to make it possible to implement this.

Also it will be good to decide based on the "sync" mode whether the attribute should be updated during "update" call from broker or not. IMO it will be nice if behaviour for "emailVerified" is same as for all other attributes regarding sync mode.

Honestly, I'm rather confused with the whole BrokeredIdentityContext thing. The email_verified claim is in the ID token, so isn't this as simple as adding a mapper that maps "email_verified" to User#emailVerified? @mposolda ? Something like:

cgeorgilakis · 2021-12-02T10:31:13Z

I think this can already be achieved with protocol mappers if I'm not mistaken. If it can't be done already, then I'd rather see an approach using mappers than adding a specific config option for it.

Could you provide us how we could achieve conditional email verification with protocol mappers?
I have added a Google Attribute Importer mapper with Social Profile JSON Field Path = email_verified and User Attribute Name= emailVerified. When I logged in with my google account Keycloak did not set emailVerified UserEntity field to true ( requested for email verification). Keycloak only have added an User Attribute emailVerified with value true to my account.
From Keycloak code: UserAttributeMapper do changes in BrokeredIdentityContext that does not have emailVerified field. emailVerified exists only in Usermodel. See the master branch code below for making emailVerified equal to true:

if (context.getIdpConfig().isTrustEmail() && !Validation.isBlank(federatedUser.getEmail()) && !Boolean.parseBoolean(authSession.getAuthNote(AbstractIdpAuthenticator.UPDATE_PROFILE_EMAIL_CHANGED))) {
logger.debugf("Email verified automatically after registration of user '%s' through Identity provider '%s' ", federatedUser.getUsername(), context.getIdpConfig().getAlias());
federatedUser.setEmailVerified(true);
}

I do not have problem implementing it as a mapper. How do you want to do it? A solution could be to try adding emailVerified to BrokeredIdentityContext and being able to change it in preprocessFederatedIdentity method of UserAttributeMapper. I am not sure that is correct being able to change emailVerified in updateBrokeredUser method. Is this something acceptable from your side?

I'm not 100% sure how it should be implemented, but in general with a mapper we can allow different sync-modes, and also ability to either hard-code it, or map it to a claim from the incoming token. Those wouldn't be possible if it's a config option.
There's (weirdly) two types of user attribute mappers, one for generic attributes, and a different one for fields. I thought we made some improvements here.
@pedroigor @mposolda could you provide some thoughts on this?

+1 to use the mapper. I think that if "emailVerified" is not available in BrokeredIdentityContext, it will be nice to add it there to make sure that propagating "emailVerified" attribute sent from the broker will allow to configure "emailVerified" of the user on Keycloak side. So I agree that this PR may require some changes in BrokeredIdentityContext class and maybe other similar classes to make it possible to implement this.
Also it will be good to decide based on the "sync" mode whether the attribute should be updated during "update" call from broker or not. IMO it will be nice if behaviour for "emailVerified" is same as for all other attributes regarding sync mode.

Honestly, I'm rather confused with the whole BrokeredIdentityContext thing. The email_verified claim is in the ID token, so isn't this as simple as adding a mapper that maps "email_verified" to User#emailVerified? @mposolda ? Something like:

The problem is that User field emailVerified does not exist in BrokeredIdentityContext. preprocessFederatedIdentity and updateBrokeredUser methods of UserAttributeMappers set values to this object. See for example https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/broker/oidc/mappers/UserAttributeMapper.java .

The provided example in Keycloak main will add a user attribute emailVerified! You could test it in a running Keycloak with Google identity provider that releases email_verified claim.

mposolda

@cgeorgilakis Thanks, added the comment inline (It was added as inline comment, but it is general comment related to this PR)

mposolda · 2021-12-03T10:35:13Z

I am not sure why there is a need for special handling of "emailVerified" attribute on this particular place? As I can see that none of other "special" attributes" (username, email, firstName, lastname) is handled here in this class.

IMO it will be better to make sure that all the places in the model classes like org.keycloak.models.jpa.UserAdapter and org.keycloak.models.map.user.MapUserAdapter are updated to make sure that:
user.setAttribute("emailVerified", "true") works as expected and calls setEmailVerified internally inside the UserAdapter itself. Similarly will be good if all other methods like user.setSingleAttribute, user.getAttribute, user.getFirstAttribute are updated to properly handle "emailVerified" attribute and delegate to the particular "setEmailVerified" or "getEmailVerified" property internally. I see you updated just single place in these classes, but not all places where other special attributes are handled.

In other words, will be good to handle emailVerified in the same places in the codebase when all other mess related to other "special attributes" (username, email, firstName, lastname) is handled. But will be good to avoid introduce more mess to other places :-)

I guess that if you properly update model classes, there won't be even need to update any brokering stuff at all (not even introduce BrokeredIdentityContext.setEmailVerified() and BrokeredIdentityContext.getEmailVerified() methods. As calling of user.setAttribute("emailVerified", "true") will be effectively same as user.setEmailVerified(true) and similarly for getters. But maybe I am too optimistic here :-)

This if is needed here. See my general comment.

cgeorgilakis · 2021-12-03T13:54:31Z

You are partially right. I have been confused by the method difference. Moreover,some checks for "special attributes" like in method updateBrokeredUser in class org.keycloak.broker.oidc.mappers.UserAttributeMapper is doing twice. If you want I could make a separate PR for this.

Changes in methods ( setAttribute etc) of UserModel is enough only for updateBrokeredUser ( User update). When User is first time created ( method preprocessFederatedIdentity), values is written to BrokeredIdentityContext (use USER_ATTRIBUTES_PREFIX for UserAttributes, fields for email, names). If I does not introduce emailVerified field, changes are more complex.

When User first time login with Social Providers, base values ( email, first name, last name) are taken in other point( see OIDCIdentityProvider). So, preprocessFederatedIdentity works only for User attributes. For email verified we need the commented if.

I will do needed changes described in my comment trying to keep changes in the same places as "special attributes". After checking tests and real scenario for Google email verified, I will ping you.

cgeorgilakis · 2021-12-06T08:36:52Z

I have tested successfully my latest changes. For details see my previous comment.
I am thinking about adding an extra test method in SocialLoginTest for emailVerified in Google and GitLab. Of cource, user's email must be verified for successful test. Do you agree?

I also have closed related documentation PR( based on previous implementation). Do you want any addition in documentation for this PR?

cgeorgilakis · 2022-05-04T06:21:41Z

I have rebased to current master.

@pedroigor @mposolda could you proceed with this PR review in order to be able to conditionally verified email for Identity Providers Users.

…field Closes#12013

cgeorgilakis · 2022-05-17T08:11:45Z

I have changed message based on new github issue and I have rebased.

mnaser · 2022-07-20T14:43:34Z

this is mega-useful for identity brokering situations, would love if this could be looked into. ❤️

pedroigor

@mposolda Looks good to me and it seems your suggestions were also considered. Wdyt?

mposolda · 2022-07-22T14:24:45Z

@pedroigor @cgeorgilakis TBH I am still missing a bit why this PR needs to do any changes in the class AbstractJsonUserAttributeMapper and introduce any "if" specific only to emailVerified? Since none of the other "special attributes" is handled on this place? In other words, I don't understand why "emailVerified" needs to be handled there when other attributes (like for example "lastName" or "email") are not needed to be handled there. Will be nice to make this consistent IMO.

For example, I see that:

Class org.keycloak.models.jpa.UserAdapter has 5 occurences of UserModel.LAST_NAME. However this PR adds just 2 places where EMAIL_VERIFIED is handled. Wouldn't it help if you introduce also EMAIL_VERIFIED to other 3 places?
Class MapUserAdapter has 3 occurences of UserModel.LAST_NAME. However this PR adds just 1 place where EMAIL_VERIFIED is handled.
Class org.keycloak.models.cache.infinispan.UserAdapter uses different approach for handling isEmailVerifed/setEmailVerified than other attributes (like for example getLastName/setLastName and others).

In other words, I guess that when you update the models to have the emailVerified handled in consistent way as for example lastName, firstName or email, then I guess no more mess would be needed in AbstractJsonUserAttribute. Wouldn't it be like it?

cgeorgilakis · 2022-08-05T12:54:32Z

AbstractJsonUserAttributeMapper is iherited by the classes FacebookUserAttributeMapper, GitHubUserAttributeMapper, GoogleUserAttributeMapper, InstagramUserAttributeMapper, LinkedInUserAttributeMapper, MicrosoftUserAttributeMapper, OpenshiftV4AttributeMapper, PayPalUserAttributeMapper and StackoverflowUserAttributeMapper.
All these are mappers of social Identity Providers. For social Identity Providers, "firstName", "lastName" and "email" are automatically handled in Identity Provider methods. So, I understand that there is no need for mappers for base attributes for these Social Identity Providers. EmailVerified is different. It is not handled by social Identity Providers methods. So, we need to add this if. context.setUserAttribute set value to "user.attributes". EmailVerified is not "user.attributes".
For understand the difference see org.keycloak.broker.oidc.mappers.UserAttributeMapper ( OIDC Identity Provider).

cgeorgilakis · 2022-08-05T14:07:37Z

@mposolda
setEmailVerified method of org.keycloak.models.cache.infinispan.UserAdapter has already been existed. I believe that doing the same thing as other basic attributes is bad code because this will mean convert boolean to String and String to boolean again.

I have made a change in updateBrokeredUser method of UserAttributeMapper.
Moreover, I have added EMAIL_VERIFIED to the places you mentioned in org.keycloak.models.jpa.UserAdapter and MapUserAdapter. I do not understand the need for addition in method getAttributes. My additions do not use it. See also UserRepresentation toRepresentation method of ModelToRepresentation.

Let's see if all test will be passed.

mposolda · 2022-09-27T09:03:48Z

@cgeorgilakis Sorry for the late feedback. I honestly still don't understand why there needs to be "if" condition added in AbstractJsonUserAttributeMapper. Again, it will be good if all the "special" attributes (like firstName, lastName, email, emailVerified etc) are handled in the same place around codebase. And there is no other attribute handled in AbstractJsonUserAttributeMapper and hence also emailVerified should not be handled here. Converting from String to boolean and vice-versa is not an issue, there is minimal performance price in that. But there is price in maintenance to have various "if/else" statements in different places around codebase for different attributes. Will be really good to avoid introducing more mess through codebase.

cgeorgilakis · 2022-09-29T11:03:33Z

@cgeorgilakis Sorry for the late feedback. I honestly still don't understand why there needs to be "if" condition added in AbstractJsonUserAttributeMapper. Again, it will be good if all the "special" attributes (like firstName, lastName, email, emailVerified etc) are handled in the same place around codebase. And there is no other attribute handled in AbstractJsonUserAttributeMapper and hence also emailVerified should not be handled here. Converting from String to boolean and vice-versa is not an issue, there is minimal performance price in that. But there is price in maintenance to have various "if/else" statements in different places around codebase for different attributes. Will be really good to avoid introducing more mess through codebase.

@mposolda preprocessFederatedIdentity method of AbstractJsonUserAttributeMapper is called during User creation from federation and put values to BrokeredIdentityContext.

If User does not exist in Keycloak, method serialize of SerializedBrokeredIdentityContext (class IdentityBrokerService line 567) is called. If I remove the if you suggest, I must add another if for setting UserModel.EMAIL_VERIFIED inside following code :

for (Map.Entry<String, Object> entry : context.getContextData().entrySet()) {
    Object value = entry.getValue();
    String serializedValue = serializer.serialize(value);

    ContextDataEntry ctxEntry = ContextDataEntry.create(value.getClass().getName(), serializedValue);
    ctx.getContextData().put(entry.getKey(), ctxEntry);
}

I can not understand why. emailVerified will have different code than main user attributes. However, if you want I could try to make the change.

alexted · 2022-10-21T16:55:08Z

Could you please tell me if the this PR is related to any issue?
I would like to be able to conveniently track the process using the capabilities of GitHub.

cgeorgilakis · 2022-10-24T06:58:28Z

Could you please tell me if the this PR is related to any issue? I would like to be able to conveniently track the process using the capabilities of GitHub.

github 12013

cgeorgilakis · 2022-11-08T14:38:22Z

For SAML Identity Providers the logic is different. SAML Identity Providers release a list of email verified.
So I correct the implementation for SAML. If email verified consists user email, emailVerified becomes true.

Could you proceed with PR review?

daviddelannoy · 2023-01-23T10:22:05Z

Hi,
I am also interested in this feature

mposolda · 2023-08-07T14:30:31Z

@cgeorgilakis I am closing as the PR is opened for long time without conclusion. I don't have much to add to my previous comment #8018 (comment) and to other comments.

We should handle emailVerified attribute propagation from broker in same places where we handle other attributes instead of introducing another if just for this specific attribute and make it something "special" and handle it in different place in the codebase where other attributes. It should be investigated why propagation of other attributes (EG. email, firstName, lastname etc) from identity-provider works and only emailVerified doesn't work. There should be a reason for that. It will be nice if all attributes are handled in same places of the codebase. Anyone is welcome to possibly continue and re-open this PR when this is figured.

cgeorgilakis · 2023-08-22T14:28:17Z

@mposolda you could see my comment in github issue.
Maybe a github discussion needed for it.

cgeorgilakis force-pushed the 70-email-verification branch from 45c55c7 to ed6cd2e Compare May 20, 2021 11:04

cgeorgilakis mentioned this pull request Jun 1, 2021

Add support for conditional email verification eosc-kc/keycloak#70

Open

cgeorgilakis force-pushed the 70-email-verification branch 2 times, most recently from 4bde962 to 9ad429d Compare September 3, 2021 07:51

cgeorgilakis force-pushed the 70-email-verification branch from 2610776 to ef73979 Compare October 20, 2021 12:37

cgeorgilakis changed the title ~~KEYCLOAK-17851 conditional trust email for OIDC and Google IdP~~ KEYCLOAK-17851 conditional trust email for OIDC, Google and GitLab IdP Oct 21, 2021

stianst requested a review from mposolda October 25, 2021 07:31

stianst requested review from pedroigor and stianst October 25, 2021 07:34

stianst mentioned this pull request Nov 10, 2021

KEYCLOAK-17851 conditional trust email for OIDC and Google IdP keycloak/keycloak-documentation#1171

Closed

This was referenced Nov 16, 2021

ORCID as Social Identity Provider eosc-kc/keycloak#126

Open

ORCID Identity Providers Mappers Problems eosc-kc/keycloak#136

Open

cgeorgilakis force-pushed the 70-email-verification branch 2 times, most recently from 9fb4279 to 5bdef65 Compare November 26, 2021 09:22

cgeorgilakis changed the title ~~KEYCLOAK-17851 conditional trust email for OIDC, Google and GitLab IdP~~ KEYCLOAK-17851 change emailVerified User field with UserAttributeMappers (conditional trust email) Nov 26, 2021

mposolda requested changes Dec 3, 2021

View reviewed changes

cgeorgilakis requested a review from mposolda December 6, 2021 08:38

cgeorgilakis force-pushed the 70-email-verification branch from 31cd597 to 92daf00 Compare May 3, 2022 14:31

cgeorgilakis force-pushed the 70-email-verification branch from 92daf00 to 435fdb5 Compare May 3, 2022 14:32

cgeorgilakis force-pushed the 70-email-verification branch from 435fdb5 to 3801ff1 Compare May 16, 2022 14:19

UserAttributeMapper (SAML, OIDC , Social) support emailVerified User …

6919fdf

…field Closes#12013

cgeorgilakis force-pushed the 70-email-verification branch from 6afa5a2 to 6919fdf Compare May 17, 2022 07:49

pedroigor previously approved these changes Jul 21, 2022

View reviewed changes

UserAttributeMapper changes and add EmailVerified to getAttribute method

6d3532a

cgeorgilakis dismissed pedroigor’s stale review via 6d3532a August 5, 2022 13:55

cgeorgilakis requested a review from pedroigor August 8, 2022 07:05

stianst assigned mposolda Aug 25, 2022

change SAML Attribute mapper

df46cfd

stianst added the team/core label Jul 18, 2023

mposolda closed this Aug 7, 2023

cgeorgilakis mentioned this pull request Aug 22, 2023

UserAttributeMapper (SAML, OIDC , Social) support emailVerified User field #12013

Open

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants