Question: How do I add new claims after `HttpContext.Authentication.SignInAsync` has been called?
jakejscott opened this issue · 7 comments
I want to be able to add a new claim to a user, but I've noticed that if I add the claim it's not being serialized with the cookie. Do I need to call await HttpContext.Authentication.SignInAsync(blah) again so that it resends the cookie with new claims in it?
You do it when you create the principal before you sign in.
If you already have a principle, then you'd use claims transformation, if you do it during runtime you'd use a validator. Both of which are out of scope for this tutorial.
Is there's any docs on claims transformation?
In my case I want to create a new 'CartId' and add it to the principle. The principle I have is anonymous so I want to store the CartId as a claim using the cookies middleware as I don't have a database record for anonymous users.
If the principal creates a new cart, I'd need to modify the claims (without re signing in)
Claims Transformation isn't going to help either. As soon as someone authenticates we throw away the old principal. Using auth for this seems a little heavy handed, what's the reason why a "normal" cookie won't do here?
I did have a cookie that I stored the cartId in but I wanted to protect that using the DataProtection apis.
After some reading last night, I found that the DataProtection APIs won't really work well in AWS just yet when deploying behind an Elastic Load Balancer: aspnet/DataProtection#92
I think I have to solve that problem anyway because AntiForgery uses DataProtection APIs too right?
It does, as does cookie auth :) So I suggest looking at writing a key repository for your architecture. I promise it's not hard, there are two things to implement in IXmlRepository, getting all keys, and adding a new one. That's it :)
All good, I think I'll have a look at using S3
I see some work has started on AzureBlog one here: https://github.com/aspnet/DataProtection/blob/pakrym/blob/src/Microsoft.AspNetCore.DataProtection.Azure.Blob/AzureBlobXmlRepository.cs
I also see there's a Redis based one being proposed too, not sure how good an idea that is seeing Redis doesn't always persist to disk?
aspnet/DataProtection#169
Total guess here but another option if deploying on Linux could be Elastic File System..
https://aws.amazon.com/efs/
Well for ephemeral data, not persisting isn't a problem :) Plus redis can persist now too. Customers did ask for it, so who am I to argue?