In aws cognito we can use multiple user pools , is there anything similar in Supertokens , I could not find related to storing users in different collection / pool is the documentations
SuperTokens doesn't support multiple user pools at the moment (as of 11th June, 2022). However, it is on the roadmap.
In the meantime, you have the following options:
You can spin up one instance of the core, per user pool, connected to its own db. You would also need to spin up one backend server to connect to one instance of the core.
You can simulate a user pool by modifying the primary key identifying the user. For example, let's say you have two user pools (p1 and p2), and you are using email password login, where the email is the primary identifying info of a user. You can override the backend recipe functions to modify the email being sent to supertokens core to include the pool ID. So for example, if a user's email is user1#example.com, then you could change it to user1+p1#example.com if they belong to user pool 1. So this way, even if the user uses the same email in the other app, it would identify them as a different user (their email being user1+p2#example.com in pool 2). Whilst this approach may be slightly more complex to implement, it requires just one core, connected to one db.
Related
i am making a set of applications that share a common oidc provider (in my control), where the users will be created.
One of my applications is a stateless SPA "meeting" app where you can schedule meetings with other users, and you login purely by an OIDC token.
I am having a hard time thinking a strategy about the following
Should the "user" details be stored in the meeting app after a login? So let's say user A exists in the provider, then enters the meeting app. Should i save user A in the meeting app DB?
How to handle change of user details? Let's say user A changes name to User B in the provider. Until he logs in again, all the other users see him as User A still in the "contacts" list. What is the usual practice for solving this?
How to handle deletions in the provider. I need someway to signal that "deleted in provider -> deleted in app". Should i constantly poll the provider and get any missing users, create a push system, or is this just unneeded?
Thanks a lot in advance
That's actually a very good question and rarely explained well in online articles. Hopefully the below detailed notes help you with your solution. I have answered your questions at the end.
OAUTH USER DATA
Typically the core user data such as name, email etc belongs in the Authorization Server. It contains Personally Identifiable Information (PII) and changes are audited there. This is explored in further detail in the Privacy and GDPR article.
DOMAIN SPECIFIC USER DATA
This might include fields like a user's application preferences, and you may end up with data similar to this in your APIs:
Field
Description
id
A database surrogate key for the user
subject
The subject claim from an OAuth access token, which is typically a GUID or something similar
archived
A boolean flag set to true when a user is active in the app
field 1
A domain specific value
field 2
A domain specific value
To get OAuth user data within your applications your APIs can call the Authorization Server's SCIM 2.0 endpoint as described in this User Management article.
AUTHORIZATION AND ROLES
Interestingly, roles and application specific rights could be stored in either of the above data sources. You may want to start by putting roles in the OAuth data, but for cases where they are very domain specific and change often, I have found that storing them in my own API data works best.
DOMAIN SPECIFIC USER DATA AND ACCESS TOKENS
Sometimes you need to include domain specific user data (which might include roles) in access tokens. This Claims Article explains how claims can be looked up from external APIs during token issuance. This typically involves a REST call from the Authorization Server to one or more APIs, providing the subject value for which tokens will be issued.
CONSISTENT USER IDENTITY IN YOUR APPS
A user can potentially authenticate in multiple ways, such as default password / corporate login / social login. You may need to use some custom Account Linking logic to ensure that the subject field in the access token gets the same value in all cases. This prevents you ever creating duplicate users within your application.
USER INFO CHANGES
These are typically made by end users within an application screen, and your APIs then call SCIM endpoints to update the core OAuth data. A common case is when a user changes their name and / or email, eg if the user gets married. Note that the subject value remains the same after this edit.
USER ADMINISTRATION
In scenarios where corporate assets are used, an administrator typically provisions users, either individually or in bulk. This can be done via the SCIM endpoint. In some cases administrator actions may need to save data to both data sources - eg to create a user and set roles + application preferences.
USER INFO EVENTS
Sometimes your application needs to know about a user info event, such as new, deleted or changed users. This can be managed via Event Listeners, where an extension to the Authorization Server calls back your domain specific APIs when a user edit occurs. When a user is deleted in the OAuth user data you might then update the user's application state to archived.
DATA MIGRATIONS
Finally it is worth mentioning that the above also supports migrating to an OAuth architecture or between providers:
Get a combined view of the user data before migration
Insert all existing users into the new OAuth system via SCIM
Update the combined view of the user data with new subject values
Update your domain specific data with new subject values
SUMMARY
So to answer your questions:
Aim to avoid this because it adds complexity, though in some cases you may need to denormalise for performance reasons. The OAuth user data should remain the source of truth and the only place where edits occur to PII data.
Your meeting app would need to join on the OAuth user data and domain specific user data and present a list. This would probably involve caching a combined view of the user data.
See Administrator Events above. Your API should be informed of OAuth user data changes via an event, then your SPA would get current data on the next refresh.
When implemented like this you end up with simple code and a well defined architecture. Some providers may not provide all of these features though, in which case you may need an alternative approach to some areas.
Let's say a user makes a purchase. Is it somehow possible to detect that a user is the same person on a different device when using Cognito User pools with federated identities that allow guest access?
I don't want my users to have to provide an email address, but I want to know what is the most reliable way I can ensure they have the most access possible to any in app purchases they make.
Currently it seems not possible to do it.
The situation you described is like unauthenticated, so you will just get an identity id and that is always some random uuids to exchange for credentials.
I deployed a user pool in Cognito which now needs additional custom attributes. These can't be added after the fact. Is it possible to now move those users from the old user pool to a new user pool? I saw mention of using a Lambda to do this, but seems like a fairly common case and Lambda seems unnecessarily complicated when you just want to export/re-import user data especially between user pools in the same AWS account.
When i was working with classic ASP.NET or even with old web forms the HttpContext.Current.Session was User specific. So when user makes the request he receives the session cookie and then onward that session belongs to that user only. So two different users can have session key with the same name in their respective session.
I am reading the documenation on session in ASP.NET Core and looks like it has the same concept as old asp.net however certains notes in the documentation is confusing.
here it says
Session storage relies on a cookie-based identifier to access data
related to a given browser session (a series of requests from a
particular browser and machine). You can’t necessarily assume that a
session is restricted to a single user, so be careful what kind of
information you store in Session. It is a good place to store
application state that is specific to a particular session but which
doesn’t need to be persisted permanently
also here it says
Session is non-locking, so if two requests both attempt to modify the
contents of session, the last one will win. Further, Session is
implemented as a coherent session, which means that all of the
contents are stored together. This means that if two requests are
modifying different parts of the session (different keys), they may
still impact each other.
so lets say i have User1 logged in and upon some action i set
`Session.SetInt32("key1", 123)`
now User2 logs in from some other machine and upon some action i set
`Session.SetInt32("key1", 999)`
Question 1
Will this overwrite User1's key?
Also note here says
ASP.NET ships with several implementations of IDistributedCache,
including an in-memory option (to be used during development and
testing only)
Question 2
What are the other implementation of IDistributedCache that i can use in production?
For Question 1.
No, one user modifying a session key will not overwrite a different user's key. The session is unique to each visitor/user because of the .AspNetCore.Session cookie that is created.
All of the Session.Set calls get stored per that unique identifier.
#1
Session isn't tied to a user because session is only identified by it's session key, so if someone gets possession of the session key/cookie, he can access it.
Asp.Net Core Identity has its own cookie (if you are using cookie authentication) and Session middle ware use its own cookie too.
Naturally, you can also use Sessions without a user. Take Google.com for example. When you first visit Google, it shows you policies and set a session cookie. All settings you do (i.e. maturity filter), will be saved in the session which gets accessed each time you perform a search.
This all without being logged in, so there is no user at all.
#2
Open Source is your friend:
https://github.com/aspnet/Caching/tree/dev/src
Redis and SqlServer are the default distributed caches, with InMemory being for development / single-node only. There also may be other third party libraries which add support.
I'm trying to design MVC4.5 website on Azure with latest EF but stuck in setting up membership and role base authentication.
I'm somewhat lost in MembershipProvider, SimpleMembershipProvider and ExtendedMembershipProvider.
I found that unlike SqlMembershipProvider the SimplememberShipProvider is not designed to store multiple applications (through ApplicationName and ApplicationID) in a single database and map users accordingly so that business can run multiple applications with only one database.
I hear all praises of SimpleMembershipProvider, my question is how should the database/providers be designed so that I'm able to store user's in association with respective applications in a single database. User registration info must be completely independent from same user name in other application. I also need new features of Open Authentication.
Broadly, my queries are:
Is it possible to use SimpleMmebershipProvider to differentiate between multiple applications in a single database.
I'm thinking to modify existing schema structure made by SimpleMembershipProvider to include ApplicationId column , but then how would even a custom provider that is inherited from Extended membership provider add ApplicationId against any user.
Is there any other provider available or any article that would guide in implementing custom membership provider with custom database design along with features of open authentication.
Or am I going with completely wrong approach?
Answering to the queries of BernardG
Do you want a "head" url/site, then redirect users to the proper
application, or
No, sites should not appear related nor will be redirect to other.
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Again no, each application should have it's own registration process. Further two applications can have same username but these accounts would not be related.
Can a user register into any application?
Yes.
If not, how do you limit that?
Not limiting.
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Refering to answer to point 2, if there are 4 applications with one database and a user registers for one application, he must need to register again to have access to other application. Hence for any user the sites must not appear related.
Do you want to duplicate users info into each applications?
As per my understanding of the question a combination of username and email address (considering this combination makes any user account unique) can again be stored against another application even with different profile information.
Actually I'm used to the classic membership approach used in ASP.net 2.0 and I'm missing the application Id column for separation.
If I may, I believe your question has a lot more to do with design and establishing clearly the features you want, rather than a specific membership provider, knowing that you can do about anything you want with SimpleMembership.
My questions, and I believe those are the questions you have to ask yourself before going further, are:
Do you want a "head" url/site, then redirect users to the proper
application, or
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Can a user register into any application?
If not, how do you limit that?
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Do you want to duplicate users info into each applications?
It looks to me that this is all about database(s) design, and analysis, for your real needs. Once that's properly done, the part about membership tables will be easily solved.