Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User and Role claims don't support multiple claims with the same type or value #5

Open
cmsd2 opened this issue Mar 28, 2017 · 2 comments

Comments

@cmsd2
Copy link
Contributor

cmsd2 commented Mar 28, 2017

both users and roles have the same pattern for storing claims,
and they both require that the claim types and the claim values are a set of unique items
(dynamodb does not allow inserting duplicates into a string set).

I think this is too restrictive and it denies legitimate uses of claims:
e.g. http://benfoster.io/blog/asp-net-identity-role-claims

https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims
f.t.a:
"An identity can contain multiple claims with multiple values and can contain multiple claims of the same type."

@miltador
Copy link
Owner

This is a good point for a brainstorming on our table structure.
Since DynamoDB doesn't allow querying on nested items we probably have to keep things we want to query on top level.
The best solution I came with is what you see now.
If you have any ideas or starting points on how this can be solved - please share!

@cmsd2
Copy link
Contributor Author

cmsd2 commented Mar 31, 2017

Having these claims as top-level stringsets is nice in that it allows conditional updates/deletes and update expressions that operate directly on the sets. It also allows filter expressions in queries/scans.

The alternative is to force users of the tables to fetch entire records and manipulate or filter in memory.

I'm thinking this might not be such a loss:

The table GSIs are all high cardinality so I think that it's unlikely to be a problem for queries: queries will already be very selective so filtering in memory might not be a problem.

Updates and deletes would need to rely on the optimistic locking instead of conditional expressions and updates need to replace instead of mutate.

Scans would end up returning all rows. It's a shame, but how about using streams, or loading the table into redshift instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants