TryGetAsync possibly broken in IUserProfileAdmin/IUserProfileSelfService

[iseneirik]

I've been scratching my head all day trying to figure out if this is a me-problem or a problem with IUserProfileAdmin/IUserProfileSelfService.

I'm creating an "invite-only" registration flow for my local users doing the following:

1. Receive link with invite-code
2. Fill out info (Name, Username, Email)
3. Submit OTP registration

Later, when the user wishes to log in again I first do a check if the user exists, with the intention of only allowing existing users to log on. For this I use the IUserProfileAdmin.TryGetAsync(AttributeCode attributeCode, object value, Ct ct);, but this never finds the profile for some reason.

To do a sanity check and see if TryGetAsync does what I think it does, I set up a few break-points in the "Submit OTP"-stage of the registration, at the point where a profile is created:

// userAdmin is IUserProfileAdmin in this example
var schema = await userAdmin.GetSchemaAsync(cancellationToken);
var attributes = new AttributeValueCollection(schema);
attributes.Set(OidcStandardAttributes.Email, request.Email);
attributes.Set(OidcStandardAttributes.Name, request.Name);
attributes.Set(OidcStandardAttributes.PreferredUserName, request.Username);

// request.SubjectId is from otpSuccess.UserSubjectId
var profile = await userAdmin.TryAddAsync(request.SubjectId, attributes.Validate(), cancellationToken);
if (profile is null)
{
    return RegisterUserResult.ProfileAlreadyExists();
}

// allUsers returns one profile (the one just created, which is correct)
var allUsers = await userAdmin.QueryAsync(QueryRequest.Create(), cancellationToken);
var user = allUsers[0];

// getting on SubjectId works fine, returns the same user that is returned in allUsers
var viaSub = await userAdmin.TryGetAsync(user.SubjectId, cancellationToken);

// not found
var viaEmail = await userAdmin.TryGetAsync(user.Attributes[OidcStandardAttributes.Email].Code, user.Attributes[OidcStandardAttributes.Email].UntypedValue, cancellationToken);

// not found
var viaName = await userAdmin.TryGetAsync(user.Attributes[OidcStandardAttributes.Name].Code, user.Attributes[OidcStandardAttributes.Name].UntypedValue, cancellationToken);

// not found
var viaUsername = await userAdmin.TryGetAsync(user.Attributes[OidcStandardAttributes.PreferredUserName].Code, user.Attributes[OidcStandardAttributes.PreferredUserName].UntypedValue, cancellationToken);

As you can see, I'm even using attribute values from the actual profile just created just to confirm that there aren't any equality shenanigans holding me back. The simpler version of the call (await userAdmin.TryGetAsync(OidcStandardAttributes.Email, request.Email, cancellationToken), etc.) yields the same result.

So far I believe this is a bug where some sort of equality comparison is wrong, either in the code or the resulting SQL.

[maartenba]

Hi @iseneirik ! Thanks for the detailed report, and good instinct to compare against QueryAsync and TryGetAsync(subjectId). That made this easy to reproduce.

You're not holding it wrong. TryGetAsync(AttributeCode, object, ct) only works for attributes that are marked unique in the user profile schema. Under the hood it isn't a value search. It looks up a storage key, and those keys are only written for attributes whose definition has IsUnique = true. The built-in OidcStandardAttributes (Email, Name, PreferredUserName, ...) are all non-unique by default, which matches the OIDC spec. So there's never a key to find, and the call quietly returns null.

The API should make this much clearer. We've filed an internal issue, and we'll update the docs.

In the meantime, you have two options:

1. Mark your lookup attribute unique (recommended for an invite-only or login-identifier flow):

var result = await schemaAdmin.GetAsync(SchemaId.UserProfile, ct);
var schema = result.Item!;
var email = schema.AttributeDefinitions.Single(d => d.Code == OidcStandardAttributes.Email.Code);
schema.AttributeDefinitions.Remove(email);
schema.AttributeDefinitions.Add(email with { IsUnique = true });
await schemaAdmin.UpdateAsync(SchemaId.UserProfile, schema, result.Version!.Value, ct);

After that, TryGetAsync(OidcStandardAttributes.Email.Code, "alice@example.com", ct) finds the profile. Keep in mind:

• Only profiles saved after this change become findable. Existing profiles need to be queried and re-saved, for example with a no-op update (through IUserProfileSelfService.TryUpdateAsync)
• Uniqueness is enforced, so TryAddAsync returns null if a second profile uses the same email. For your flow that's probably what you want.

2. Use QueryAsync with a filter if the attribute shouldn't be unique. The attribute must be IsQueryable.

[iseneirik]

Ah, that makes sense, thank you for the quick reply! 😄

A quick follow-up relating to making the docs clearer, what exactly does this mean?

Does it mean that if I have added the email-attribute (TryAddAttributeDefinitionAsync) , then a successful call to IOtpAuthenticator.TryAuthenticateAsync will set this attribute for me? It doesn't seem to be doing so, so I do it manually (as you can see from the example I provided).

[maartenba]

Going to make an update there. It alludes to what we do in the quick start - https://docs.duendesoftware.com/identityserver/identity/user-management/getting-started/ - where the email becomes the subject ID.

[mahoekst]

We will address this in an upcoming release